Security policy

1. Scope and ownership

This policy applies to Asymm Systems (Pvt) Ltd, a company in Sri Lanka with about 5 people, and to all of its products:

• Eliya, our OpenJDK distribution. Product detail: Eliya security.
• Dial. Product detail: Dial.
• Asymm Forensics. Product detail: Asymm Forensics.
• The Jira Governance Suite (CascadePlan, LedgerSeal, DefinitionGuard and FourRealities). Product detail: compliance and security mapping.

The product pages hold the product detail. This page states the rules that apply to the company and to every product.

The security contact is [email protected].

2. Information security

• Multi-factor authentication is on for every company account: the GitHub organisation, email, Atlassian and Cloudflare.
• Passwords are kept in a password manager. Each password is strong and used for one account only.
• Endpoint protection: our Linux workstations run ClamAV.
• Patching: we keep operating systems and software up to date with security updates.
• Least privilege: each person gets only the access their work needs. We review access each quarter and remove what is no longer needed.

3. Secure development

• Review: every change is made on a branch, and an independent review of the change is done before it is merged.
• Continuous integration: automated tests and a dependency audit run in CI. For the Jira apps (Atlassian Forge) the audit is npm audit; a high or critical finding fails the build.
• OWASP Top 10: changes are reviewed against the OWASP Top 10 risks.
• Secrets: secrets are never stored in code. The Jira apps keep their secrets as encrypted Forge environment variables.

4. Signing keys

LedgerSeal and DefinitionGuard sign some of their records with Ed25519. Each signing key has a key id, and each signed record names its key id.

• Rotation: we rotate each signing key every 12 months, and at once if we suspect that a private key is exposed. The first scheduled rotation is in December 2026.
• Publication: the public keys, with their key ids and fingerprints, are on the signing keys page.
• Retired keys: a retired public key stays published, so that evidence signed with it can still be checked.

Eliya releases are signed with a GPG key. Its fingerprint and the channels that publish it are on the Eliya security page.

5. Reporting a vulnerability

Email [email protected]. Do not report a vulnerability in a public issue. Tell us the product and version, the steps that show the problem, and any fix you suggest.

• Acknowledgement: within 72 hours.
• Fix: we target a fix for a critical vulnerability within 30 days.
• Jira apps: we follow Atlassian's Security Bug Fix Policy for Marketplace apps. Its time frames are shorter than 30 days for critical and high vulnerabilities, and where they are shorter they apply.

Vulnerabilities in upstream OpenJDK go to the OpenJDK Vulnerability Group, as the Eliya security page explains.

6. Incident response

When we find or are told of a security incident, we follow these steps:

1. Detect: record the report or the alert and when it arrived.
2. Contain: stop the harm, for example by revoking access or rotating a key.
3. Assess: find the cause, what data and which customers are affected, and since when.
4. Notify: tell the affected customers. For the Jira apps, also tell Atlassian, as its app security incident management guidelines for Marketplace Partners require.
5. Fix: remove the cause and release the fix.
6. Review: after the incident, review what happened and change what let it happen.

We tell affected customers without undue delay, and within 72 hours of confirming a breach of their personal data.

7. Data handling

The Jira apps run on Atlassian Forge. Asymm Systems operates no external servers for them, and the apps call only Atlassian's own APIs: your site's Jira and Confluence, and Atlassian's personal data reporting service. The privacy policy states what each app stores and how it is deleted.

Updates to this policy

Changes to this policy are recorded in the git history of this website.