Security Sweep
Replaces "ran one security tool, called it done" with one workflow that runs all of
them in parallel and reconciles findings so duplicates and false positives don't
clutter the actionable list.
Auto-invocation triggers
- User says "security audit", "check for vulns", "is this safe to deploy"
- Quarterly per active repo (manual cadence — not auto-scheduled to avoid noise)
- Before any release of security-sensitive code (auth, payments, PII, file uploads)
- Post-incident as part of
production-incident Phase 6 if the incident was
security-related
Workflow
Phase 1 — Parallel scan dispatch (always)
Invoke in parallel:
security-audit — broad OWASP-style review (secrets, deps, code paths)
socket-audit — npm supply chain (malicious packages, typosquats) — npm only
semgrep — pattern-based scan (custom rules + community packs)
code-security — review of recent diffs for unsafe patterns
Each returns structured findings.
Phase 2 — Reconcile + dedupe (always)
Combine findings into one set:
- Same vulnerability flagged by multiple tools → keep one entry, list which tools
caught it (high-confidence finding)
- Conflicting severity ratings → take the highest
- False positives the user has documented before (read memory) → suppress
Severity ranking:
- CRITICAL — exploitable now, in prod, no mitigation
- HIGH — exploitable but mitigated by other controls, or only on auth paths
- MEDIUM — limited exploitability, fix in the next release
- LOW — best-practice violations, no immediate risk
- INFO — track only
Phase 3 — Remediation plan (always)
For each CRITICAL + HIGH:
- Specific fix with code snippet or command
- Estimated effort (5min / 30min / 2h / day+)
- Recommended skill to apply:
secrets-rotate (if secrets), refactor-pipeline
(if structural), direct edit (if simple)
Sort by impact-per-effort.
Phase 4 — Capture
Write report to ~/.claude/projects/<slug>/memory/security_sweep_<repo>_<date>.md.
Update MEMORY.md index. Trend visible across quarterly runs.
If CRITICAL findings: also create Linear ticket via incident-response (without
the full incident workflow — just ticket creation).
Reconciliation
SECURITY SWEEP — <repo> — <date>
Tools run: security-audit, socket-audit, semgrep, code-security
Total findings: N (after dedup)
CRITICAL (X):
[tool1, tool2] <finding>
Fix: <action>, estimated <effort>
HIGH (Y): ...
MEDIUM (Z): ...
INFO (W): ...
Remediation plan (impact-per-effort sorted):
1. <action> (5min, fixes 1 CRITICAL)
2. <action> (30min, fixes 2 HIGH)
3. <action> (2h, fixes 1 HIGH + 3 MEDIUM)
Linear: <ticket URL if CRITICAL findings>
Memory: <report path>
Outputs / Evidence
- Per-tool raw verdicts
- Reconciled severity-ranked finding list
- Effort-sorted remediation plan
- Memory file for trend tracking
- Linear ticket if CRITICAL
Failure / Stop Conditions
- Any single tool errors → mark partial, continue with the rest
- All tools clean → write a "no findings" memory; clean baseline is itself evidence
- Tool unavailable (e.g., semgrep not installed) → skip + note in report; don't
block the rest
Memory Hooks
- Read prior reports to surface trend (e.g., "secrets-in-config CRITICAL flagged
3 quarters running — structural fix needed")
- Read documented false-positive list to suppress noise
- Write report as primary output
1---2name: security-sweep3description: Composite skill — full security pass across secrets, dependencies, code paths, and OWASP risks. Chains security-audit (broad) + socket-audit (npm supply chain) + semgrep (pattern scan) + code-security (code review for vulns) in parallel, reconciles into one severity-ranked report with remediation plan. Use quarterly per active repo or before any release of security-sensitive code.4---56# Security Sweep78Replaces "ran one security tool, called it done" with one workflow that runs all of9them in parallel and reconciles findings so duplicates and false positives don't10clutter the actionable list.1112## Auto-invocation triggers1314- User says "security audit", "check for vulns", "is this safe to deploy"15- Quarterly per active repo (manual cadence — not auto-scheduled to avoid noise)16- Before any release of security-sensitive code (auth, payments, PII, file uploads)17- Post-incident as part of `production-incident` Phase 6 if the incident was18 security-related1920## Workflow2122### Phase 1 — Parallel scan dispatch (always)23Invoke in parallel:24- `security-audit` — broad OWASP-style review (secrets, deps, code paths)25- `socket-audit` — npm supply chain (malicious packages, typosquats) — npm only26- `semgrep` — pattern-based scan (custom rules + community packs)27- `code-security` — review of recent diffs for unsafe patterns2829Each returns structured findings.3031### Phase 2 — Reconcile + dedupe (always)32Combine findings into one set:33- Same vulnerability flagged by multiple tools → keep one entry, list which tools34 caught it (high-confidence finding)35- Conflicting severity ratings → take the highest36- False positives the user has documented before (read memory) → suppress3738Severity ranking:39- **CRITICAL** — exploitable now, in prod, no mitigation40- **HIGH** — exploitable but mitigated by other controls, or only on auth paths41- **MEDIUM** — limited exploitability, fix in the next release42- **LOW** — best-practice violations, no immediate risk43- **INFO** — track only4445### Phase 3 — Remediation plan (always)46For each CRITICAL + HIGH:47- Specific fix with code snippet or command48- Estimated effort (5min / 30min / 2h / day+)49- Recommended skill to apply: `secrets-rotate` (if secrets), `refactor-pipeline`50 (if structural), direct edit (if simple)5152Sort by impact-per-effort.5354### Phase 4 — Capture55Write report to `~/.claude/projects/<slug>/memory/security_sweep_<repo>_<date>.md`.56Update MEMORY.md index. Trend visible across quarterly runs.5758If CRITICAL findings: also create Linear ticket via `incident-response` (without59the full incident workflow — just ticket creation).6061## Reconciliation6263```64SECURITY SWEEP — <repo> — <date>6566Tools run: security-audit, socket-audit, semgrep, code-security67Total findings: N (after dedup)6869CRITICAL (X):70 [tool1, tool2] <finding>71 Fix: <action>, estimated <effort>7273HIGH (Y): ...74MEDIUM (Z): ...75INFO (W): ...7677Remediation plan (impact-per-effort sorted):78 1. <action> (5min, fixes 1 CRITICAL)79 2. <action> (30min, fixes 2 HIGH)80 3. <action> (2h, fixes 1 HIGH + 3 MEDIUM)8182Linear: <ticket URL if CRITICAL findings>83Memory: <report path>84```8586## Outputs / Evidence8788- Per-tool raw verdicts89- Reconciled severity-ranked finding list90- Effort-sorted remediation plan91- Memory file for trend tracking92- Linear ticket if CRITICAL9394## Failure / Stop Conditions9596- Any single tool errors → mark partial, continue with the rest97- All tools clean → write a "no findings" memory; clean baseline is itself evidence98- Tool unavailable (e.g., semgrep not installed) → skip + note in report; don't99 block the rest100101## Memory Hooks102103- Read prior reports to surface trend (e.g., "secrets-in-config CRITICAL flagged104 3 quarters running — structural fix needed")105- Read documented false-positive list to suppress noise106- Write report as primary output