Security Statement

Last updated: 2026-05-22

⚠️ MANUAL REVIEW REQUIRED — This statement must be reviewed and confirmed accurate against the production deployment before the Atlassian Marketplace listing is submitted. Specific items requiring verification are marked inline.

Infrastructure and data residency​

Attestsys apps process and store all customer data exclusively on Hetzner Cloud infrastructure in Nuremberg, Germany (EU). No customer data is transferred to or stored in the United States or any other non-EU jurisdiction.

• Provider: Hetzner Online GmbH, Nuremberg, Germany
• Certification: BSI C5 Type 2 (German Federal Office for Information Security cloud security attestation), ISO 27001:2022
• Data residency claim: EU only at launch. Customers requiring US or APAC residency must contact us for an Enterprise contract.
• Legal framework: German and EU law only. No US CLOUD Act exposure — Hetzner is a German company with no US parent.

Encryption​

In transit​

All connections between Jira clients (via the Atlassian Forge platform) and the Attestsys backend use TLS 1.2 or higher. The backend API is served at https://api.attestsys.com with HSTS enabled.

At rest​

All data stored on the Attestsys backend is encrypted at rest using AES-256 in GCM mode (envelope encryption for cryptographic key material) and LUKS full-disk encryption on the host server.

⚠️ MANUAL REVIEW REQUIRED — Confirm LUKS is provisioned before this statement goes live. LUKS passphrase management decision is pending (see OPEN-THREADS.md).

Cryptographic key material​

ECDSA private keys (per-tenant signing keys) are stored with AES-256-GCM envelope encryption. The key-encryption key (KEK) is held separately from the wrapped key material. Private keys are loaded into memory only for the duration of a signing operation, then immediately zeroized from memory (set to zero bytes before GC eligibility).

Authentication​

Forge Invocation Token (FIT) validation​

All requests from the Atlassian Forge platform to the Attestsys Forge Remote backend are authenticated using Forge Invocation Tokens (FITs). The backend validates every FIT as a signed JWT against Atlassian's published JWKS endpoint (https://forge.cdn.prod.atlassian-dev.net/.well-known/jwks.json) on every incoming request. Requests with missing, expired, or invalid FITs are rejected with HTTP 401.

This satisfies Atlassian's Cloud Security Requirements for Forge Remote apps (normative "must" language).

Ingestion credentials (HMAC)​

Event ingestion from the Forge app to the backend uses HMAC-based credentials. HMAC keys are:

• Stored with AES-256-GCM envelope encryption at rest
• Never logged
• Compared using constant-time comparison to prevent timing attacks
• Zeroized from memory immediately after use

Operator endpoints​

Sensitive operator-only endpoints (e.g., GDPR tenant erasure) are protected by a separate X-Operator-Token header, held only by the Attestsys operations team and never exposed to customers.

Data egress from Atlassian infrastructure​

Attestsys apps use Forge Remote — Jira event data is forwarded from the Atlassian Forge platform to the Attestsys backend on Hetzner Cloud for cryptographic processing and storage. This constitutes data egress from Atlassian's infrastructure.

What data leaves Atlassian infrastructure:

• Jira event payloads: event type, issue key, actor accountId, timestamp, and changed field values (as produced by Jira's event webhook system)
• Jira workspace identifier (cloudId)

What does not leave Atlassian infrastructure:

• Jira issue descriptions, attachment content, or comment text beyond what the Jira webhook event payload contains

⚠️ MANUAL REVIEW REQUIRED — Confirm the exact data fields in each Jira webhook event payload and update this list accordingly.

All egressed data is processed exclusively on Hetzner Cloud EU infrastructure (see above) and is subject to the Data Processing Agreement.

Because Attestsys uses Forge Remote, the app does not qualify for Atlassian's "Runs on Atlassian" trust badge. We consider EU-only data residency on certified German infrastructure (BSI C5 Type 2 + ISO 27001:2022) to be a stronger trust signal for compliance-focused customers than the RoA badge, which carries no geographic data residency guarantee.

Cryptographic evidence chain security​

The cryptographic evidence chain is an additional security property — not just a product feature. See Cryptographic Verification for full technical detail.

Key security properties:

• Per-entry signing: each audit entry is individually ECDSA-signed (secp256k1, RFC 6979 deterministic)
• Hash chaining: each entry contains the SHA-256 hash of the previous entry's signed payload — any past modification is mathematically detectable
• RFC 3161 trusted timestamping: timestamps are issued by independent accredited timestamp authorities, not by the Attestsys server clock
• Insert-only audit table: chain entries are never updated or deleted — corrections and redactions are appended as new entries, preserving chain continuity
• GDPR erasure compatibility: tenant key erasure tombstones the signing key and appends a signed tombstone entry before key deletion, preserving chain continuity while enabling GDPR compliance

GDPR and data subject rights​

Attestsys acts as a data processor for all customer data. The data controller is the customer (the Jira workspace administrator).

Data subject rights (erasure, access, portability, restriction) are handled as follows:

• Audit chain entries are never deleted in response to data subject requests — deletion would break the cryptographic chain. Instead, a signed redaction marker is appended to the chain
• Personal identifiers in chain entries (Atlassian accountIds) can be identified and reported via the Atlassian Personal Data Reporting API on a cycle of at most 7 days
• Full tenant erasure (key tombstoning + credential revocation) is available on request for GDPR Art. 17 compliance

A full Data Processing Agreement is available on request.

Vulnerability disclosure​

To report a security vulnerability, contact security@attestsys.com.

⚠️ MANUAL REVIEW REQUIRED — A formal responsible disclosure policy should be published before the Marketplace listing. Atlassian requires a security contact to be registered at ecosystem.atlassian.net. Cloud Fortified certification (Phase 6) requires Bug Bounty program enrollment.

Sub-processors​

⚠️ MANUAL REVIEW REQUIRED — Add any email provider, monitoring tool, or other sub-processor used in production before publishing.