Reporting a vulnerability

Email security@shortspan.dev. Please do not open a public issue for a security problem, and please do not disclose it publicly before it is fixed.

A useful report includes what you did, what happened, what you expected, and why it matters. A proof of concept helps enormously; a scanner's raw output on its own rarely does.

The full policy is published at shortspan.dev/legal/vulnerability-disclosure.

1. 01

   Acknowledgement that a person has read it, not just an autoresponder.

2. 02

   An assessment of severity and impact, shared with you.

3. 03

   Regular updates while it is being worked on, without you having to chase.

4. 04

   Credit in the fix if you want it, and none if you do not.

We will not threaten legal action over research conducted in good faith under the rules below.

• The application, the API, and the marketing and documentation sites.

• The CLI, including its update mechanism.

• Anything that lets one workspace reach another's data.

• Anything that lets a role act beyond its permissions.

• Anything that exposes secret plaintext, key material, or token plaintext to someone not entitled to it.

• Anything that lets the platform control plane read customer credentials - that boundary is a design commitment, and a hole in it is a real finding.

• Denial of service, volumetric testing, and anything that degrades service for other people.

• Social engineering of staff, customers, or vendors.

• Physical attacks.

• Findings that only affect an out-of-date browser.

• Missing hardening headers with no demonstrated impact.

• Reports from automated scanners with no analysis attached.

• The documented limits in Security model - that credentials are decrypted server-side, that a compromised machine can read a brokered credential, or that runbook steps are not sandboxed. Those are design decisions, described openly. A way to *exceed* them is very much in scope.

• Use your own account and your own workspace.

• Do not access, modify, or retain anybody else's data. If you encounter someone else's data, stop and tell us.

• Do not degrade the service for others.

• Give us reasonable time to fix an issue before disclosing it.

A vulnerability in Shortspan itself is in scope regardless of where it runs - please report it. A misconfiguration of your own deployment is yours; Running it covers the failure modes that are silent by default.

Security fixes are announced through the release notes, and a release with a serious defect can be marked blocked so clients refuse to run it.