Your First Audit
A worked first run on a repository you own, with the scope record fields to fill in, what each phase should produce, and how to read the result honestly.
Before you start
Pick a repository you own. A first run should be treated as an experiment, not a gate: the enterprise guidance is explicit that production must not be gated on the first experimental run.
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.Phase 0 — scope
Create a short scope record before hunting. These are the fields the workflow expects.
- Repository and service names.
- In-scope hosts and environments.
- Explicitly out-of-scope systems.
- Available test accounts and roles.
- External providers and their side effects.
- Money, inventory, and customer-data paths.
- Production restrictions.
- Allowed tools.
- Stop conditions.
examples/scope.example.json shows the shape, and schemas/scope-v1.schema.json is the contract it validates against.
Phase 1 — map the system
Mapping produces the inventory the rest of the run depends on. It is built from evidence, not from assumptions about how the framework normally works.
- Entrypoints
- Routes, RPCs, webhooks, workers, cron jobs, queues, browser extensions, CLIs.
- Identities
- Users, admins, sellers, workers, services, agents, API keys, provider accounts.
- Trust boundaries
- Browser to server, tenant to tenant, seller to seller, app to provider, app to database, agent to tool, CI to runtime.
- Sensitive assets
- Secrets, money, payouts, codes, inventory, PII, chat, tokens, admin actions.
- State machines
- Order, refund, fulfillment, assignment, auth and session, listing, payout.
- Persistence
- Tables, caches, object storage, queues, logs.
The phase ends with a role by object by action matrix for every authorization-sensitive domain. See Attack Surface.
Phase 2 — select applicable coverage
The catalog is not run mechanically. Each of the 546 hypotheses is labelled from architecture evidence, and the reason code, capability states, and evidence references are retained.
| Label | Meaning |
|---|---|
APPLICABLE | At least one required architecture capability is evidenced as present. |
NOT_APPLICABLE | Every required capability is explicitly evidenced as absent. |
UNKNOWN | Capability evidence is missing or unresolved. |
BLOCKED | Authorization, environment, access, or a declared constraint prevents a legitimate decision. |
Prioritisation then follows impact and reachability, starting with authentication and session compromise, then authorization and tenant isolation, then money and provider side effects.
Phase 3 — parallel specialist review
Where the host supports subagents or worktrees, review runs in disjoint lanes with explicit ownership. Every hunting profile emits records where status is CANDIDATE and severity is UNASSESSED. A coordinator may add identifiers, but it must not silently convert a candidate into a finding.
- Do not let every lane run a full project suite concurrently. Focused tests per lane, central verification later.
- Deduplicate by root cause, not by title or scanner rule.
- Only one remediation lane owns a file at a time.
- Heavy scanners and full test suites run centrally or under an explicit resource budget.
Phase 11 — verification
The independent verifier receives candidates without being told they are true, reconstructs the path, and classifies each one as VERIFIED, LIKELY_BUT_UNPROVEN, FALSE_POSITIVE, DUPLICATE_ROOT_CAUSE, or BLOCKED_BY_ENVIRONMENT.
For High and Critical candidates the verifier tries to disprove attacker control, reachability, missing guard assumptions, role preconditions, impact, whether the vulnerable state is producible at all, and whether a compensating control already blocks the exploit.
Reading the result honestly
A first run that produces two verified findings and six rejected candidates is a good run. A first run that produces forty findings has almost certainly skipped verification.
- Check that unknown and blocked counts are non-zero and explained. A run that classifies everything usually guessed somewhere.
- Check that each verified finding has a safe reproduction and a named root cause, not just a file and a line number.
- Check that rejected candidates kept their refutation reason. That record is the point of the verification phase.
- Check the retest ran against a built application. A green typecheck is not proof that a browser bundle or production build is valid.