feat: initial open marketplace with llm-security, config-audit, ultraplan-local
This commit is contained in:
commit
f93d6abdae
380 changed files with 65935 additions and 0 deletions
176
plugins/llm-security/templates/archive/threat-model-report.md
Normal file
176
plugins/llm-security/templates/archive/threat-model-report.md
Normal file
|
|
@ -0,0 +1,176 @@
|
|||
# Threat Model: [System Name]
|
||||
|
||||
<!--
|
||||
TEMPLATE USAGE
|
||||
This is the output template for `/security threat-model`.
|
||||
The threat-modeler-agent uses this as a formatting guide — fill every section with real findings
|
||||
from the 5-phase interview workflow. Do NOT output placeholder text. If a section is not
|
||||
applicable, write "Not applicable — [brief reason]."
|
||||
-->
|
||||
|
||||
**Date:** [today's date]
|
||||
**Scope:** [brief system description from Phase 1]
|
||||
**Frameworks:** STRIDE + MAESTRO 7-Layer + OWASP LLM Top 10 (2025) + OWASP Agentic Top 10 (2026)
|
||||
**Status:** Advisory — AI-generated. Requires review by a qualified security practitioner.
|
||||
|
||||
---
|
||||
|
||||
## 1. System Description
|
||||
|
||||
[2-4 sentence description of what the system does, who uses it, and how it is deployed.
|
||||
Derived from Phase 1 interview answers.]
|
||||
|
||||
---
|
||||
|
||||
## 2. Architecture Overview
|
||||
|
||||
[Text-based architecture diagram from Phase 2 component mapping, with trust boundaries marked.]
|
||||
|
||||
---
|
||||
|
||||
## 3. MAESTRO Layer Mapping
|
||||
|
||||
| Layer | Components Present | Attack Surface Rating |
|
||||
|-------|-------------------|----------------------|
|
||||
| L1 Foundation Models | [models used] | [Low/Medium/High] |
|
||||
| L2 Data and Knowledge | [knowledge files, state files] | [...] |
|
||||
| L3 Agent Frameworks | [hooks active, permission model] | [...] |
|
||||
| L4 Tool Integration | [MCP servers, Bash, filesystem] | [...] |
|
||||
| L5 Agent Capabilities | [commands, agents, skills] | [...] |
|
||||
| L6 Multi-Agent Systems | [pipelines, delegation patterns] | [...] |
|
||||
| L7 Ecosystem | [plugins, integrations, CI/CD] | [...] |
|
||||
|
||||
---
|
||||
|
||||
## 4. Threat Catalog
|
||||
|
||||
### Layer [X] — [Layer Name]
|
||||
|
||||
#### Threat [X.1]: [Short threat title]
|
||||
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
| STRIDE | [S/T/R/I/D/E] |
|
||||
| OWASP | [LLM0X or ASI0X] |
|
||||
| Likelihood | [1-5] — [rationale] |
|
||||
| Impact | [1-5] — [rationale] |
|
||||
| Risk Score | [L×I] — [Critical/High/Medium/Low] |
|
||||
| Wild Exploitation | [Yes/PoC/No] — [cite source if yes] |
|
||||
|
||||
**Attack scenario:** [Concrete description of how this threat plays out in this system.]
|
||||
|
||||
**Current control status:** [Already mitigated / Can be mitigated / Accepted / External]
|
||||
|
||||
**Recommendation:** [Specific, actionable mitigation. Reference the mitigation matrix
|
||||
control type: Automated / Configured / Advisory.]
|
||||
|
||||
---
|
||||
[Repeat for each threat, grouped by MAESTRO layer]
|
||||
|
||||
---
|
||||
|
||||
## 5. Risk Matrix
|
||||
|
||||
| Threat | Layer | STRIDE | OWASP | Score | Priority |
|
||||
|--------|-------|--------|-------|-------|----------|
|
||||
| [Threat title] | L[X] | [category] | [ID] | [score] | [Critical/High/Medium/Low] |
|
||||
|
||||
[Sorted by score descending]
|
||||
|
||||
---
|
||||
|
||||
## 6. Mitigation Plan
|
||||
|
||||
### Critical and High Priority Actions
|
||||
|
||||
| # | Threat | Action | Control Type | Effort |
|
||||
|---|--------|--------|-------------|--------|
|
||||
| 1 | [Threat] | [Specific action] | Automated/Configured/Advisory | Low/Med/High |
|
||||
|
||||
[Sorted by risk priority]
|
||||
|
||||
### Already Mitigated
|
||||
|
||||
| Threat | Control | Evidence |
|
||||
|--------|---------|---------|
|
||||
| [Threat] | [What control] | [File or config that confirms it] |
|
||||
|
||||
### Accepted Risks
|
||||
|
||||
| Threat | Rationale | Owner |
|
||||
|--------|-----------|-------|
|
||||
| [Threat] | [Why accepted] | [Who owns this decision] |
|
||||
|
||||
---
|
||||
|
||||
## 7. Residual Risk Summary
|
||||
|
||||
[2-4 sentences summarizing the overall risk posture after applying recommended mitigations.
|
||||
Identify the highest-impact residual risk and what it would take to address it.]
|
||||
|
||||
**Threat model coverage:** [X] threats identified across [Y] MAESTRO layers.
|
||||
**Critical:** [n] | **High:** [n] | **Medium:** [n] | **Low:** [n]
|
||||
|
||||
---
|
||||
|
||||
## 8. Assumptions and Limitations
|
||||
|
||||
- This threat model is based on information provided in the interview session and file
|
||||
analysis at the time of generation. System changes may invalidate findings.
|
||||
- Threat likelihood ratings reflect the analyst's assessment; actual exploitation depends
|
||||
on attacker capability and motivation not fully modeled here.
|
||||
- External controls (IAM, network policy, model provider security) are noted as dependencies
|
||||
but not verified.
|
||||
- This document is advisory. It does not constitute a security audit or penetration test.
|
||||
Engage a qualified security practitioner before production deployment of high-risk systems.
|
||||
|
||||
---
|
||||
|
||||
*Generated by threat-modeler-agent (llm-security plugin)*
|
||||
*Frameworks: STRIDE · MAESTRO · OWASP LLM Top 10 (2025) · OWASP Agentic Top 10 (2026)*
|
||||
|
||||
<!--
|
||||
RISK SCORING LOGIC
|
||||
|
||||
Risk Score = Likelihood × Impact (both on a 1-5 scale)
|
||||
|
||||
| Score | Priority | Action |
|
||||
|-------|----------|--------|
|
||||
| 20-25 | Critical | Address before deployment |
|
||||
| 12-19 | High | Address in current sprint |
|
||||
| 6-11 | Medium | Schedule for remediation |
|
||||
| 1-5 | Low | Monitor, accept, or defer |
|
||||
|
||||
Likelihood scale (1-5):
|
||||
1 — Theoretical, no known exploitation path
|
||||
2 — Unlikely, requires unusual attacker access
|
||||
3 — Plausible, standard attacker capability
|
||||
4 — Likely, low-cost exploitation
|
||||
5 — Near-certain, trivial or already exploited in wild
|
||||
|
||||
Impact scale (1-5):
|
||||
1 — Minimal — inconvenience, no data loss, easily reversible
|
||||
2 — Low — minor data exposure or disruption, limited blast radius
|
||||
3 — Medium — credential leakage, significant disruption, or reputational harm
|
||||
4 — High — production system compromise, mass credential theft, persistent backdoor
|
||||
5 — Critical — complete system compromise, irreversible data loss, regulatory breach
|
||||
|
||||
CONTROL STATUS CATEGORIES
|
||||
|
||||
- Already mitigated — Evidence exists in the project (hook present, tool restriction in
|
||||
frontmatter, CLAUDE.md scope-guard, gitignore excludes secrets).
|
||||
Cite the specific file.
|
||||
- Can be mitigated — A specific, actionable control exists. State exactly what to do.
|
||||
- Partially mitigated — A control exists but has gaps. Describe what the gap is.
|
||||
- Accepted risk — The threat is real, but the system's constraints make mitigation
|
||||
impractical. Document the decision and the reasoning.
|
||||
- External dependency — Mitigation requires organizational controls outside Claude Code
|
||||
scope (IAM, network policy, vendor security). Note the dependency.
|
||||
|
||||
THREAT COUNT QUALITY GUIDANCE
|
||||
|
||||
5-10 well-described threats with concrete attack scenarios and specific recommendations
|
||||
are more useful than 25 thin entries with generic rationale. Prioritize depth over breadth.
|
||||
Group threats tightly by MAESTRO layer — avoid repeating the same threat class across layers
|
||||
unless the attack vector genuinely differs.
|
||||
-->
|
||||
Loading…
Add table
Add a link
Reference in a new issue