Host product
Jira or Confluence identity, permissions, and authorized context.
Every permission needs a reason, scope, and owner.
This page describes the security standard expected for future addly apps. It does not turn concepts into audited products and claims no certification that has not been obtained.
Guiding principle
Request the minimum, explain every access, respect host permissions, and document uninstall behavior.
Four layers, four responsibilities.
A Forge app does not become secure merely by being close to the host. Every boundary remains named and testable.
Application
Scopes, access controls, input validation, and secrets.
Optional services
Authentication, encryption, logging, and subprocessors.
Operations
Access reviews, vulnerability management, and incident response.
Intended permissions, never presented as a real manifest.
| Concept | Read | Write | Expected control |
|---|---|---|---|
| Readiness for Jira | Read the issue context | Write only app-owned states | Alignment with the published manifest |
| Portfolio Insights | Read selected projects | Write only view preferences | Alignment with the published manifest |
| Page Summary | Read the current page | Write only macro configuration | Alignment with the published manifest |
| Context Linker | Read the current page | Read Jira only for accessible projects | Alignment with the published manifest |
Report a vulnerability
The future channel must be private, acknowledged quickly, and separate from functional support. No SLA is invented here; the production procedure still needs publication.
View the escalation pathEvidence to attach
- 01Forge manifest and scope justification.
- 02Secret inventory and rotation.
- 03Threat model and trust boundaries.
- 04Deletion and uninstall procedure.
- 05Publishable security-fix history.
Useful security is app-specific.
Open the documentation for the selected concept to connect permissions, configuration, and data to the behavior that is actually demonstrated.