Every control in the catalogue is tested by exactly one of four detection methods, called lanes. The lane is part of the control’s definition, so the same control is always tested the same way, and the evidence it produces always says where it came from.
Live URL probe
20 controls, tested from the outside against your production URL in the way any visitor could: transport security and HSTS, security headers, whether the public client key can read protected tables, whether admin routes are reachable without a role, whether error pages leak stack traces, whether source-control metadata is served, whether a privacy policy is reachable.
The probe runs in under a minute and its evidence expires after 24 hours. It is available on every plan.
Repository host
3 controls, read from your repository host’s security alerts: whether secret scanning reports no secret in the history, whether dependency alerts are on, and whether no alert is open past its window. The open alerts themselves become findings, each with a window taken from the severity the host reports.
Your coding tool
49 controls, tested by Claude Code, Cursor or Windsurf running against your own code on your own machine. Each control has a verification prompt that names the requirement it satisfies and tells the tool exactly what to look for. The tool reads the code, reasons about it, and returns a verdict: verified with the evidence, or failed with the location of the problem.
The verdict is bound to the commit it was checked at. Change the code and the evidence lapses. Nothing is uploaded: VibeLock receives the verdict and the reasoning, never the code.
This is where most of the catalogue lives, and it is the signal that reaches the requirements a probe cannot see: ownership checks on every object access, row level policies, parameterised queries, webhook signatures, token validation, prompt-injection defences. It is available on Starter and above.
Cross-checks
5 controls that compare a document you publish with what is actually verified. Your privacy policy promises erasure; is the erasure control verified? It names sub-processors; do they match your stack? Your runbook claims to cover your components and the 72-hour notification clock; does it? A promise the application does not keep is a failed control, and the finding it produces is the one you forward to your lawyer.
How far each signal reaches
- Nothing connected
- 11 of 56 Level 1 requirements met on the reference profile: only the provider-owned controls count.
- Probe only
- 21 of 56.
- Probe and repository
- 22 of 56.
- Plus your coding tool
- 56 of 56.
- All four signals
- Every Level 2 requirement a signal can reach.
These are ceilings, not results: they are what each signal could reach if everything it tested passed. They are the reason the coding-tool signal is the first thing to run after the probe.