Vulnerability disclosure policy
If you have found a security issue in our platform, we want to hear about it. This page tells you what is in scope, how to test without crossing a line, what we commit to in return, and the protection you have when you act in good faith.
How to report
Email [email protected] with the affected URL or endpoint, the steps to reproduce, what an attacker could achieve, and anything you need us to keep confidential.
This address is also published in our security.txt, per RFC 9116. Reports in English or Arabic are equally welcome.
Scope
In scope
- The public web application at steadywrk.app
- Public API endpoints under steadywrk.app/api that are documented in our OpenAPI description
- The Model Context Protocol endpoint at steadywrk.app/api/mcp
- Authentication and session handling on operator and employer surfaces
- Our published machine-readable discovery artifacts under /.well-known/
Out of scope
- Any host or subdomain not listed above, including staging, preview and unreferenced hostnames
- Third-party services we consume — report those to the provider under their own policy
- Denial of service, load testing, resource-exhaustion and volumetric testing of any kind
- Social engineering, phishing, or physical attempts against our people or premises
- Automated scanner output submitted without a demonstrated, reproducible impact
- Missing hardening headers, cookie flags, or TLS configuration preferences with no demonstrated exploit path
- Reports that a published policy or disclosure page is missing an optional field
If a host is not named in the in-scope list, treat it as out of scope. Not every hostname that resolves is a production system, and testing an unlisted one is outside this policy and outside its safe harbour.
Rules of engagement
- Test only against accounts and data you own or have explicit permission to use.
- Stop at proof of concept. Do not access, modify, download, retain or exfiltrate data that is not yours — demonstrating access is enough, and we will take your word for the rest.
- Do not degrade service for anyone else. If a test could affect availability, describe it to us instead of running it.
- Give us a reasonable opportunity to remediate before disclosing publicly.
- Do not demand payment in exchange for withholding a report. We run no bug bounty and offer no reward; a report conditioned on payment is not a good-faith report.
What we commit to
| Timeframe | Commitment |
|---|---|
| Within 5 working days | We acknowledge receipt of your report. |
| Within 15 working days | We give you our assessment of validity and severity. |
| Ongoing | We keep you updated on remediation progress until the issue is closed. |
| On resolution | We confirm the fix and, with your permission, credit you publicly on our security page. |
We run no bug-bounty programme and offer no monetary reward. We say so plainly rather than leave it ambiguous, so you can decide how to spend your time before you spend it.
Safe harbour
If you make a good-faith effort to comply with this policy during your research, we will consider your research authorised, we will not initiate or support legal action against you in connection with it, and we will not report you to law enforcement for it.
If a third party brings legal action against you for research you conducted in good faith under this policy, we will make it known that your activity was authorised.
Good faith means: you stayed within the scope above, you stopped at proof of concept, you did not access or retain data belonging to others, you did not degrade the service, and you gave us a reasonable chance to fix the issue before telling the world. If you are unsure whether something is permitted, ask us first — we would much rather answer the question than argue about it afterwards.
This safe harbour is limited to us. It cannot and does not bind third parties whose systems we do not control.
Related: Security posture · Subprocessors · Privacy