Security Threat Model

Security Threat Model is an official curated OpenAI skill for Codex. According to the provider, it guides an AI model through a focused application security analysis of a code repository or a clearly bounded project path. The result is not a generic architecture summary or an unstructured checklist. It is an evidence-grounded threat model that explains trust boundaries, assets, attacker capabilities, abuse paths, priorities, and mitigations. The skill is published in the official openai/skills repository under skills/.curated/security-threat-model, and the skill directory includes an Apache License 2.0 license file.

Purpose and Method

The workflow starts by establishing scope. The agent collects the repository or in-scope path, intended usage, deployment model, internet exposure, authentication expectations, and any existing architecture summary. It then derives actual components, entry points, data stores, and external integrations from repository evidence. Runtime behavior is deliberately separated from CI, build, and development tooling, as well as tests and examples. This keeps a development helper or fixture from being mistaken for a production component without supporting evidence.

Trust Boundaries and Assets

A core requirement is to describe concrete trust boundaries between components. Each boundary is considered in terms of protocol, authentication, encryption, validation, and rate limiting. The skill also asks for assets that drive risk, including credentials, personal or confidential data, integrity-sensitive state, availability-sensitive resources, configuration, models, build artifacts, and audit logs. Potential entry points include endpoints, uploads, parsers, decoders, job triggers, administrative tooling, and logging or error sinks. This makes the analysis follow data flows and control edges rather than merely naming vulnerability classes.

Attackers and Abuse Paths

Instead of producing a broad list of theoretical weaknesses, the skill connects realistic attacker capabilities to concrete goals. Those goals can include exfiltration, privilege escalation, integrity compromise, or denial of service. Every threat should identify affected assets, describe a plausible abuse path, and explain qualitative likelihood and impact. Overall priority is derived from those factors and adjusted for existing controls. Assumptions that materially change the ranking must be explicit, so reviewers can challenge the model rather than treating an unexplained severity label as fact.

Evidence and Boundaries

According to the provider, the agent must not invent components, flows, endpoints, or controls. Architectural claims are anchored to repository paths, symbols, configuration keys, or short quoted evidence. Missing information becomes an assumption and an open question. The skill also enforces security hygiene: secrets must never appear in the output. If keys, passwords, or tokens are encountered, the agent should redact them and describe only their presence and location. This preserves analytical value while reducing the risk of leaking credentials into reports or conversation history.

Output and Quality Review

The requested deliverable is a concise Markdown report containing one compact Mermaid flowchart for the primary components and trust boundaries. The report distinguishes existing mitigations from recommendations, ties recommendations to concrete locations and control types, and records residual risk. Before finalizing, the agent checks that discovered entry points and boundaries are covered, runtime and tooling contexts remain separate, assumptions are visible, and the output follows the required contract. According to the provider, the report should be written to a file named after the repository or in-scope directory with the suffix threat-model.md.

Appropriate Use by Teams

This skill is useful for an initial repository-grounded AppSec baseline, security-focused architecture reviews, and preparation for deeper testing. It does not replace an independent security assessment or controlled validation in an isolated environment. Its quality depends on repository completeness, the strength of available architectural evidence, and the accuracy of operational assumptions. The provider explicitly includes a validation step with one to three targeted questions. If those answers are unavailable, the report should retain the unresolved assumptions and explain how they affect prioritization.