Full Audit
The complete workflow across a repository: map first, select only applicable hypotheses, hunt in parallel lanes, verify independently, fix root causes, prove regressions, gate the release.
The instruction
A full audit is the widest run: it maps the whole repository, resolves applicability across all 21 families, and ends at a release decision. The instruction below is the one the framework documents.
Use SecHelix for a complete authorized security audit of this repository.
Start STATIC. If a safe local runtime is available, continue in LOCAL.
Do not skip attack-surface mapping or applicability.
Run specialist review in parallel where useful, independently verify High/Critical candidates,
fix root causes, add regression tests, retest, and produce the final release gate.Two clauses matter more than the rest. Do not skip mapping or applicability stops the agent from pattern-matching the codebase against a generic vulnerability list. Independently verify stops the agent from grading its own work.
Specialist lanes
Seventeen model-neutral role profiles are defined in the repository. A full audit uses whichever lanes the attack surface justifies; it does not activate all of them by default.
| Lane | Primary ownership |
|---|---|
| Surface mapper | Architecture, identities, assets, entrypoints, data flows, trust boundaries |
| Auth | Authentication, sessions, recovery, MFA, federation |
| AuthZ | Object and function authorization, BOLA and BFLA, roles, tenant isolation |
| Injection and web | SQL, command, template, and DOM injection, XSS, CSRF, redirects |
| SSRF and file parser | Outbound requests, uploads, paths, archives, parser boundaries |
| Business logic | Workflow and state-machine abuse outside payment-specific accounting |
| Payments and accounting | Money, refunds, payouts, currencies, ledger and reconciliation invariants |
| Race and idempotency | Concurrency, retries, duplicate work, TOCTOU, outcome-unknown handling |
| Database, RLS, migrations | Database authorization, row policies, constraints, functions, migrations |
| Browser and extension | Client and server bundles, DOM, origins, extension boundaries |
| Supply chain | Dependencies, lockfiles, packages, build inputs, provenance |
| CI/CD and cloud | CI identities, workflows, deployments, cloud policy, runtime configuration |
| AI, MCP, agent | Agent identity, prompts, tools, MCP authorization, untrusted context |
| Privacy and logging | Data minimization, telemetry, redaction, retention |
| Independent verifier | Blind reconstruction and active refutation of candidates |
| Remediation reviewer | Canonical root-cause repair, preservation of accounting truth |
| Regression and release verifier | Regression proof, neighbouring tests, release-readiness evidence |
Fast triage variant
When the goal is a quick read rather than a release decision, triage keeps the evidence rules and drops the exhaustive coverage pass.
Use SecHelix for a security triage of this repository.
Prioritize authentication, authorization, business logic, secrets, injection/SSRF/files,
supply chain, dangerous configuration, and AI/MCP surfaces.
Return only evidence-backed candidates and clearly mark anything unproven.Wording that works
Asking an agent to find vulnerabilities optimises for finding count, which is the wrong objective. The framework recommends this phrasing instead:
Use SecHelix to identify and independently verify security boundary failures
in this authorized repository. Optimize for evidence and low false-positive rate,
not finding count.That sentence captures the core contract: claims must survive verification before they become findings.
Cost and parallelism
- Partition by paths, boundaries, or state machines. Do not ask every lane for a repository-wide scan.
- A mapper may fan out read-only work once the scope and graph are stable.
- Heavy scanners and full test suites run centrally or under an explicit resource budget.
- Only one remediation lane owns a file at a time, and no agent mutates the release tree during certification.
- New evidence can send a candidate back to the owning specialist, but it must not bypass verification.