Use security-threat-model for an explicit application-security modeling task. It extracts the system from the repository, then asks where an attacker can enter, what assets are exposed and which boundaries matter. It connects risks to existing controls and proposed mitigations. Deployment and authorization details affect priorities, so you must supply context the code cannot reveal.
Install and prepare
This guide covers the standalone Skill retained in openai/skills. That repository is deprecated and current examples have moved to openai/plugins; the instructions here describe the linked standalone version, not the latest plugin.
Enter this line in the Codex conversation, not a terminal. If the installed Skill does not appear, restart Codex.
$skill-installer security-threat-model
- A readable repository or a clearly bounded directory
- Usage, deployment, internet exposure and authorization context
- A project owner who can confirm material assumptions
Try a first task
For a file-upload service, start here and replace the deployment context with the real situation:
$security-threat-model
Threat-model this repository’s file upload and processing flow. It is a multi-tenant service for business customers with a public upload API. Derive components, data flows and trust boundaries from code and cite paths. Ask me about unknowns that affect prioritization, then produce a Markdown report distinguishing existing controls from recommended mitigations.
Work through the task
-
Build an evidenced system model. Identify runtime components, inputs, stores and integrations. Separate production paths from tests and CI, and do not treat sample code as deployed architecture.
-
Confirm threat conditions. List assets and realistic attacker capabilities, including important non-capabilities. Answer the few context questions needed to calibrate likelihood and impact.
-
Prioritize actionable paths. For a focused set of abuse paths, describe conditions, impact, existing controls and concrete mitigation locations, then write the agreed report.
Use one flow to test whether the model is specific
For a file-upload service, map browser, upload API, object store, processing worker and download route. Mark where authentication, tenant identity and file-format checks occur at each boundary. Then ask whether an attacker could upload arbitrary content, read another tenant’s result or consume excessive processing capacity. Those are paths to investigate, not claims that the code is vulnerable. Require a code location and precondition for each path.
A useful entry is more than a category such as “XSS” or “authorization bypass.” It states attacker starting point, crossed boundary, target asset, observed controls, gap, likely impact and a suggested repair location. If deployment settings or storage permissions are not in the repository, supply the real context. Otherwise keep the relevant severity conditional.
Use the report to plan the next check
Confirm that every important entry point has a corresponding flow, risks are ordered by realistic exposure, and controls seen in code are distinguished from proposed controls. Turn the highest-priority paths into a targeted security test or configuration review. A threat model helps decide where to investigate; it does not execute an attack or validate live permissions.
Another case: multi-tenant exports
If customers can download CSV exports, scope the task as: “Analyze only the export API, background job and object store. A tenant admin may export their own tenant’s data. Trace how tenant identity passes through the request, queue message, storage path and download link. Ask me about deployment permissions and link expiry before ranking the most important cross-tenant access or leak paths.” This examines whether boundaries are enforced without presuming an authorization bug exists. The report should state attacker capability, asset, observed control and suggested repair location for each path. If object-store permissions are absent from the repository, leave them as a named assumption.
Check the result
The default filename uses the repository or target directory name followed by -threat-model.md. Check coverage of important entry points and boundaries, and whether priorities use confirmed deployment facts. Existing controls need code evidence; proposed controls should remain clearly identified as work to do.
Common blockers
Deployment context is missing. Clarify exposure, tenant isolation, authentication and data sensitivity. Keep rankings conditional where answers are unavailable.
Threats are generic. Require a concrete entry point, asset and attacker goal for each, favoring a few clear paths.
Only the README was read. Verify consequential architectural statements in code; documentation is a starting point rather than proof of implementation.
Start from one real data flow
Start with a bounded repository and one path, such as sign-in through access to sensitive data. Have the agent infer components and flows from code, then inspect each trust boundary and threat against the implementation. A practitioner tried this on OWASP Juice Shop in both desktop and CLI and obtained architecture, data-flow, and STRIDE drafts. Use that as a discussion starter; confirm specific vulnerabilities and mitigations against code and deployment.