Security Policy

1. Platform & hosting

Contextra Secure Field is a Forge app: its backend logic, storage, and UI surfaces all run on Atlassian-operated infrastructure, inside Atlassian's Forge sandbox. Contextra Labs does not host, operate, or have direct access to any server, container, or database behind this app.

The app's manifest declares no external domains for the core product. It makes no network call to any Contextra Labs endpoint or third-party service — not for analytics, error reporting, telemetry, licensing, or any other purpose.

The security of the underlying compute, network, and physical infrastructure is governed by Atlassian's own security program, including encryption in transit and at rest, applied uniformly to all Forge apps and to Jira itself.

2. The core guarantee: the raw value is never Jira's own data

An ordinary Jira custom field's value is the field's own data, readable by anyone with issue-view permission through Jira's REST API, independent of what the field's own UI hides. Secure Field's schema value is limited, at the platform level, to { v, hasValue, updatedAt } — a version number, a boolean, and a timestamp. There is no property in the field's own schema that could contain, or point to, the actual secret. This is enforced by the app's own manifest, not left to convention.

The encrypted value itself lives in Forge's key-value store, reachable only through this app's own resolver — never through Jira's generic field-read APIs.

3. Encryption

• AES-256-GCM, an authenticated encryption mode — a corrupted or tampered ciphertext fails its authentication check rather than silently decrypting to garbage.
• Encryption and decryption happen only inside the resolver, on Atlassian's backend infrastructure — never in the browser.
• By default, the app generates and manages the encryption key itself, inside Forge's own storage. Optionally, a field can be configured to use a customer-supplied key ("bring your own key") instead — see the note on irreversibility in the Privacy Policy and Terms & EULA.

4. Access control & permission scopes

The app requests only the Forge scopes it needs to function, and nothing broader:

• read:jira-work — resolve the issue's assignee, reporter, creator, project and project lead for allow-list decisions
• read:jira-user — resolve the calling user's group and project-role membership for the same checks
• write:jira-work — write the field's own {v, hasValue, updatedAt} marker, and clear a migrated field's original value
• read:servicedesk-request — resolve JSM request-participant membership
• storage:app — read and write the app's own Forge key-value store: encrypted values, configuration, and the audit log

End-user identity and session handling are entirely Atlassian's: the app never sees a password, session token, or API credential for the underlying Jira account, and never implements its own authentication. Every action runs under Forge's own invocation context, scoped to the calling user and site.

Every reveal and edit re-derives the caller's permission from Jira's own APIs, on every single request — never from anything the client claims. The same allow-list check runs whether the request came from the intended UI or was sent to the resolver directly, closing the standard "the UI hid the button, so it must be safe" gap. The migration wizard (section 6) carries an additional, separate check: it requires the caller to hold Jira's own site-administrator permission, verified server-side.

5. Audit logging

Every reveal, every edit, and every denied attempt is written to an append-only log — there is no code path in this app that updates or deletes an existing entry. Audit-log visibility is governed by its own allow-list, independent of who can reveal the value itself, so it can be granted to an auditor or project lead without also granting them the secret.

6. The migration wizard's specific safeguards

Migrating values in from an existing plain field is a two-phase, admin-only operation with safeguards beyond the ordinary allow-list model:

• Copy, never move — the original field's value is untouched by the copy phase; nothing about copying can lose data.
• Requires Jira administrator permission, checked server-side on every call to either phase — not inferred from which screen the request happened to come from.
• The destructive phase is gated behind the actual result of the copy phase — an issue that failed to copy, or had nothing to copy, can never be selected for the clear step.
• Requires an exact typed confirmation phrase, not a checkbox, before the irreversible clear step runs.
• Every step — copy, clear, and any denied attempt — is written to the audit log.

7. Data storage & isolation

Encrypted values, per-field configuration, and the audit log are all stored in Forge's key-value store, a bucket Atlassian provisions per installation and isolates from every other app and every other site's installation. Nothing is cached or buffered outside that store by the app itself.

8. Licensing & subscription checks

Licence status is supplied by Atlassian and checked before any state-changing action (saving or revealing a value, changing configuration, or running the migration wizard). The app does not operate its own licence server or store licence data outside Atlassian's platform.

9. Vulnerability management

Dependencies are kept current and the app is rebuilt against the latest supported Forge runtime; the underlying platform patching (Node runtime, sandbox, infrastructure) is handled by Atlassian as part of the Forge managed environment. Contextra Labs reviews and applies security-relevant Forge platform advisories as they are published.

10. Reporting a vulnerability

If you believe you've found a security issue in Contextra Secure Field, please report it privately to support@contextra-labs.com rather than filing a public issue. Include steps to reproduce and, where possible, the affected Forge app version. We aim to acknowledge reports within two business days and will keep you informed as we investigate and remediate.

Please do not access, modify, or exfiltrate data belonging to a site you do not control while testing — use a test site you own or one where you have explicit authorization.

11. Incident response

Should a security incident affecting this app be identified, Contextra Labs will investigate, take reasonable steps to remediate, and notify affected customers without undue delay where the incident materially affects their data, consistent with our obligations under the Terms & EULA. Because the app holds no infrastructure of its own outside Atlassian's platform, most infrastructure-level incidents are disclosed and handled directly by Atlassian's Trust Center.

12. Changes to this policy

Material changes will be published on this page with an updated effective date, and noted in the app's release notes.

13. Contact

support@contextra-labs.com

See also the Privacy Policy and Terms & EULA for Contextra Secure Field for Jira.