Security Policy for Flow Metrics Charts in Jira Cloud

Version: 1.0
Last Updated: January 2026

Use your browser's on-page find, or scroll, to navigate the sections below: Overview, Security Architecture, Data Protection and Privacy, Authentication and Authorization, Secure Coding Practices, API Security, Storage and Caching Security, Dependency Management, Monitoring and Logging, Incident Response, Compliance and Standards, Vulnerability Disclosure, Security Testing, and the Security Controls Checklist.

Overview

Purpose

This security policy defines the security controls, practices, and standards for the Flow Metrics Charts for Jira Cloud application. It ensures the protection of customer data, maintains system integrity, and complies with industry security standards.

Scope

This policy applies to:

• All components of the Flow Metrics Charts application

• Development, testing, staging, and production environments

• All personnel with access to the application codebase or infrastructure

• Third-party dependencies and integrations

Security Principles

Our security approach is built on these core principles:

1. Defense in Depth: Multiple layers of security controls

2. Least Privilege: Minimal permissions required for operation

3. Secure by Default: Security built into design, not added later

4. Privacy by Design: Data protection integrated from the start

5. Zero Trust: Verify explicitly, use least privilege, assume breach

6. Transparency: Clear communication about security practices

Security Architecture

Platform Foundation

Atlassian Forge Platform

The application runs on Atlassian Forge, a secure, serverless platform that provides:

• Isolated Execution Environment: Each app runs in isolation from others

• Managed Infrastructure: Atlassian handles infrastructure security, patching, and updates

• Automatic Scaling: Built-in protection against resource exhaustion

• Runtime Security: Forge runtime provides sandboxed execution

• Built-in Rate Limiting: Protection against abuse and DoS attacks

• Managed Authentication: Forge handles OAuth authentication securely

Security Boundaries

1. Client-Side (Browser)

   • Forge UI Kit enforces XSS prevention

   • Content Security Policy (CSP) restricts resource loading

   • No sensitive data stored in browser storage

2. Forge Runtime

   • Isolated execution environment per app instance

   • Memory and CPU limits prevent resource exhaustion

   • 25-second timeout limit per function execution

   • No direct network access except via Forge APIs

3. Storage Layer

   • Forge Storage API: App-scoped, encrypted at rest

   • Forge SQL: Isolated database per app, parameterized queries only

   • No direct database access from frontend

4. External APIs

   • Only Jira internal APIs accessed via requestJira()

   • No external API calls or egress traffic

   • All requests authenticated via Forge's OAuth mechanism

Data Protection and Privacy

Data Classification

Data Minimization

Principle: We only collect and process data necessary for application functionality.

Implementation:

• Only request issue fields required for metrics calculation

• No collection of personally identifiable information (PII) beyond what Jira already exposes

• No logging of sensitive user data

• Aggregated metrics only (no individual user tracking)

• Cache eviction after 5 minutes for issue data

Privacy Considerations

• User Consent: Users consent via Jira app installation process

• Data Access: Limited to users with existing Jira permissions

• Data Portability: Users can export data via CSV export feature

• Right to Deletion: Uninstalling app removes all data

• Transparency: This security policy provides transparency on data handling

GDPR Compliance

For European customers:

• Lawful Basis: Legitimate interest (providing analytics service)

• Data Subject Rights: Supported via Jira's existing data subject access mechanisms

• Data Protection Officer: Contact via Atlassian Marketplace support

• Data Processing Agreement: Covered under Atlassian's DPA

• Cross-Border Transfers: Data processed within Atlassian's infrastructure per their data residency policies

Authentication and Authorization

Authentication Model

Forge Managed Authentication

The application does not implement custom authentication. All authentication is managed by Atlassian Forge:

1. User Authentication: Users authenticate to Jira Cloud (Atlassian Identity)

2. App Authentication: Forge runtime authenticates app requests via OAuth 2.0

3. API Authentication: All Jira API calls use Forge-managed authentication tokens

Authorization Model

Permission-Based Access Control

The application respects Jira's native permission model:

1. Issue Visibility: Users can only see issues they have permission to view in Jira

2. Project Access: Users must have project access to view project metrics

3. Board Access: Users must have board access to view board-scoped metrics

4. Configuration Access: Only project admins can modify workflow configurations

Scopes and Permissions

Scope Justification:

• read:jira-work: Required to fetch issue data for metrics calculation

• write:jira-work: Required ONLY for custom JQL functions (SQL sync), NOT for modifying issues

• storage:app: Required for caching and configuration storage

• read:jira-user: Required for displaying assignee names in issue lists

• read:servicedesk-request: Required for JSM project support

Session Management

• Session Handling: Managed by Forge platform

• Session Timeout: Follows Jira Cloud session timeout (configurable by org admin)

• Token Refresh: Automatic token refresh handled by Forge

• No Custom Sessions: Application does not implement custom session management

Secure Coding Practices

Input Validation and Sanitization

All inputs are validated before processing, including project keys (regex-validated), JQL query values (escaped), date ranges (validated for format and ordering), and numeric inputs (bounded). Output is encoded by the Forge UI Kit / React layer.

Injection Prevention

• JQL Injection Prevention: JQL values are escaped and parameterized; user input is never concatenated directly into a JQL string.

• SQL Injection Prevention: All SQL uses parameterized, prepared statements with bound parameters; no string concatenation.

• Path Traversal Prevention: All Jira API calls use Forge's route template tag, which handles encoding.

Cross-Site Scripting (XSS) Prevention

• Forge UI Kit automatically escapes all user-supplied content.

• React's JSX escapes values by default.

• No use of dangerouslySetInnerHTML.

• Content Security Policy enforced by Forge.

Error Handling

Errors return generic messages to the client; sensitive data and stack traces are never returned to the client or logged. HTTP status codes are handled explicitly (for example 410 and 404).

Rate Limiting and Abuse Prevention

The Forge platform enforces a 25-second function timeout, per-function memory limits, and built-in API rate limiting. The application adds configuration limits (maximum issues per request, page size, response-size caps) and exponential backoff on HTTP 429 responses.

API Security

Jira API Integration

Secure API access relies on Forge-managed authentication, respecting user permissions via api.asUser(), exponential backoff for rate limits, and graceful HTTP error handling without data leakage.

API Call Patterns

API routes are constructed with the Forge route template tag (which provides automatic URL encoding, path-traversal prevention, and injection prevention). User context (api.asUser()) is used for data retrieval; app context (api.asApp()) is reserved for non-sensitive operations only. Retry logic uses exponential backoff and does not retry authorization/timeout errors.

No External API Calls

The application makes NO external API calls outside Jira. The manifest.yml declares empty external.fetch.backend and external.fetch.client arrays, so no external URLs are permitted.

Storage and Caching Security

Storage Types

Forge Storage API is an app-scoped key-value store, encrypted at rest by Atlassian, used for configuration, cached metrics, and user preferences. Forge SQL Storage is an app-scoped MySQL database, encrypted at rest, used for issue synchronization and historical data, accessed exclusively through parameterized queries.

Caching Strategy

Caching improves performance while maintaining security. Issue cache and changelog cache use a 5-minute TTL; metrics cache uses a 24-hour TTL. Cache keys are base64-encoded and length-limited to prevent key injection, and include the auth mode for isolation. Caches are invalidated automatically by TTL, by manual refresh, and on app upgrade.

Storage Security Best Practices

• Least retention: store only necessary data; use the shortest practical TTL.

• Key sanitization: sanitize all storage keys to prevent key-injection attacks.

• Data isolation: separate caches by authentication mode and include project/board identifiers to avoid cross-tenant leakage.

Dependency Management

Dependency Security Policy

The app uses only trusted, regularly updated dependencies with no known vulnerabilities — six production dependencies, all from Atlassian official SDKs or trusted sources (such as React).

Dependency Security Controls

• Minimal dependencies: only 6 production dependencies; regular review of the dependency tree.

• Auditing: npm audit is run; vulnerabilities are remediated on a severity-based schedule (critical within 24 hours, high within 1 week, medium within 30 days, low in the next release cycle).

• Version pinning: a committed lock file (package-lock.json) is required; lock-file changes are reviewed in PRs.

Prohibited Dependencies

Never include dependencies with known critical vulnerabilities, unmaintained packages (no updates in 2+ years), packages from untrusted sources, packages with malware or suspicious activity, or packages with excessive transitive dependencies.

Monitoring and Logging

Logging Policy

Logging provides visibility for debugging, detects security incidents and anomalies, supports audit requirements, and protects sensitive data in logs.

What We Log and Don't Log

The app logs operational events and errors with context (status, message, endpoint). It never logs authentication tokens or API keys, user email addresses or account IDs (except where strictly necessary for debugging), passwords or secrets, full request/response payloads containing user data, stack traces sent to the client, or other PII.

Log Access and Retention

Logs are accessible via the forge logs command and require an authenticated Forge CLI session limited to app developers. The Forge platform manages retention (typically 7–30 days); the application performs no long-term log archival.

Security Monitoring

Monitored events include authentication failures, unusual activity (excessive API call rates, large data retrieval, repeated errors, timeouts), and security events (input-validation failures, blocked JQL injection attempts, invalid project-key access attempts). Alerting is a manual log-review process.

Incident Response

Incident Response Plan

The objective is to quickly detect, respond to, and recover from security incidents.

Incident Classification

Incident Response Phases

The phases are: detection (via vulnerability reports, Forge alerts, log monitoring, user reports, automated scans); triage and assessment (classify severity, determine scope and impact); containment (disable the app immediately for critical incidents, apply temporary mitigations for high); eradication (identify root cause, develop and test a fix, security-review it, deploy); recovery (deploy to production, verify, re-enable, monitor); and a post-incident review within one week.

Communication Plan

Internally, the development team is notified immediately and High/Critical incidents are escalated to the security lead. Externally, Critical/High incidents are communicated to affected customers via the Atlassian Marketplace, Medium incidents via release notes, and Low incidents via the changelog. Vulnerabilities are disclosed after a fix is deployed.

Compliance and Standards

Compliance Frameworks

The application is designed to support GDPR (data minimization, purpose limitation, storage limitation, data-subject rights, privacy by design), SOC 2, and ISO 27001 — the latter two largely inherited via Atlassian's certifications.

Inherited Compliance

The application inherits infrastructure security, encryption at rest and in transit, physical data-center security, business continuity and disaster recovery, security monitoring, penetration testing, and third-party audits (SOC 2, ISO 27001) from the Atlassian Forge platform. Reference: Atlassian Trust & Security.

Data Residency

Data is processed within Atlassian's infrastructure, follows Atlassian's data-residency policies, and is not transferred across borders outside Atlassian's control.

Vulnerability Disclosure

Responsible Disclosure Policy

We encourage responsible disclosure of security vulnerabilities. Please report vulnerabilities by emailing support@divim.io with the subject "Security Vulnerability Report - Flow Metrics Charts".

What to Include

Please provide a description of the vulnerability, steps to reproduce, a proof of concept (if available), an impact assessment, suggested remediation (if any), and your contact information. Please do not run exploits against production systems, include data from customer installations, or disclose publicly before a fix is available.

Our Commitment

When you report a vulnerability, we commit to acknowledgment within 5 business days, regular updates during investigation, and remediation on a severity-based timeline (critical within 7 days, high within 30 days, medium within 60 days, low within 90 days or the next release). We provide public credit to reporters who wish it; we do not currently operate a paid bug-bounty program.

Out of Scope

The following are not considered vulnerabilities: denial of service (Forge enforces a 25-second timeout), social-engineering attacks, physical attacks, vulnerabilities in Atlassian's infrastructure, issues requiring a compromised Jira administrator account, issues in third-party dependencies (report to the dependency maintainer), and theoretical vulnerabilities without a realistic attack scenario.

Security Testing

Testing Strategy

The objective is to ensure security controls are effective through comprehensive testing: unit security tests (JQL injection prevention, input validation, cache-key sanitization, auth-mode isolation), integration security tests (HTTP error handling, parameterized SQL), BDD security scenarios, and periodic manual testing (injection attempts, path traversal, authorization bypass, rate limiting, error-message validation).

Security Test Coverage

Required coverage includes input validation at all entry points, JQL and SQL injection prevention, path-traversal prevention, authentication/authorization checks, error handling without data leakage, cache-key sanitization, and rate-limiting behavior. Security tests run automatically in the CI/CD pipeline on every commit, alongside dependency vulnerability scanning.

Penetration Testing

External penetration testing is not currently performed; the app relies on Atlassian's security testing of the Forge platform and is open to coordinated security research (see Vulnerability Disclosure). Professional penetration testing and a bug-bounty program are future considerations if the app scales significantly.

Appendix: Security Controls Checklist

This appendix summarizes the implemented controls across authentication and authorization, input validation, output encoding, injection prevention, data protection, API security, storage security, dependency security, monitoring and logging, incident response, testing, and compliance. Each control area above documents the specific safeguards in place.

Document History

End of Security Policy Document