Security Policy

Reporting a Vulnerability

We value the work of security researchers. If you discover a vulnerability, please report it responsibly by emailing [email protected].

How to report:

  • Provide a clear description of the vulnerability.
  • Include steps to reproduce the issue.
  • Explain the potential security impact.

Our commitment:

  • We acknowledge all reports within 48 hours.
  • We aim to resolve critical issues within 14 days.
  • We ask that you do not disclose the issue publicly until we have provided a fix.

Data Security & Privacy

Following our principle of data minimisation, we ensure your Jira data remains within your control.

  • Data storage: All End-User Data (subtask names, descriptions, and templates) is stored exclusively as Jira issue/user properties on Atlassian’s infrastructure.
  • Remote Backend: Our AWS backend does not persist customer-generated data; it only stores installation metadata (atlassian_host) required for the app to function.
  • Data in transit: All connections are encrypted using TLS 1.2+. We enforce HSTS (HTTP Strict Transport Security) with a 1-year max-age.
  • Encryption at rest: All data on our infrastructure is encrypted using AES-256.

Privacy by Design and Privacy by Default

Privacy and data protection are considered from the outset of all design and development decisions, not added retrospectively.

Privacy by Design (DSP-08.1)
The following architectural and development principles are applied to embed privacy into the system by design:

  • Data minimisation at the architecture level: The application does not persist customer Jira content (issue summaries, descriptions, custom fields). This data is processed in memory during subtask creation and discarded. Only installation metadata (atlassian_host) is stored persistently, as required for Atlassian Connect authentication.
  • Private network architecture: ECS Fargate and RDS are deployed in private subnets with no direct internet access. All inbound traffic routes through the ALB over TLS 1.2+.
  • PII excluded from logs at source: Application logging configuration explicitly excludes credentials, tokens, and personally identifiable information. This is enforced in code, not filtered after the fact.
  • Encryption by default: All data at rest is encrypted with AWS KMS AES-256. All data in transit uses TLS 1.2+ enforced at the ALB layer.
  • Least privilege access: IAM roles are scoped to the minimum permissions required. No role has broad data access beyond its specific function.

Privacy by Default (DSP-08.2)
The system is configured to protect privacy without requiring any action from the user or customer:

  • The application collects only the data strictly necessary to deliver its function. No additional data collection is enabled by default.
  • No customer data is shared with third parties beyond the sub-processors documented in the DPA, and only to the extent required to operate the infrastructure.
  • Users are not required to opt out of data collection — minimal collection is the only mode of operation.
  • Security and privacy settings (encryption, network isolation, log sanitisation) are active by default and cannot be disabled by end users.

Application Security

We integrate security into every stage of our development lifecycle.

  • Authentication: All API endpoints require Atlassian Connect JWT validation.
  • Access Control: We verify active licenses on every request and apply rate limiting to prevent abuse.
  • Input Validation: All user-supplied data (field lengths, project keys, etc.) is validated via Regex and strict length checks.
  • Security Headers: We use modern security headers, including CSP, HSTS, Referrer-Policy, Permissions-Policy, CORP, and X-Content-Type-Options.

Vulnerability Management

We use a multi-layered scanning approach to identify and remediate risks.

  • Static Analysis (SAST): SpotBugs and FindSecBugs are integrated into our Maven build process.
  • Dependency Scanning (SCA): We use OWASP Dependency Check, Trivy, and Dependabot to monitor third-party libraries and container images.
  • Dynamic Analysis (DAST): ZAP active scanning is performed against our OpenAPI specs in CI/CD.
  • Remediation Policy: We remediate all HIGH and CRITICAL CVEs identified by our scanning tools before release, where technically feasible. In cases where a fix requires a dependency upgrade blocked by third-party compatibility constraints (e.g., Atlassian Connect frameworks), the CVE is tracked, risk-assessed, and mitigated by alternative security controls until the constraint is resolved.

Infrastructure & Operations

  • Hosting: Our infrastructure is hosted exclusively on AWS eu-west-1 (Ireland).
  • Internal Security: MFA is mandatory for all accounts accessing AWS, source code repositories, and internal systems.
  • Workstation Protection: Full disk encryption is enforced on all development workstations.
  • Logging: Security event logs are maintained for 12 months to support incident investigation. We do not log credentials, tokens, or PII.

Incident Response

In the event of a security incident or data breach:

Supported Versions

Security fixes and patches are applied to the latest published version of the app only. We strongly recommend that customers keep their Jira instance updated to the current version of the app to ensure all security protections are active.

Third-Party Services

  • AWS: Infrastructure hosting in the EU (Ireland) region. AWS Security Practices.
  • Atlassian: Jira platform provider; all End-User Data is stored exclusively as Jira properties on Atlassian’s infrastructure.

Last updated: 24th of March 2026

Scroll to Top