Feature-Forge creates its own security skills inspired by Trail of Bits methodologies. We adapt their thinking patterns into skills that frame how our agents approach security work.
Key distinction: We do NOT invoke Trail of Bits plugins. We create our own skills that embody similar methodologies.
Feature-Forge includes five security-focused skills:
| Skill | Inspired By | Purpose |
|---|---|---|
| deep-context | ToB audit-context-building | Ultra-granular analysis before vulnerability hunting |
| threat-model | STRIDE methodology | Systematic threat enumeration |
| footgun-detection | ToB sharp-edges | Identify dangerous defaults and API misuse |
| variant-hunt | ToB variant-analysis | Find similar bugs after initial discovery |
| fix-verify | ToB fix-review | Verify fixes address root cause |
Methodology: Build deep architectural context through ultra-granular code analysis BEFORE vulnerability hunting.
How to think:
- Analyze line-by-line / block-by-block
- Apply First Principles, 5 Whys, 5 Hows at micro scale
- Map insights → functions → modules → entire system
- Identify invariants, assumptions, flows, reasoning hazards
Output includes:
- Trust boundary mapping
- Attack surface identification
- Data flow analysis
- Assumption documentation
- Invariant tracking
NOT for:
- Vulnerability findings (context only)
- Fix recommendations (context only)
- Exploit reasoning (context only)
- Severity/impact rating (context only)
Methodology: STRIDE-based systematic threat enumeration.
| Threat | Description | Key Question |
|---|---|---|
| Spoofing | Impersonating something/someone | Can identity be faked? |
| Tampering | Modifying data or code | Can data be changed? |
| Repudiation | Denying actions taken | Can actions be traced? |
| Information Disclosure | Exposing protected information | Can data leak? |
| Denial of Service | Denying or degrading service | Can service be disrupted? |
| Elevation of Privilege | Gaining unauthorized access | Can permissions be exceeded? |
How to think:
- Identify assets (what we're protecting)
- Map actors (who interacts with the system)
- Draw trust boundaries (where trust changes)
- For each boundary crossing, apply STRIDE
- Assess likelihood and impact
- Propose mitigations
Methodology: Identify error-prone APIs, dangerous configurations, and designs that enable security mistakes.
How to think:
- Model the adversary (what mistakes could be made?)
- Probe edge cases (what happens with unexpected input?)
- Check defaults (are they secure by default?)
- Evaluate pit-of-success (is the safe path the easy path?)
Key questions:
- Is this API misuse-resistant?
- Are defaults secure?
- Can users accidentally create vulnerabilities?
- What happens if this is used wrong?
Methodology: Find similar vulnerabilities after discovering an initial issue.
How to think:
- Start specific (understand the exact bug)
- Generalize the pattern (what makes this vulnerable?)
- Build queries (CodeQL, Semgrep, grep patterns)
- Search codebase systematically
- Stop at 50% false positive rate (diminishing returns)
When to use:
- After discovering a vulnerability (hunt variants)
- After fixing a bug (ensure no similar bugs)
- When a CVE affects patterns in your code
- During systematic security sweeps
Methodology: Verify that fixes actually address security findings without introducing regressions.
How to think:
- Understand the original vulnerability (root cause)
- Analyze the fix (what changed?)
- Verify root cause addressed (not just symptoms)
- Check for regressions (did fix break anything?)
- Look for incomplete fixes (all variants covered?)
Differential analysis:
- Compare before/after behavior
- Test original exploit vector
- Check related code paths
- Verify test coverage of fix
Security skills are used at multiple points in the workflow:
Security Context Phase:
- security-analyst uses deep-context to build trust boundaries and attack surfaces
- Produces
security-context.md
Architecture Phase:
- All design specialists consider security in their domain
- security-analyst available for consultation
Security Review Phase:
- security-analyst uses footgun-detection to review architecture
- Identifies dangerous defaults, API misuse potential
- Produces
hardening-review.md
Triage Phase:
- security-analyst uses threat-model to enumerate threats
- architect + security-analyst prioritize for v1
- Produces
triage.json
Review Phase:
- reviewer (security) uses deep-context for thorough analysis
- Contributes to
findings.json
Remediation Phase:
- remediator uses variant-hunt to find related issues
- remediator uses fix-verify to validate fixes
- Updates
findings.jsonwith verification status
The Security Context phase produces security-context.md:
---
phase: security-context
status: complete
trust_boundaries: 5
attack_surfaces: 8
critical_assumptions: 3
---
# Security Context
## Trust Boundaries
[Where trust changes in the system]
## Attack Surfaces
[Entry points, exposed interfaces]
## Data Flows
[Sensitive data movement through the system]
## Invariants & Assumptions
[What must remain true for security]
## Reasoning Hazards
[Non-obvious security implications]The Security Review phase produces hardening-review.md:
---
phase: hardening
status: complete
issues_identified: 5
severity_high: 1
severity_medium: 3
severity_low: 1
---
# Hardening Review
## Critical Issues
[Must fix before implementation]
### Issue 1: [Title]
- **Risk:** [What could go wrong]
- **Recommendation:** [How to fix]
## Medium Priority
[Should fix, prioritized by risk]
## Low Priority
[Nice to have, can defer]
## Accepted Risks
[Documented decisions to accept certain risks]The Triage phase produces triage.json:
{
"v1_requirements": [
{
"id": "SEC-001",
"threat_category": "spoofing",
"description": "Implement JWT validation",
"priority": 1,
"source": "threat-model"
}
],
"deferred": [
{
"id": "SEC-005",
"description": "Add rate limiting to all endpoints",
"reason": "Low immediate risk, can add in v1.1"
}
],
"accepted_risks": [
{
"id": "RISK-001",
"description": "Timing attacks on comparison",
"justification": "Low likelihood, would require significant resources",
"review_date": "2026-04-01"
}
]
}Review produces findings.json, which is updated during remediation:
{
"findings": [
{
"id": "FIND-001",
"type": "security",
"severity": "high",
"description": "SQL injection in user search",
"location": "src/api/users.ts:42",
"status": "fixed",
"fix_commit": "abc123",
"verification": {
"root_cause_addressed": true,
"regression_check": "pass",
"variants_checked": true,
"verified_by": "remediator",
"verified_at": "2026-01-22T16:00:00Z"
}
}
]
}UNDERSTANDING
│
└── security-analyst (deep-context)
│
▼
security-context.md
DESIGN
│
├── specialists (consider security in domain)
│
├── security-analyst (footgun-detection)
│ │
│ ▼
│ hardening-review.md
│
└── security-analyst + architect (threat-model)
│
▼
triage.json [HUMAN CHECKPOINT]
EXECUTION
│
├── reviewer/security (deep-context)
│ │
│ ▼
│ findings.json
│
└── remediator (variant-hunt, fix-verify)
│
▼
findings.json (with verification)
A key design principle: security skills are reusable tools, not one-time phases.
| Skill | Used In |
|---|---|
| deep-context | Security Context, Review, any deep analysis |
| threat-model | Triage, whenever threats need enumeration |
| footgun-detection | Security Review, API design review |
| variant-hunt | Remediation, after any bug discovery |
| fix-verify | Remediation, after any fix implementation |
This means the security-analyst agent can apply these skills whenever the orchestrator determines they're needed, not just at predetermined phases.