just-vibeSecurity · plan by default
/security-threat-model
Identify assets, trust boundaries, attack paths, and mitigations
Use for systematic threats to a scoped system; security-authz or security-inputs investigates a concrete path, and security-fix repairs a confirmed vulnerability.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select security-threat-model from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv security-threat-model, /just-vibe security-threat-model and /jv:security-threat-model in Claude. See shortcut setup and context examples.
/just-vibe:security-threat-model Model threats around invoice exports and background processing./just-vibe:security-threat-model Threat-model a tenant export service with signed download links./just-vibe:security-threat-model Model threats from partial architecture without probing live systems.What the agent does
- Enumerate assets, actors, entry points and trust transitions, tracing data and privilege boundaries.
- Model realistic misuse chains and connect each to existing controls and observable impact.
- Prioritize gaps by realistic impact and exposure, with a validation scenario for each.
Inputs
- system architecture, assets, actors, trust boundaries, and critical outcomes.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Plausible attack paths and proportionate mitigations for this system.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.
- Mode
- Plan; system architecture, assets, actors, trust boundaries, and critical outcomes.
- Prerequisites
- Defined application boundary, authorized code/environment, relevant trust/access rules, and evidence sources. Default to defensive inspection; active tests use owned or explicitly authorized isolated targets. Minimize sensitive evidence and never print usable credentials.
Expected output
- Threat model with a boundary diagram, assumptions, threat/control/gap matrix, prioritized mitigations and verification scenarios.
How the work is checked
- A sensitive export path has explicit access/data-handling controls; mitigations map to concrete threats rather than generic checklists.
When to stop or clarify
- Do not claim all threats are covered or infer deployment controls without evidence. Unknown architecture remains a documented gap.
Handling missing context
- Infer
- Resolve the requested surface, source/runtime version, reachable callers and actual trust/access boundaries.
- Assume
- Start with source analysis and bounded owned fixtures; treat scanner output as leads and preserve legitimate controls.
- Ask
- Ask when target authorization or necessary trust semantics are unresolved before active probing; source inspection need not wait for production access.
Technical guidance
- Evidence
- Inventory assets, actors, entry points, trust transitions, deployment assumptions and existing controls.
- Method
- Build source-to-effect attack paths with prerequisites; route relevant paths to the vulnerability and framework guides.
- Pitfall
- A generic OWASP list is not a project threat model, and a hypothetical deployment must not become an observed exposure.
- Check
- Walk a high-impact misuse path and its legitimate control case; distinguish demonstrated, conditional and unknown risks.
Situational decisions
When a threat depends on an unverified deployment assumption: State the condition and required evidence instead of declaring an incident or guaranteed exploit.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.