Repository Threat Modeler
Builds evidence-grounded, actionable AppSec threat models for code repositories.
The skill requires repository evidence, explicit scope, attacker-capability limits, and redaction of discovered secrets. It does not define least-privilege file access, confirmation for the requested Markdown write, rollback, or full data-flow disclosure, so points are deducted.
The workflow, output contract, and assumption handling are coherent, and it requires explicit feedback when context is missing. However, there are no scripts, tests, or reproducible execution artifacts; key paths depend on repository context not included here, so the static score is conservative.
Trigger conditions, audience, and non-trigger scenarios are clearly stated for repository AppSec threat modeling. Input-context requirements are substantial, Chinese-language support is unspecified, and handling is limited for inaccessible repositories or unavailable user confirmation, so the score is below full marks.
The skill provides layered documentation, a quick start, phased workflow, reference templates, control checklists, and a defined output contract. Its own materials do not clearly establish per-skill licensing, versioning, changelog, maintenance ownership, or update path, so points are deducted.
The specified output includes concrete abuse paths, prioritization, mitigations, detection ideas, and review paths, which should be directly useful. Actual quality depends on complete repository evidence and user context, and static review cannot verify the resulting artifact, so the score remains below the static ceiling.
Requiring repository-path evidence anchors and a quality checklist provides some auditability. There is no committed test suite, CI coverage, third-party execution evidence, or independent reproduction, so only limited points are warranted.
- The skill requires pausing for context validation; without deployment, authentication, exposure, or data-sensitivity details, conclusions and priorities will depend heavily on assumptions.
- It requires writing the final report to a file but does not specify pre-write confirmation, file permissions, or rollback on failure.
- The instructions and templates are English-only and do not establish Chinese-output quality or mainland-China environment compatibility.
- License, versioning, changelog, and maintenance ownership are incomplete in the supplied skill materials; verify these before adoption.
What it does & when to use it
This is one curated skill in the openai/skills monorepo, located at skills/.curated/security-threat-model/SKILL.md. It is intended only for explicit requests to threat model a codebase or project path. The workflow analyzes trust boundaries, assets, attacker capabilities, entry points, abuse paths, and mitigations using repository evidence. It produces a concise Markdown threat model while keeping assumptions and unresolved context visible.
Collects the repository root, in-scope paths, usage and deployment context; identifies components, data stores, integrations, runtime modes, and entry points from a repository summary; maps concrete trust boundaries and risk-driving assets; describes realistic attacker capabilities and non-capabilities; enumerates a small set of goal-oriented abuse paths; rates likelihood and impact qualitatively; separates evidenced existing controls from recommended mitigations; asks targeted questions about context that affects prioritization; performs a quality check; and writes the final report to a Markdown file named for the repository or in-scope directory.
- An AppSec engineer needs a repository-specific model of entry points, trust boundaries, assets, and realistic attack paths.
- An architect is assessing a service before changing its deployment model, authentication expectations, or internet exposure.
- A development team needs to connect credentials, sensitive data, integrity-critical state, and audit logs to concrete controls.
- A reviewer needs to separate runtime behavior from CI, build, development tooling, tests, and examples.
Pros & cons
- Grounds architectural claims in repository evidence instead of generic checklists.
- Covers boundaries, assets, attacker capabilities, entry points, abuse paths, and mitigations.
- Separates existing controls from recommendations and includes likelihood-impact reasoning.
- Produces a concise, reviewable Markdown deliverable.
- Quality depends on repository evidence and deployment context supplied or available.
- The workflow pauses for user validation when missing context could change prioritization.
- The provided material does not document a test suite, concrete platform coverage, or this skill's license.
- The containing repository is marked deprecated; the README points current Codex skill and plugin examples to the OpenAI Plugins repository.
How to install
The skill is in the repository's curated collection. The README documents installation through Codex with: $skill-installer security-threat-model. Restart Codex after installation so it can load the skill. The provided material does not document another installation method or state this individual skill's license; it says to check LICENSE.txt inside the skill directory.
How to use
In Codex, make an explicit request such as “Threat model this codebase for AppSec” or “Enumerate the trust boundaries, assets, and abuse paths for this project path.” Provide the repository root or scope and, where possible, describe deployment, internet exposure, authentication and authorization, scale, and data sensitivity. The workflow asks for confirmation of assumptions that materially affect ranking; if answers are unavailable, those assumptions remain explicit in the report.