Security Swarm: Fix Vulnerabilities at Scale
Opulent fans an agentic map-reduce across your repositories, builds a threat model, validates real vulnerabilities, and opens fix PRs with regression evidence.
Define the security swarm playbook
Connect GitHub for code access and Sentry for runtime signals. The swarm is a playbook, a reusable, named set of steps that runs in parallel across repositories and files, then reduces the findings into validated, fixable vulnerabilities.
The playbook defines what to look for, how to validate a finding, when to stop and ask a human, and what evidence a fix PR must include.
Playbook: !security-swarm Phase 1: Map - Build a threat model for each repo: entry points, auth flows, data stores, dependencies, and trust boundaries. - Identify high-risk surfaces: file uploads, URL builders, SQL builders, eval/serialization, auth middleware, webhook handlers. Phase 2: Hunt For each high-risk surface, search for patterns associated with: - SQL injection (unparameterized query builders) - Path traversal (user input in fs paths without sanitization) - SSRF (user input in outbound URLs) - Auth bypasses (missing checks, weak comparison) - Unsafe deserialization (JSON.parse of untrusted data into classes with methods) - DoS (unbounded loops, regex with catastrophic backtracking) Phase 3: Validate - For each candidate, trace whether user input reaches the sink. - Attempt a minimal, safe reproduction in a test harness. - If exploitation is confirmed, mark Confirmed. If uncertain, mark Needs Review. Phase 4: Fix - For Confirmed findings, open a PR with: - Root cause explanation - Safe minimal fix - Regression test that fails before the fix and passes after - Evidence of validation (test output, stack trace, Sentry link) - Never merge a security fix without human review. Phase 5: Reduce - Aggregate findings across repos into a report: severity, affected files, fixed files, and remaining risks.
Launch parallel hunting sessions
Opulent fans out one run per repository or one run per vulnerability class, depending on the size of the estate. Each run reads the code, builds a local threat model, searches for patterns, and reports candidates with file paths and line numbers.
Parallel hunting is the map step. It must not modify code yet; the reduce step decides which candidates are real and which are false positives.
Swarm split: Repo: payment-service - Focus: SQL injection, unsafe deserialization in webhook handlers. Repo: file-service - Focus: path traversal in upload/download routes. Repo: notification-service - Focus: SSRF in webhook delivery, auth bypass in API keys.
Validate and fix a finding
When Opulent finds a candidate, it attempts a safe reproduction. For SQL injection, it builds a parameterized query test. For path traversal, it creates a test that passes a malicious path and checks whether the file system resolves outside the upload directory.
If the test fails before the fix and passes after, the finding is validated. Opulent opens a PR with the fix, the test, and a description of the exploitation path.
Finding: path traversal in upload handler
File: src/routes/uploads.ts:42
Issue: req.query.filename is joined to UPLOAD_DIR without
normalization.
Validation test:
it('rejects path traversal in filename', () => {
const res = request('/upload?filename=../../etc/passwd');
expect(res.status).toBe(400);
});
Result: fails before fix, passes after fix.
Fix PR: #312, sanitize filename with path.basename and reject
directory separators.Review and merge fixes safely
Security fixes need careful review. Opulent's PR includes the regression test and validation evidence so a human can verify the exploit path and the fix without recreating the bug. Merge only after review.
After merging, run the regression test in CI and monitor Sentry for any new errors introduced by the change. The swarm report tracks which findings are fixed, which are accepted risks, and which need deeper review.
Sharpen the security swarm loop
When a finding is a false positive, add the pattern to an ignore list or to the playbook's stop rules. When a new exploit class appears in your stack, add a hunt module. After each swarm, update the threat model with new services and dependencies.
Schedule the swarm quarterly or after major dependency upgrades. The natural chain: when a vulnerability needs a broader code change, use Fleet-Wide Maintenance Across Thousands of Repositories; when it appears in production, use Debug a Bug Report End-to-End; when it should block merges going forward, use Auto-Fix PR Bugs Before Merge.