Vulnerability disclosure policy

Gitana welcomes reports from security researchers and customers who find vulnerabilities in our products and services. This page explains what is in scope, how to report, what you can expect from us, and the commitments we make to people who report in good faith.

Scope

In scope

  • The Gitana hosted service: *.gitana.io and *.cloudcms.net, including the API and the user interface.
  • Gitana container images (cloudcms/api-server, cloudcms/ui-server, cloudcms/webshot-server, cloudcms/antivirus-server) and the deployment kits and Helm charts we publish for them.
  • Gitana client libraries and SDKs published under our name.

Out of scope

  • Third-party services we use (AWS, Braintree, Docker Hub and others). Report those to the provider.
  • Findings that require physical access to a user’s device, or social engineering of Gitana staff or customers.
  • Denial-of-service testing, spam, or anything that degrades service for other customers.
  • Automated scanner output without a demonstrated impact.
  • Reports about missing best-practice headers, TLS configuration or similar without a working exploit, unless the finding is on this list because it exposes customer data.
  • Vulnerabilities in third-party components listed in our SBOMs that our published VEX already assesses as not affecting the product — unless you can show the assessment is wrong, in which case we very much want to hear it.

How to report

Email security@gitana.io. Encrypt with our PGP key if the report contains sensitive detail: /.well-known/pgp-key.txt, fingerprint 93E6A3559B21A84B521D6A415C9D47769BAF2602.

Please include:

  • the product or URL affected and, for images, the exact tag or digest;
  • steps to reproduce, or a proof of concept;
  • the impact as you understand it;
  • how you would like to be credited, if at all (see Acknowledgments).

Please do not include customer data you may have encountered beyond what is needed to demonstrate the issue, and delete any such data once the report is filed.

What we will do

  • Acknowledge your report within 2 business days.
  • Assess it and tell you our initial view of severity and whether it is in scope within 5 business days.
  • Keep you informed as we work on a fix, and tell you when it ships.
  • Fix confirmed vulnerabilities according to severity: our target is 30 days for Critical and High, 90 days for others. Where a fix depends on a third-party component without a fix available, we will say so and describe mitigations.
  • Credit you on our Acknowledgments page if you wish, once the issue is resolved.

Coordinated disclosure

We ask that you give us a reasonable opportunity to fix an issue before you disclose it publicly — 90 days from acknowledgment, or sooner once a fix has shipped to all supported versions. If we need longer, we will explain why and agree a date with you. We will not ask you to withhold disclosure indefinitely.

We do not currently operate a paid bug-bounty program.

Safe harbor

If you make a good-faith effort to comply with this policy while researching, we will consider your research authorized, will work with you to understand and resolve the issue quickly, and will not initiate or recommend legal action against you. If a third party pursues legal action against you for activity consistent with this policy, we will make it known that your actions were authorized.

Good faith means: you do not access, modify or destroy data that is not your own beyond what is necessary to demonstrate the issue; you do not degrade the service for others; you do not exploit an issue beyond proof of concept; and you report promptly and keep the details confidential until disclosure is agreed.

Our own practice

How we build, scan and publish our software — including the SBOMs, vulnerability assessments and signatures shipped with every container image — is described on the security page. Reports that our published VEX is wrong are in scope and welcome.

Last updated: September 2026