Skip to content
SecHelixv3 alpha
GitHub
DocsContributeSupportWorkbenchGitHub
Getting Started

Quickstart

The five-minute path from install to a release decision: scope, map, select, hunt, verify, fix, regress, retest, report, gate.

1. Install

npx skills@latest add omarmohelal/SecHelix --skill sechelix

Project-local alternatives already exist for Claude Code, Codex, GitHub Copilot, and vendor-neutral skills/ discovery. See Installation for the per-host paths and the compatibility statuses.

2. First run

Use a repository you own or are explicitly authorized to assess. SecHelix is a skill, so the interface is a precise instruction to the coding agent rather than a scanner CLI.

Agent prompt
Run a SecHelix security audit on this repository.
Mode: STATIC first, then LOCAL if the project can be started safely.
Map the attack surface and trust boundaries before hunting.
Use only applicable hypotheses.
Treat scanner/model output as hypotheses, not findings.
Independently verify every High/Critical candidate.
Fix root causes, add regression tests, retest, then produce the release gate decision.

3. Expected lifecycle

  1. installThe skill is discoverable by the host.
  2. scopeTarget, mode, authorization, exclusions, providers, and stop conditions are recorded.
  3. mapEntrypoints, identities, assets, boundaries, and state machines are inventoried.
  4. selectEach hypothesis is labelled applicable, not applicable, unknown, or blocked.
  5. huntSpecialist lanes emit candidates with status CANDIDATE and severity UNASSESSED.
  6. verifyThe independent verifier attempts refutation of every important candidate.
  7. fixRoot causes are repaired at the canonical boundary.
  8. regressA regression test proves the boundary now holds.
  9. retestThe original claim is re-run against the built application.
  10. reportOne canonical report renders to Markdown, JSON, SARIF, and HTML.
  11. gateThe policy gate returns a fail-closed release decision.

4. Focused runs

A full audit is not always what you want. Narrow the instruction and the workflow narrows with it, while the evidence contract stays identical.

Authorization and multi-tenancy
Use SecHelix to audit authorization in this repository.
Build a role × object × action matrix.
Focus on BOLA/IDOR, BFLA, ownership checks, tenant isolation, mass assignment, storage policy, and server-side enforcement.
Use two-user tests in LOCAL/STAGING where safely available.
Release gate only
Run the SecHelix release gate for this repository.
Fail closed if required evidence is missing.
Do not mark UNKNOWN/BLOCKED checks as NOT_APPLICABLE.
List verified blockers, known accepted risks, regression status, and the final PASS / PASS_WITH_KNOWN_RISK / BLOCKED / INCOMPLETE decision.

More recipes live under Using SecHelix, one page per task shape.

5. What you get back

  • A scope record naming the target, the mode, and the authorization basis.
  • An attack-surface inventory including the role by object by action matrix.
  • A coverage summary with applicable, not applicable, unknown, and blocked counts.
  • Verified findings with a complete evidence chain, and rejected candidates with the refutation reason retained.
  • Regression tests for the verified findings that received a fix.
  • A release recommendation: PASS, PASS_WITH_KNOWN_RISK, BLOCKED, or INCOMPLETE.

A useful run leaves enough evidence that another reviewer can reproduce the reasoning without trusting the first model. That is the actual acceptance criterion.

Your First AuditThe same run, phase by phase, with the scope fields to fill in.Report FormatWhat the canonical report contains and how it is rendered.