Forge security review
The Forge Skills Plugin bundles several Forge-focused skills plus MCP-backed tooling so your agent can scaffold apps, review them before deploy, debug production issues, and stay current on Forge APIs and the Atlassian Design System.
npx -y skills add atlassian/forge-skills --skill forge-security-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 18 stars18 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Performs a white-box security review of Atlassian Forge apps using structured, Forge-specific security rules and evidence-driven reporting. Use when the user asks for a Forge security review, security audit, vuln assessment, pentest-style code review, authz review, tenant isolation analysis, web trigger hardening, or static analysis execution for a Forge app.
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
6.6 KB, as published. Nobody here has run it
Forge Security Review
Runs a Forge-focused white-box security review and reports validated findings with exploitability, impact, evidence, and remediation guidance.
Token-Efficient Default
Use manifest-driven routing by default to reduce token usage. Do not load every rule file up front.
Rule Assets
The review rules are packaged with this skill under assets/security-rules/:
- Global baseline:
assets/security-rules/_global-forge.mdc - Category indexes:
assets/security-rules/forge-*/_index-*.mdc - Category deep checks:
assets/security-rules/forge-*/*.mdc
Execution Mandate
When this skill is triggered:
- Run static analysis first from this skill directory:
scripts/run_static_analysis.sh <forge-project-root-directory>- use
.ps1script for windows
- Read
manifest.ymlfirst before any deep code review. - Load
assets/security-rules/_global-forge.mdcfirst. - Load only relevant category index rules based on manifest and code signals.
- Load deep subrules only when the matching detection heuristics are triggered by real code patterns.
- Perform an evidence-based security review across:
- AuthN/AuthZ
- Injection and input validation
- Tenant isolation and cross-tenant leakage
- Secrets and storage
- Egress/remotes/CSP and manifest permissions
- Public entry points (web triggers)
- Agent and miscellaneous Forge security risks
- Do not modify app code unless the user explicitly requests fixes.
- Write all scan outputs and generated artifacts to
security-audit-artifacts/.
Rule Routing Workflow
Phase 1: Reconnaissance (Mandatory)
Read manifest.yml first and extract:
permissions.scopespermissions.external.fetchpermissions.content.scriptsmodules(resolver/webtrigger/scheduledTrigger/rovo/etc.)remotesapp.runtime.name
Build an execution map:
- UI modules -> bridge calls -> resolvers/functions
- External entry points (web triggers, events, schedules)
api.asUser()vsapi.asApp()paths- Outbound fetch destinations
Phase 2: Index Rule Selection (Two-Tier Loading)
Always load first:
assets/security-rules/_global-forge.mdc
Then load only relevant category index rules:
| Signal | Load |
|---|---|
Any meaningful scope usage, mutations, or asApp() usage | assets/security-rules/forge-authn-authz/_index-authn-authz.mdc |
webtrigger or scheduledTrigger modules | assets/security-rules/forge-webtrigger-entrypoints/_index-webtrigger-entrypoints.mdc |
permissions.external.fetch or remotes | assets/security-rules/forge-egress-remotes/_index-egress-remotes.mdc |
| SQL APIs or untrusted input reaching resolver sinks | assets/security-rules/forge-injection/_index-injection.mdc |
| Multi-tenant patterns, module/global state, cache reuse | assets/security-rules/forge-tenant-isolation/_index-tenant-isolation.mdc |
| Credentials/tokens/secrets handling | assets/security-rules/forge-secrets-storage/_index-secrets-storage.mdc |
| Unsafe CSP or likely scope/config misconfiguration | assets/security-rules/forge-manifest-config/_index-manifest-config.mdc |
| Rovo modules/actions | assets/security-rules/forge-rovo-agents/_index-rovo-agents.mdc |
| Baseline logging/error/static analysis concerns | assets/security-rules/forge-auditing/_index-auditing.mdc |
| Dependency/package risk review | assets/security-rules/forge-misc/_index-misc.mdc |
Subrule policy:
- After reading an index, load only the subrules that match the detection heuristics observed in code.
- Do not pre-load every subrule in a category.
Phase 3: Analysis and Verification
For each loaded category:
- Enumerate reachable entry points.
- Trace source -> validation/authz -> sink.
- Confirm exploitability with evidence.
- Score confirmed findings with CVSS v3.1.
Focused Review Mode
If the user asks for a narrow review (for example, only authz), load:
- Global baseline
- Requested category index
- Only matching subrules in that category
Still mention any obvious critical findings observed outside scope.
Review Workflow
- Build an execution map:
- UI Kit/Custom UI entry points
- Bridge invocations and resolver handlers
api.asUser()/api.asApp()call paths- External egress/remotes and trigger entry points
- For each finding, trace source -> validation/authz -> sink.
- Validate exploitability before classifying as a confirmed vulnerability.
- Keep non-exploitable hardening observations in a separate "needs validation" section.
- Provide file-level evidence and practical test leads for each issue.
Static Analysis Mode
If the user asks for a full scan, run the complete workflow from:
assets/security-rules/forge-auditing/static-analysis-forge.mdc
Expected tools (when available): Semgrep, npm audit, Snyk, gitleaks.
Output Requirements
- Provide a markdown security audit report.
- Order confirmed exploitable findings by CVSS v3.1 severity and impact.
- Include for each confirmed finding:
- CVSS vector and base score
- Severity band
- Exploitability and impact
- File evidence and source-to-sink trace
- CWE mapping
- Reproducible PoC/test steps with concrete commands
- Include assumptions and evidence gaps.
- Do not report scanner counts only when vulnerabilities exist.
Example Trigger Phrases
- "Review this Forge app for security"
- "Do a white-box security audit of my Forge app"
- "Check this app for authz bypass and tenant isolation issues"
- "Run full static analysis for this Forge codebase"