Security at Gitana
Gitana is available as a hosted service (SaaS) and as container images for self-managed deployment. This page describes the security practices that apply to both, and how to verify them yourself. It is written for security and compliance reviewers; where a topic has a hands-on companion, it is linked.
Senior management is accountable for security and ensures that security capabilities and competence exist at every level of the business. We follow a collaborative approach to protect the confidentiality, integrity and availability of your data.
At a glance
| Hosting | AWS, Virginia (US) or Frankfurt (EU); ISO 27001-certified data centers |
| Encryption | At rest: AES-256 with AWS KMS-managed keys, on S3, databases and EBS. In transit: HTTPS (TLS 1.2 / 1.1) |
| Identity | OAuth 2.0; role- and policy-based authorization; SAML 2.0 and JWT SSO; MFA |
| Data history | Changeset versioning of every transaction; roll back or restore to any point in time |
| Backups & continuity | Continuous encrypted backups replicated across data centers; yearly disaster-recovery tests |
| Assurance | Continuous vulnerability scanning; annual penetration test; annual staff security training; internal audit |
| Supply chain (images) | Signed images with SBOM, VEX and scan attestations, verifiable offline against a published key — details |
| Privacy | GDPR obligations met; DPA available on request; full export and permanent deletion |
| Contact | security@gitana.io · /.well-known/security.txt |
Data protection
Where your data lives
Gitana services and data are hosted in Amazon Web Services facilities in Virginia (US) or Frankfurt (EU). The data centers used to store and deliver your content are certified to ISO 27001 (AWS compliance).
Encryption at rest
Your data is encrypted at rest in the S3 buckets, database instances and EBS block devices that hold it. AWS KMS manages the keys used to write and read storage. Where hybrid block encryption is used, AES-256 is applied and a digital hash is written to the end of each file; verifying it on read ensures assets were not manipulated between write and read.
Encryption in transit
All exchange between a user’s browser (or API client) and Gitana uses transport-level encryption (TLS 1.2 by default).
Backups and retention
All data is backed up continuously. EBS volumes are snapshotted with redundant storage across multiple data centers; the snapshots are encrypted with keys and ciphers distinct from the volumes themselves. Binary content is stream-encrypted on write to S3, replicated in real time across data centers, and the buckets are encrypted at rest with their own keys. Customers with additional backup requirements can use Project Export.
Data portability and deletion
Customers can export all content in their tenant at any time. Personal data processed by Gitana is limited to the name and email of the business users who access a repository. All customer content is permanently deleted when an account is deleted.
Identity and access
Authentication is OAuth 2.0 over HTTPS. Authorization is role-based, expressed as policy documents that describe rights over classes of assets. Policies are assigned to individuals, groups or teams and can grant or revoke access to individual objects, types of objects, folders, projects, data stores or entire platforms. Authority may be direct, inherited through group membership, or propagated through folder containment. Every API call is subject to these checks, so only principals with the correct rights can retrieve, store or act on data.
Single sign-on works out of the box with SAML 2.0 and JWT, connecting Gitana to commercial and open-source identity providers. Self-managed customers can add SSO customizations for tighter adaptation to a corporate policy.
Multi-factor authentication can be enabled for users; the second factor may be a mobile phone, an email, or an app on the user’s device.
Password policy (for local accounts): minimum 8 characters, including at least one numeric and one alphabetic character. The password policy can be further restricted or customized on a per-tenant basis.
Application security
API
The Gitana API is an HTTPS endpoint authenticated with OAuth 2.0 and encrypted with TLS. Your data is always transmitted encrypted, and strict authority checks on every call ensure that only correctly authorized principals can act on it.
Versioning and auditability
Gitana uses a Git-like changeset model that captures every change made by editors or through the API. Every operation is transactional and its full payload is recorded in its own changeset, spanning multiple documents where a unit of work does. Nothing is lost: your business can roll back or restore to any prior moment, and the history is an audit trail of who changed what.
Environments and release control
A Project is an isolated workspace. Within it, teams manage content lifecycle and approval workflow, work on release branches with scheduled publishing through QA, staging and production, and deploy through integrated targets (Amazon S3, FTP, remote Gitana servers).
Secure development
Security is enforced throughout the release cycle. Quality assurance for each release includes code peer review and a list of security checks and tests that must pass. Extensive non-regression testing is performed and approved before release to production.
Self-managed deployments: container images
Customers who run Gitana themselves receive it as container images. Everything a reviewer needs to verify an image independently is published with it; the hands-on commands are on the container images page and each release page.
| Signed images | Every image is signed with Sigstore cosign. Signatures are bound to the image digest, not the tag, and verify offline against our published public key. |
| Software Bill of Materials | Every image ships an SBOM (CycloneDX and SPDX), generated at build time from the exact image that ships, attached as a signed attestation and published as a file. |
| Vulnerability assessments (VEX) | Every image carries a signed OpenVEX document stating, per assessed vulnerability, whether the product is affected and why. |
| Scan results | Images are scanned with Trivy and Grype before release and re-scanned for the life of each supported version; the scan and a summary score are attached as signed attestations. |
| Minimal base images | Red Hat UBI 9 Minimal (API server) and Alpine Linux (Node.js services), updated at every build; no package managers or build tooling in the runtime image. |
| License-gated | The product runs only with a Gitana-issued license file; the images contain no secrets. |
How asssessments work
For each vulnerability reported against a component we ship, the VEX states not_affected (with a machine-readable justification and a plain-language reason), affected (with the recommended action and the release carrying the fix), fixed, or under_investigation. A vulnerability with no statement has not yet been assessed; we do not use VEX to hide findings.
Continuous re-assessment
Supported versions are re-evaluated against current vulnerability databases on a weekly schedule. New Critical or High findings receive an initial statement within 5 business days and a final assessment within 30 days. Operating-system fixes are picked up at the next image build; application dependency fixes ship in the next maintenance release. When an assessment changes, the VEX for every supported version containing that component is regenerated and re-signed. VEX and re-scanning are maintained for the current release and up to the previous 5 releases within the last year.
Third-party components and licensing
The SBOM lists every component with its license. We do not ship components under licenses that would impose copyleft obligations on your use of the product, and the SBOM records the concluded license for multi-licensed components.
Operations and resilience
Business continuity
High availability, failure resilience and continuity are addressed through database replication for redundancy and uptime, frequent encrypted backups stored both at the data center and at a remote location, and redundant components at each service layer so that a single failure does not affect the rest of the system. Data centers enforce physical security and protection against environmental hazards. Disaster-recovery procedures are tested yearly.
Availability
Current status of the API and UI is published through a third-party monitoring service.
Monitoring
System availability, performance and capacity are monitored so that potential issues are detected, reported, logged and resolved in a timely manner.
Audit logging
Tooling and processes are in place to monitor account activity across the infrastructure.
Assurance
| Practice | Cadence |
|---|---|
| Vulnerability scanning with industry-standard tools | Continuous |
| Penetration testing, with a remediation plan by criticality and re-testing of resolved findings | Yearly |
| Security and awareness training for all employees | Yearly |
| Internal audit that controls are designed and operating as management intends | Ongoing |
| Disaster-recovery exercise | Yearly |
Governance
Security policies. Employees are bound by a set of security policies and guidelines covering strong passwords, physical security, cybersecurity best practice, and privacy and confidentiality.
Third-party suppliers. Gitana maintains an inventory of service and software suppliers, performs risk analysis and security review on them, and ensures they hold the compliance certifications their role requires (for example PCI for payment providers; SOC 2 or ISO 27001 for business-critical services).
Payments. All payment-instrument processing is outsourced to Braintree, a certified PCI Service Provider Level 1 (details).
GDPR. Gitana fulfils its obligations and is transparent about how it processes personal data. A Data Processing Addendum can be signed by contacting legal@gitana.io.
Incident response
Security incidents are handled through a documented process that includes notification of and cooperation with affected customers, data-protection authorities and law enforcement. Affected customers are notified without undue delay after detection, with a preliminary assessment and an open channel for cooperation. Where personal data is involved, Gitana follows GDPR Article 33 and notifies the supervisory authority.
Reporting a vulnerability
If you’ve found a vulnerability, we ask that you report it to our security team at security@gitana.io.
To report sensitive information, please encrypt any communication using our PGP Key.
- PGP Key
- Fingerprint:
[93E6A3559B21A84B521D6A415C9D47769BAF2602]
Please give us a reasonable opportunity to investigate and fix an issue before public disclosure; we will keep you informed of our progress and do not pursue legal action against researchers acting in good faith. Machine-readable contact details are at /.well-known/security.txt.
Frequently asked questions
Can we verify images without trusting your registry?
Yes. Signatures verify against our public key on your side; the registry only stores them. If the key on this site and the signature on the image agree, the image is ours and unmodified, wherever it was pulled from.
Our scanner shows a Critical finding on an image. Is the product vulnerable?
Check the VEX first (the images page shows how to scan with it applied). Most Critical and High findings on current images carry a not_affected statement with the reason. A finding with no statement has not yet been assessed; contact us.
Do you provide SBOMs in a specific format?
CycloneDX and SPDX, both JSON. If your tooling needs another format, ask.
Can we get a DPA or discuss our own assessment?
legal@gitana.io for the DPA; security@gitana.io for security reviews, which we treat as a normal part of the relationship.
Last updated: September 2026