playbooks

home / skills / davila7 / claude-code-templates / security-threat-model

security-threat-model skill

/cli-tool/components/skills/security/security-threat-model

This skill helps perform repository-grounded security threat modeling for the codebase, enumerating assets, trust boundaries, abuse paths, and mitigations with

This is most likely a fork of the security-threat-model skill from openai
npx playbooks add skill davila7/claude-code-templates --skill security-threat-model

Review the files below or copy the command above to add this skill to your agents.

Files (5)
SKILL.md
5.4 KB
---
name: "security-threat-model"
description: "Repository-grounded threat modeling that enumerates trust boundaries, assets, attacker capabilities, abuse paths, and mitigations, and writes a concise Markdown threat model. Trigger only when the user explicitly asks to threat model a codebase or path, enumerate threats/abuse paths, or perform AppSec threat modeling. Do not trigger for general architecture summaries, code review, or non-security design work."
author: openai
---

# Threat Model Source Code Repo

Deliver an actionable AppSec-grade threat model that is specific to the repository or a project path, not a generic checklist. Anchor every architectural claim to evidence in the repo and keep assumptions explicit. Prioritizing realistic attacker goals and concrete impacts over generic checklists.

## Quick start

1) Collect (or infer) inputs:
- Repo root path and any in-scope paths.
- Intended usage, deployment model, internet exposure, and auth expectations (if known).
- Any existing repository summary or architecture spec.
- Use prompts in `references/prompt-template.md` to generate a repository summary.
- Follow the required output contract in `references/prompt-template.md`. Use it verbatim when possible.

## Workflow

### 1) Scope and extract the system model
- Identify primary components, data stores, and external integrations from the repo summary.
- Identify how the system runs (server, CLI, library, worker) and its entrypoints.
- Separate runtime behavior from CI/build/dev tooling and from tests/examples.
- Map the in-scope locations to those components and exclude out-of-scope items explicitly.
- Do not claim components, flows, or controls without evidence.

### 2) Derive boundaries, assets, and entry points
- Enumerate trust boundaries as concrete edges between components, noting protocol, auth, encryption, validation, and rate limiting.
- List assets that drive risk (data, credentials, models, config, compute resources, audit logs).
- Identify entry points (endpoints, upload surfaces, parsers/decoders, job triggers, admin tooling, logging/error sinks).

### 3) Calibrate assets and attacker capabilities
- List the assets that drive risk (credentials, PII, integrity-critical state, availability-critical components, build artifacts).
- Describe realistic attacker capabilities based on exposure and intended usage.
- Explicitly note non-capabilities to avoid inflated severity.


### 4) Enumerate threats as abuse paths
- Prefer attacker goals that map to assets and boundaries (exfiltration, privilege escalation, integrity compromise, denial of service).
- Classify each threat and tie it to impacted assets.
- Keep the number of threats small but high quality.

### 5) Prioritize with explicit likelihood and impact reasoning
- Use qualitative likelihood and impact (low/medium/high) with short justifications.
- Set overall priority (critical/high/medium/low) using likelihood x impact, adjusted for existing controls.
- State which assumptions most influence the ranking.

### 6) Validate service context and assumptions with the user
- Summarize key assumptions that materially affect threat ranking or scope, then ask the user to confirm or correct them.
- Ask 1–3 targeted questions to resolve missing context (service owner and environment, scale/users, deployment model, authn/authz, internet exposure, data sensitivity, multi-tenancy).
- Pause and wait for user feedback before producing the final report.
- If the user declines or can’t answer, state which assumptions remain and how they influence priority.

### 7) Recommend mitigations and focus paths
- Distinguish existing mitigations (with evidence) from recommended mitigations.
- Tie mitigations to concrete locations (component, boundary, or entry point) and control types (authZ checks, input validation, schema enforcement, sandboxing, rate limits, secrets isolation, audit logging).
- Prefer specific implementation hints over generic advice (e.g., "enforce schema at gateway for upload payloads" vs "validate inputs").
- Base recommendations on validated user context; if assumptions remain unresolved, mark recommendations as conditional.

### 8) Run a quality check before finalizing
- Confirm all discovered entrypoints are covered.
- Confirm each trust boundary is represented in threats.
- Confirm runtime vs CI/dev separation.
- Confirm user clarifications (or explicit non-responses) are reflected.
- Confirm assumptions and open questions are explicit.
- Confirm that the format of the report matches closely the required output format defined in prompt template: `references/prompt-template.md`
- Write the final Markdown to a file named `<repo-or-dir-name>-threat-model.md` (use the basename of the repo root, or the in-scope directory if you were asked to model a subpath).


## Risk prioritization guidance (illustrative, not exhaustive)
- High: pre-auth RCE, auth bypass, cross-tenant access, sensitive data exfiltration, key or token theft, model or config integrity compromise, sandbox escape.
- Medium: targeted DoS of critical components, partial data exposure, rate-limit bypass with measurable impact, log/metrics poisoning that affects detection.
- Low: low-sensitivity info leaks, noisy DoS with easy mitigation, issues requiring unlikely preconditions.

## References

- Output contract and full prompt template: `references/prompt-template.md`
- Optional controls/asset list: `references/security-controls-and-assets.md`

Only load the reference files you need. Keep the final result concise, grounded, and reviewable.

Overview

This skill performs repository-grounded threat modeling for codebases or specific project paths. It enumerates trust boundaries, assets, attacker capabilities, realistic abuse paths, and targeted mitigations, then writes a concise Markdown threat model anchored to evidence in the repo. Trigger this skill only when you explicitly ask to threat model a codebase, directory, or application component.

How this skill works

I scan the specified repo root or in-scope path and extract the system model: components, entrypoints, data stores, and runtime vs CI/dev surfaces. I enumerate trust boundaries, list sensitive assets, and infer realistic attacker capabilities from exposure and intended deployment. I produce a short set of prioritized abuse paths (threats), justify likelihood and impact, call out assumptions, ask 1–3 clarifying questions if needed, and produce a final repository-rooted Markdown threat model file.

When to use it

  • You explicitly ask to threat model a repository or specific project path.
  • You request enumeration of threats, abuse paths, or AppSec-focused attack scenarios for the codebase.
  • You want prioritized, evidence-anchored mitigations tied to concrete files/components.
  • You need a concise threat model suitable for engineering or security review.
  • You need help deciding which mitigations to implement first based on likelihood/impact.

Best practices

  • Provide the repo root and any in-scope subpaths and confirm intended deployment (CLI, server, library, cloud).
  • Share known auth/identity, exposure (internet-facing or internal), and data sensitivity to reduce assumptions.
  • Review and answer 1–3 follow-up questions I’ll ask to validate attacker capabilities and environment.
  • Treat the output as a living artifact: re-run after major architecture or dependency changes.
  • Use my concrete mitigations tied to components as tasks in your backlog rather than generic security tasks.

Example use cases

  • Threat model the CLI tool that configures and monitors Claude Code to identify secrets, RPC endpoints, and agent behaviors that could be abused.
  • Model a specific service directory to find trust boundaries between local CLI, remote control plane, and any cloud integrations.
  • Prioritize mitigations when the repo exposes credentials, telemetry, or model config that could be exfiltrated or modified.
  • Validate a proposed deployment (internet-facing vs internal) and get attacker capability adjustments and resultant priority changes.
  • Produce a concise Markdown threat model file named <repo-or-dir>-threat-model.md for security reviews.

FAQ

Will you run automatically on any repo?

No. I only run when you explicitly ask me to threat model a repository or path. I will not trigger for general architecture summaries or non-security tasks.

How do you handle unknown deployment details?

I state explicit assumptions that drive threat prioritization and ask 1–3 targeted questions. If you can’t answer, I mark recommendations as conditional and show how assumptions affect priority.