Effective Date: May 5, 2026
This Partner Security Policy describes how we prevent, detect, respond to, and learn from security issues across our Atlassian Marketplace apps built on Atlassian Forge. It is intended for customers’ security, risk, and compliance reviewers; procurement teams; and Atlassian administrators.
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
Atlassian operates the underlying cloud platform and Forge runtime. We manage app code, configuration, and our operational processes. Customers retain responsibility for Jira/Confluence permissions, project configurations, and administrative controls within their Atlassian tenant.
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