Update to Tahr Security

{
  "name": "tahr-threat-model-app",
  "description": "Build a full, implementation-backed threat model of an entire existing application, covering actors, assets, trust boundaries, entrypoints, hop-level data flows, abuse cases, connected attack paths, security invariants, control gaps, risk responses, and executable validation handoffs. Use for comprehensive system threat modeling, security architecture assessment, pentest preparation, or correlating a complete application repository with configuration, IaC, API schemas, diagrams, and deployment documentation. Do not use for a feature-only, diff-only, or design-only review.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 314
    },
    {
      "relative_path": "assets/threat-model.schema.json",
      "size_in_bytes": 60851
    },
    {
      "relative_path": "assets/threat-model.template.json",
      "size_in_bytes": 93256
    },
    {
      "relative_path": "references/full-review-workflow.md",
      "size_in_bytes": 9285
    },
    {
      "relative_path": "references/specialist-handoffs.md",
      "size_in_bytes": 6587
    },
    {
      "relative_path": "references/threat-evidence-and-quality-gates.md",
      "size_in_bytes": 8131
    },
    {
      "relative_path": "references/threat-model-ledgers.md",
      "size_in_bytes": 11898
    },
    {
      "relative_path": "references/worked-example.md",
      "size_in_bytes": 4021
    },
    {
      "relative_path": "scripts/build_repository_manifest.py",
      "size_in_bytes": 7800
    },
    {
      "relative_path": "scripts/render_threat_model.py",
      "size_in_bytes": 19987
    },
    {
      "relative_path": "scripts/validate_threat_model.py",
      "size_in_bytes": 62382
    }
  ],
  "skill_md_contents": "---\nname: tahr-threat-model-app\ndescription: Build a full, implementation-backed threat model of an entire existing application, covering actors, assets, trust boundaries, entrypoints, hop-level data flows, abuse cases, connected attack paths, security invariants, control gaps, risk responses, and executable validation handoffs. Use for comprehensive system threat modeling, security architecture assessment, pentest preparation, or correlating a complete application repository with configuration, IaC, API schemas, diagrams, and deployment documentation. Do not use for a feature-only, diff-only, or design-only review.\n---\n\n# Tahr Threat Model App\n\nModel the entire existing application as an attacker would. Use source and\nconfiguration for observed implementation, documents for intended behavior,\nand runtime evidence only when the exact target and test are authorized.\nProduce a decision and validation plan, not a code-smell list and not a\nverified-vulnerability report.\n\n## Load the operating contract\n\nBefore modeling:\n\n1. Read [full-review-workflow.md](references/full-review-workflow.md) for the\n   end-to-end sequence and completion gates.\n2. Read [threat-model-ledgers.md](references/threat-model-ledgers.md) for the\n   canonical record relationships and exact enums.\n3. Read\n   [threat-evidence-and-quality-gates.md](references/threat-evidence-and-quality-gates.md)\n   before accepting threats, risk ratings, or a complete status.\n4. Read [specialist-handoffs.md](references/specialist-handoffs.md) before\n   assigning validation work to another Tahr skill.\n5. Use [worked-example.md](references/worked-example.md) only when the expected\n   evidence-to-test trace is unclear.\n\nUse [threat-model.template.json](assets/threat-model.template.json) as the\nstarting structure and [threat-model.schema.json](assets/threat-model.schema.json)\nas the output contract. Do not invent a different report structure.\n\n## Establish full-application scope\n\nRecord the repository path and revision, packages, services, clients,\ndeployment environments, supplied specifications and documents, excluded\nthird-party internals, runtime authorization, previous model, and unanswered\nquestions. Keep `mode` equal to `full`.\n\nCover every admitted first-party application component. If time, access, or\nmissing evidence prevents full coverage, preserve the complete inventory,\ndisposition each gap, and set `model_status` to\n`incomplete_high_risk_coverage`. Never silently narrow a full review.\n\nKeep these concepts separate:\n\n- `model_status`: whether the declared full scope has been dispositioned;\n- `assurance_status`: whether conclusions are source-observed or also\n  runtime-validated;\n- `risk`: plausible impact and likelihood of a modeled threat;\n- `confidence`: strength and completeness of supporting evidence;\n- `execution_status`: whether a validation test is only planned or has an\n  authorized result.\n\nA source-observed model may be `complete` while validation tests remain\n`planned`, provided runtime validation was not part of the declared scope and\nall implementation evidence was dispositioned. Express the limitation through\n`assurance_status`; do not misuse coverage status to imply a test ran.\n\nDefault to read-only analysis. Do not test production, third parties, real\ntenants, or real accounts without explicit authorization. Redact credentials,\ntokens, keys, personal data, and customer data from every artifact.\n\n## Inventory before judging\n\nBuild a coverage baseline from all first-party files and supplied evidence.\nInspect source, manifests and lockfiles, configuration, CI/CD, IaC, containers,\nAPI and GraphQL schemas, database models, tests, diagrams, role matrices,\nworkflows, integration notes, and deployment documents. Map:\n\n- human, service, worker, administrator, support, peer, tenant, and third-party\n  actors;\n- critical business, identity, authorization, financial, operational, privacy,\n  audit, and secret assets;\n- clients, APIs, services, workers, queues, data stores, caches, renderers,\n  control planes, AI systems, and external integrations;\n- public, internal, administrative, legacy, debug, webhook, job, CLI,\n  upload/download, import/export, socket, serverless, and mobile entrypoints;\n- authentication, session, authorization, owner/tenant policy, validation,\n  serialization, secrets, logging, rate, quota, and recovery controls;\n- deployment, network, process, tenant, role, provider, browser, device, and\n  asynchronous trust boundaries.\n\nGroup routes and files into capabilities and business workflows. Retain exact\nlocations as evidence, but do not turn the report into a route-by-route review.\nAccount for each high-signal item in `coverage`.\n\nFreeze a deterministic repository manifest before review. Bind its embedded\ncontent hash to the immutable revision and reconcile its admitted paths, packages,\nenvironments, documents, and exclusions with metadata. Populate\n`coverage.inventory.expected_subject_ids` from that inventory before changing\nany coverage item from `pending`; never shrink the expected set to make a\nreview pass.\n\nCreate the manifest in the selected threat-model output directory:\n\n```bash\npython3 <skill-directory>/scripts/build_repository_manifest.py \\\n  path/to/application --include . \\\n  --output path/to/output/repository-manifest.json\n```\n\nAdd repeated `--include` and `--exclude` arguments when scope is more precise.\nPass `--revision` for an immutable VCS/release revision; when omitted, the\nscript derives `snapshot-sha256:<digest>` from the admitted bytes. Copy its\nembedded revision and content hash (also printed by the script) into metadata,\n`coverage.inventory.manifest`, and manifest evidence. Use explicit empty arrays\nfor documents or exclusions when there are none; do not omit those scope fields.\n\nWhen the reachable surface is non-trivial and `$tahr-map-attack-surface` is\navailable, send it the frozen revision and scope before deriving threats, then\nreconcile its inventory into this model rather than treating its output as a\nsecond source of truth. If that companion skill is unavailable, perform the\nsame stable inventory locally using this section; do not block or narrow the\nreview.\n\n## Build an evidence-backed graph\n\nRecord material facts as claim-level evidence. Use exactly `observed`,\n`intended`, `inferred`, or `unknown`; never combine classes in one field.\n\nFor every sensitive or state-changing flow, model each hop from the initiating\nactor to the final response, durable state, or side effect. At each hop record:\n\n- source, destination, protocol, input, and affected assets;\n- actor, user, service, owner, tenant, role, and policy context;\n- trust boundary crossed;\n- validation, serialization, authentication, authorization, and logging\n  controls;\n- queues, workers, callbacks, redirects, repositories, providers, tools,\n  browsers, and other continuation points.\n\nDo not stop at a controller when another component performs the security\ndecision. Include data creation, replication, retention, deletion, backup,\nresidency, and third-party handling where material.\n\n## Derive material threats\n\nFor each critical asset and flow:\n\n1. State the security invariant.\n2. Define a realistic actor, goal, preconditions, boundary, abuse steps,\n   affected assets, and business impact.\n3. Locate observed and intended controls and their enforcement points.\n4. Search for the strongest contradiction in middleware, policy, service,\n   repository, serializer, validator, framework, IaC, or deployment controls.\n5. Reject, narrow, or mark the threat `validation_required` according to the\n   contradiction result.\n6. Rank risk with an explicit rationale and keep confidence separate.\n7. Assign a response, decision, owner, next action, residual risk, and\n   validation test.\n\nUse STRIDE as a completeness prompt, not as evidence or a requirement to emit\none threat per category. Use ASVS, OWASP API, GraphQL, privacy, mobile, or AI\ntaxonomies only to find omissions and map controls. Retain only threats that\nconnect to the implementation-backed graph.\n\nBuild attack paths only from connected model IDs. Mark uncertain steps\nconditional; do not invent a hop merely to make a chain more severe.\n\nKeep the canonical model proportional to the application. Reuse a control,\ninvariant, decision, or validation test across related threats when the\nenforcement point, owner, and discriminating oracle are genuinely the same.\nKeep claim statements short and reference stable IDs instead of copying the\nsame narrative. Do not create reciprocal records solely to make the artifact\nlook complete.\n\nIf no candidate survives the evidence, contradiction, and materiality gates,\nleave `threats`, `attack_paths`, `decisions`, `validation_tests`, and\n`questions` empty. Preserve the populated inventory, graph, implemented\ninvariants and controls, evidence, coverage, and independent challenge. Never\ninvent a low-value threat or test to avoid an empty ledger.\n\n## Add applicable specialist analysis\n\nWhen personal or regulated data is present, trace collection, linkability,\nidentifiability, detectability, disclosure, consent/awareness, retention,\ndeletion, residency, and third-party processing.\n\nWhen LLMs, agents, RAG, embeddings, MCP, prompts, memory, providers, or tools\nare present, trace prompt injection, retrieval and memory isolation, tool\nauthorization, confused-deputy paths, output trust, provider disclosure,\nsupply-chain changes, evaluation bypass, and wallet/quota abuse.\n\nWhen a lane is not applicable, record `applicable: false` with evidence. Do not\ninvent threats merely to populate a taxonomy.\n\n## Create executable validation handoffs\n\nCreate a validation test for every material uncertain, missing, or potentially\nbypassable control. Include the target Tahr skill, authorization required,\nsafe environment, fixtures, preconditions, normal baseline, exact action,\nexpected control, `attacker_case.attacker_success_signal` and\n`expected_denial_signal`, `control_case.control_success_signal` and\n`control_failure_signal`, evidence, cleanup, destructive risk, confidence, and\ncurrent execution status.\n\nTreat each test as `planned` until authorized evidence proves otherwise. Never\nconvert a proposed test into a finding. Route the test to the specialist named\nin [specialist-handoffs.md](references/specialist-handoffs.md).\n\n## Challenge before publishing\n\nRun a separate adversarial quality pass after producing the draft and before\npublishing it. Use an independent subagent when available; otherwise use a\nfresh, explicitly separate review pass. Give the reviewer the draft model and\nsource evidence, not the desired conclusions.\n\nRequire the reviewer to challenge missing assets, actors, boundaries, flow\nhops, contradictory controls, unsupported impact, inflated risk, route-review\ndrift, unhandled documentation, incomplete coverage, weak actions, broken\nreferences, and non-executable tests. Record findings and their dispositions in\n`quality_review.challenge_findings`.\nResolve every high-severity review finding or keep the review and model failed.\nThe reviewer must not silently rewrite the model it is judging.\n\n## Validate and render\n\nFor a durable model, write only to a user-selected output directory or a\nclearly named `tahr-threat-model-output/` directory. Never modify application\nsource during the review.\n\nValidate before presenting the model as final:\n\n```bash\npython3 <skill-directory>/scripts/validate_threat_model.py \\\n  path/to/threat-model.json --strict\n```\n\nFix validation failures, rerun the independent challenge when material model\ncontent changes, and validate again. Then render concise views:\n\n```bash\npython3 <skill-directory>/scripts/render_threat_model.py \\\n  path/to/threat-model.json --output-dir path/to/output --strict\n```\n\nThe renderer produces `threat-model.md`, `validation-plan.json`, and\n`coverage.json` from the canonical model. Do not edit derived files as though\nthey were independent sources of truth.\n\n## Deliver concise-first results\n\nLead with:\n\n1. model and assurance status;\n2. the five most important connected attack paths or threats;\n3. blocking security decisions and their owners;\n4. the first five validation tests;\n5. high-risk coverage gaps.\n\nPlace complete ledgers after that summary or in the canonical JSON artifact.\nAvoid repeating the same threat narrative in every section.\n\nNever conclude that the application is secure. A clean full model means only\nthat no additional material modeled risks were identified within the stated,\ncompleted evidence scope. Preserve assumptions, limitations, accepted risks,\npending tests, and a review date so future changes can update the model rather\nthan starting over.\n"
}