A project in VibeLock represents one application. Everything else, the catalogue, the evidence, the ledger, the Trust Center, belongs to a project, so this is the first thing you create.
Setup asks two things: where the app runs, and what kind of app it is. The URL is what the probe tests. The profile decides which of the 77 controls apply. You are not committing to anything, and you can change every answer later; changing one recomputes applicability and the ledger.
The eight profile facts
- User accounts
- Whether people log in. Turns on the authentication, session and per-user access controls.
- Managed auth
- Whether a managed authentication provider runs your login. Eight authentication controls become provider-owned: they count as verified once the probe has seen the provider in your served app, and you are not asked to test them.
- Hosted backend
- Whether the browser talks to a hosted database directly with a public client key. Turns on the two controls that check row-level policies and that the public key cannot read protected tables.
- Payments
- Turns on the controls about trusting the client with amounts and verifying webhook signatures.
- Sensitive data
- Health, financial or similarly sensitive personal data. Turns on field-level protection, logging and minimisation controls.
- EU users
- Turns on the application-level GDPR articles: consent, erasure, portability, and the EU AI Act transparency duties where an AI feature also ships.
- File uploads
- Turns on the four upload controls: type and size validation, storage outside the web root, server-generated file names, and a bucket that is not publicly listable.
- AI feature
- Whether the app calls a model on behalf of users. Turns on the OWASP LLM Top 10 controls and the AI Act disclosure and prohibition.
With every fact false, 34 controls apply. With every fact true, all 77 do. The reference profile in the published method, a typical SaaS with accounts, managed auth, a hosted backend, payments, sensitive data and EU users, has 66, and 56 ASVS Level 1 requirements in play.
There is no not-applicable status. You describe the app; applicability follows from the description. If a control seems wrong for your app, the fix is to correct the profile, not to exempt the control.
Your first ledger
The probe runs as soon as you save a URL. It reaches 20 controls from the outside and takes under a minute. Connecting a repository adds three more. That first ledger will show most requirements as not yet tested, because the 49 controls in the coding-tool signal wait until you run them, and a control that has not been tested meets nothing.
Run the coding-tool signal from your own machine with Claude Code, Cursor or Windsurf. Each control is a verification prompt that names the requirement it satisfies; the tool reads your code, reasons about the control, and returns a verdict and the evidence for it. The code stays where it is.
A first ledger with most rows not yet tested is the expected outcome and not a judgement. It reflects what has been tested so far, not what is true about your application.
What happens to your code
Nothing is uploaded. VibeLock does not read your repository, does not clone it, and has no access to it. The coding-tool signal runs in your editor through a local agent, and what comes back is a verdict per control with a short reasoned explanation, bound to the commit it was checked at.
The probe only sees what any visitor to your URL can see. The repository signal reads the security alerts of your repository, not its contents.