Vulnerability Disclosure Policy

Transpose Skills holds student evidence, assessment decisions, and personal information on behalf of Australian education and training providers. If someone finds a way to reach data they should not reach, we want to hear about it before anyone else does.

We will not pursue legal action against anyone who reports a vulnerability in good faith and in accordance with this policy. We would rather receive an uncomfortable report than not receive it.

We do not currently publish a PGP key. If you need an encrypted channel before sending details, say so in a first email that contains nothing sensitive and we will arrange one.

Please send one issue per email, and please do not disclose publicly before we have had a chance to respond.

A good report lets us reproduce the issue without guessing:

• What the vulnerability is and where it is — URL, endpoint, or component.
• Steps to reproduce, in enough detail that we can follow them.
• What an attacker could achieve with it.
• Any proof-of-concept material — a request, a screenshot, a short recording.
• Whether you believe any real data was exposed, and if so what.
• How you would like to be credited, if at all.

• Acknowledge your report within 2 business days.
• Assess and triage within 5 business days, and tell you our severity assessment and whether we consider it in scope.
• Keep you updated at least every 10 business days while the issue is open.
• Tell you when it is fixed, and confirm the fix with you where you are willing.
• Credit you in our disclosure acknowledgements, if you want to be credited.
• Not take legal action against you for good-faith research conducted under this policy.

These are our internal targets, measured from acknowledgement. A complex issue may take longer; where it does, we will tell you why rather than letting the clock run out quietly.

We ask for 90 days from acknowledgement before public disclosure, or until a fix is released, whichever is sooner. If we need longer we will say so and explain why.

We will not ask you to stay silent indefinitely, and we will not treat a deadline you gave us in good faith as hostile.

In scope — the Transpose Skills web application and its API at www.transposeskills.com, the publicly embeddable components served from that domain, and our published security.txt and the supporting infrastructure we control.

Out of scope — our cloud providers’ own infrastructure (Google Cloud, Microsoft Azure, Stripe, Twilio), which should be reported to the provider under their own programme; customer-controlled configuration and content, including an organisation’s own settings, uploaded material, and connected systems; and findings on a domain we do not operate.

A report consisting solely of the following will be acknowledged and then closed. If you can demonstrate real impact, that is a different report and we want it.

• Automated scanner output with no demonstrated impact.
• Missing security headers with no demonstrated exploit path.
• Software version disclosure without a working exploit.
• Social engineering of our staff or our customers.
• Physical attacks, or attacks requiring physical access to a device.
• Denial-of-service and volumetric testing — see section 9.
• Self-inflicted issues requiring the victim to paste attacker-supplied content into their own browser console.
• Missing best-practice configuration with no security consequence.
• Email deliverability configuration (SPF, DKIM, DMARC) on domains not used for the application.

Testing under this policy is authorised only within these limits.

You must not

• Access, modify, download, retain, or destroy data belonging to anyone other than yourself. See section 10.
• Run denial-of-service, volumetric, brute-force, load, or stress testing against any environment.
• Send phishing or social-engineering attempts to our staff, our customers, or their students.
• Attempt physical access to any premises or device.
• Use an automated scanner at a rate that degrades service for real users.
• Publish details before the disclosure window in section 6 has elapsed.

You should

• Use your own test account wherever possible. Contact us if you need one.
• Test against a non-production environment where we can provide one.
• Include a distinctive identifier in your requests — a custom user-agent or header — so we can tell your testing apart from a real attack.

Evidence on this platform includes academic transcripts, employment history, and in some cases recordings of people describing their own working lives. A single cross-tenant read here is not an abstract finding — it is a real person’s records.

Proving that a boundary can be crossed does not require crossing it repeatedly, and it never requires retaining what you found. One reproducible example, reported and then deleted, is worth more to us than a complete extraction, and it is the only version of the finding this policy authorises.

If you inadvertently reach another person’s data, stop immediately, do not save a copy, do not explore the extent of the access, and tell us what happened in your report. Doing that is not a mark against you — it is what we are asking for.

If you make a good-faith effort to comply with this policy during your research, we will:

• Consider your research authorised under applicable Australian computer-misuse law in respect of our systems.
• Not initiate or support legal action against you in relation to it.
• Work with you if a third party takes action, to make clear that your research was authorised by us.

This safe harbour applies to our systems only. It cannot and does not extend to our cloud providers, our customers, or any other third party.

If you are unsure whether something is in scope or authorised, ask us before you test it. We would rather answer a question than receive an apology.

We publish the vulnerabilities reported to us once they are resolved — what the issue was, how severe we assessed it, and when we fixed it. We describe an issue at the level a customer needs to judge their own exposure, without handing anyone a reproduction against an organisation that has not yet taken the fix. We never name a customer.

A resolved report appears here whether or not it reflects well on us. Where a reporter asked to be named, we name them alongside it — tell us in your report how you would like to be credited, or that you would prefer not to be. If your organisation was materially affected by an issue, you will hear from us directly rather than reading about it here first.

We review this policy every twelve months, and sooner where our platform or our obligations change. The date at the top of this page is the version in force. A change does not apply retrospectively to research you have already carried out under an earlier version in good faith.

Transpose Labs Pty Ltd, 1/457-459 Elizabeth Street, Surry Hills, NSW 2010, Australia.

Security reports: security@transposeskills.com. General enquiries: hello@transposeskills.com.

This policy sits alongside our Terms of Service and Privacy Policy. Section 8 of the terms prohibits probing the platform’s security without our written consent — research conducted within this policy is that consent.