Effective Date: ​May 5, 2026

1. Scope and Roles

This policy applies to all Forge-based cloud apps we publish on the Atlassian Marketplace, including Field Radar and other apps listed on our vendor profile. It covers organizational and technical controls, vulnerability management, and incident response.

• Customer data context: Our Forge apps primarily store configuration metadata within Atlassian’s platform; see each app’s Data Security and Privacy Policy for app-specific details.

• 
  

  • Security Lead — overall ownership, incident commander

  • Engineering — secure development, code reviews, remediation

  • Support — intake, customer comms, case tracking

  • Leadership — escalation and regulatory decisions

2. Security Principles

• Platform-first: Leverage Atlassian Forge’s isolation, permission model, and platform-managed data at rest.

• Least privilege: Minimize scopes/permissions and review them before release.

• Privacy by design: Collect and process only what is necessary for functionality.

• Defense in depth: Combine preventive, detective, and responsive controls.

• Transparency: Clear disclosure, timely customer communication, and changelogs.

3. Incident Response

3.1 Definitions

• Security Event: Observable occurrence that may indicate a security issue (e.g., suspicious error spikes, unexpected permissions prompts).

• Security Incident: Confirmed adverse event impacting confidentiality, integrity, or availability of our apps or customer data.

3.2 Intake and Reporting

• External reporting: Email suspected vulnerabilities or incidents to security@almbase.com.

• Internal sources: Support tickets, monitoring alerts, Atlassian Ecosystem notifications, and platform advisories.

• Acknowledgement: We acknowledge external reports within 2 business days.

3.3 Triage and Classification

• Initial assessment (within 24 hours for high/critical): scope, potential impact, affected apps/tenants, and exploitability.

• Severity mapping: Critical, High, Medium, Low based on confidentiality, integrity, and availability impact and ease of exploitation.

• Decision: Contain immediately for Critical/High; proceed to full investigation for all severities.

3.4 Containment, Eradication, and Recovery

• Containment options: Disable impacted functionality, roll back to a safe version, rotate credentials/keys, revoke Forge environments if applicable.

• Eradication: Patch the vulnerable component; remove any malicious artifacts; harden controls to prevent recurrence.

• Recovery: Validate fix in staging; redeploy via Forge with least downtime; monitor closely post-release.

3.5 Communication

• Customer notifications: For material incidents, we notify impacted customers with description, scope, affected versions, required customer actions, and remediation timelines.

• Atlassian coordination: We coordinate with Atlassian Support/Ecosystem when platform-level action or guidance is relevant.

• Status updates: Provided as new facts are confirmed; final notice includes root cause and corrective actions.

3.6 Post‑Incident Review

• Within 10 business days: Document timeline, root cause, lessons learned, and corrective/preventive actions.

• Track actions to completion; verify via follow-up testing and monitoring.

4. Vulnerability Management

4.1 Intake Channels

• Public contact: security@almbase.com and app support channels.

• Advisories: Atlassian security advisories, dependency CVE feeds, and code scanning alerts.

4.2 Verification and Severity

• Reproduce issues in a safe environment; determine affected apps, versions, and impact.

• Severity aligns to industry practices (e.g., CVSS context-adjusted): Critical, High, Medium, Low.

4.3 Remediation Targets

• Critical: fix/deploy as soon as possible; target within 7 days.

• High: fix/deploy within 14 days.

• Medium: plan and deploy within 30–60 days.

• Low: schedule in regular maintenance cycles.

When a full fix requires more time, we implement compensating controls (feature flags, permission tightening, temporary mitigations) and communicate timelines.

4.4 Responsible Disclosure

• We welcome good-faith research. Do not attempt to access data you do not own, disrupt service, or violate laws or Atlassian’s policies.

• We will credit researchers upon request and consent after validation and fix.

5. Technical Controls

5.1 Platform and Architecture

• Forge hosting: Code runs within Atlassian’s Forge runtime with app-level isolation and explicit permission scopes.

• Data storage: Custom Entity Storage managed by Atlassian; no external databases for listed apps.

• No external egress by default: Our apps are designed to avoid outbound network calls unless explicitly documented.

5.2 Data Protection

• In transit: TLS for all traffic between user browsers and Atlassian Cloud; Forge-to-Atlassian services also over TLS.

• At rest: Storage encryption managed by Atlassian’s cloud infrastructure for Forge services.

• Data minimization: Only configuration data necessary for functionality is stored; no tracking of personal behavior.

5.3 Access Control and Secrets

• Principle of least privilege: App scopes restricted to required Jira APIs and entities; periodic review during release.

• Secrets management: Forge-managed environment variables; no hard-coded credentials in code.

• Separation of duties: Code review required for sensitive changes; protected branches and mandatory approvals.

5.4 Secure Development Lifecycle

• Static analysis and dependency scanning as part of CI.

• Threat modeling for new features and permission changes.

• Security checklists for releases; regression tests for previously fixed classes of bugs.

5.5 Logging and Monitoring

• Forge logs and metrics reviewed for anomalous error rates and access patterns.

• Alerting rules for repeated failures, unexpected permission errors, and abnormal usage spikes.

• Access to logs limited to authorized team members for troubleshooting purposes.

5.6 Availability and Change Management

• Progressive rollout where possible; rapid rollback strategy for emergency fixes.

• Release notes for material security-relevant changes.

6. Organizational Controls

• Security ownership: Designated Security Lead and clear escalation path.

• Training: Periodic secure coding and Forge platform security training for engineers.

• Vendor management: We do not use third-party sub-processors for app data. Changes would be documented in app policies prior to adoption.

• Background and access: Principle of least privilege for internal systems; MFA enforced on corporate accounts used for Atlassian Cloud administration.

7. Customer Responsibilities and Shared Model

• Review and approve app scopes during installation or updates.

• Manage user/group/project permissions in Jira to align with least privilege.

• Report suspected security issues to security@almbase.com promptly.

8. Policy Review and Changes

We review this policy at least annually and after material incidents or platform changes. Updates will be posted on this page with an updated Effective Date. For material changes, we will make reasonable efforts to notify affected customers via our Marketplace listing or direct communication channels.

9. Contact

• Security reports and disclosures: security@almbase.com

• General privacy/compliance: apps@almbase.com

Appendix A — Severity Examples

Appendix B — References

Atlassian Forge Data Residency: developer.atlassian.com/platform/forge/data-residency/

• Atlassian Security advisories and practices: atlassian.com/trust