Security disclosure policy

If you have discovered a security issue affecting CAO Studio — the SaaS deployment, the Local Client + CAO Server deployment, the CAO Studio website, or any associated infrastructure — we want to hear from you. Please report it privately to the address below before any public disclosure.

Primary contact: security@creatingagileorganizations.com

Send your report to the address above. If you need to share sensitive details under encryption, ask for our PGP key when you make first contact. The full security contact details are documented at https://www.caostudio.org/.well-known/security.txt (RFC 9116).

Useful information to include in the report:

• A clear description of the issue and the impact you observed.
• The CAO Studio component affected (web, backend API, CAO Server, local client) and, if known, the version number.
• Steps to reproduce, including any specific input values, URLs, or sequences of actions.
• Any artefacts that helped you verify the issue (screenshots, request/response captures with sensitive data redacted, log excerpts).
• Whether you have shared the issue with any third party.

We treat every reported security issue seriously and follow a documented response playbook. Specifically, we commit to:

• Initial acknowledgement within 2 business days of receipt.
• A status update at least every 7 days while the issue is being investigated.
• Coordinated public disclosure on a timeline agreed with the reporter; our default is 90 days from the initial report, sooner once a patch is published and customers have been notified, and longer only with the reporter's consent.
• Public credit on our acknowledgments page after the issue is resolved, unless you ask to remain anonymous.

For Critical-severity issues (CVSS 9.0 and above) we aim to publish a signed patched release within 48 hours of severity confirmation, and to email all active license-holders within the same window. For High-severity issues (CVSS 7.0–8.9) the patch SLA is 7 days. Lower-severity issues are addressed in the next routine release and recorded in the release notes.

We support and welcome security research conducted in good faith. We will not pursue civil or criminal action, or report you to law enforcement, for security research and vulnerability disclosure activity that meets all of the following conditions:

• You make a good-faith effort to avoid privacy violations, degradation of user experience, disruption to production systems, and destruction or manipulation of data.
• You access only the minimum data necessary to demonstrate the issue, and you do not retain, transfer, or use any data once the report has been acknowledged.
• You give us a reasonable opportunity to investigate and remediate the issue before any public disclosure.
• You do not exploit the issue beyond the proof of concept required to report it.
• You comply with all applicable laws.

If you are unsure whether a particular test is in scope, contact us at security@creatingagileorganizations.com before proceeding. We would rather have the conversation up front than learn about it after the fact.

In scope

• The CAO Studio SaaS application and its API surface.
• The CAO Server (the centrally-hosted AI processing component used by Local Client deployments).
• The CAO Studio Local Client binary distribution and its install path.
• The CAO Studio website at https://www.caostudio.org.
• The release-attestation pipeline (signed images, SBOM, transparency-log entries) — if you can show the signing chain is broken or forgeable, we want to know.

Out of scope

• Denial-of-service findings that require sustained, large-scale traffic to demonstrate.
• Spam, social-engineering, and physical attacks against our offices or staff.
• Reports based solely on automated-scanner output without a concrete demonstrable impact.
• Missing security headers, missing CAPTCHAs, or other best-practice gaps without a demonstrable exploit path.
• Issues in third-party services we use (Resend, Sentry, GitHub, Sigstore, our AI provider) — please report those directly to the responsible vendor; we are happy to help coordinate where useful.
• Issues that require the attacker to already have administrator or developer access to the target installation.

We do not currently operate a paid bug bounty programme. We may introduce one once the volume and severity profile of reports justifies it. In the meantime, we credit researchers on our acknowledgments page and respond promptly to every report.