Coverage

How coverage is derived

The mapping from controls to published requirements, what met means, the four tiers, and what the evaluation found.

VibeLock does not produce a score. It produces a ledger: which published requirements your application meets, by whose test, at what commit. Every input is observed, no language model participates in the arithmetic, and no severity or weight was assigned by VibeLock.

This matters because the ledger is meant to be shown to somebody who may push back on it. A requirement someone else wrote, met by a test you can name, survives that conversation. A number with a weighting behind it does not.

The mapping

Control
A testable statement about your application, checked by one signal. There are 77.
Requirement
A published requirement with its own identifier: an OWASP ASVS 5.0 requirement such as V8.2.2, a GDPR article such as Art. 17, an EU AI Act article such as Art. 50(1), or an entry in the OWASP Top 10 for LLM Applications such as LLM01.
Satisfies
Every control maps to one or more requirements. A control with no published requirement behind it is not in the catalogue.
Met
A requirement is met when every applicable control mapped to it is verified or provider-owned. If one of them fails, the requirement is unmet; if one is not yet tested, the requirement is not yet tested.
Tier
A control inherits Level 1 if any ASVS requirement it satisfies is Level 1, otherwise Level 2 if it satisfies any ASVS requirement, otherwise Legal for a GDPR or AI Act article, otherwise Advisory for the LLM Top 10.

No verdict

VibeLock never states that an application is ready, secure or compliant. It reports fractions: how many applicable requirements at each level are met, and which are not. OWASP defines Level 1 as the minimum set, so the Level 1 fraction is the one most readers look at first; the platform reports it and draws no conclusion from it. Level 2, the legal articles and the advisory entries are reported the same way.

A worked example

The reference profile has 66 applicable controls, 56 ASVS Level 1 requirements and 51 Level 2 requirements in play, and all 14 GDPR articles. Suppose the probe verifies its 18 controls, the repository signal its 3, the cross-checks their 4, eight authentication controls are provider-owned, and the coding-tool signal verifies 31 of the 33 it tests, with two Level 1 controls failing: server-side session verification and object ownership checks.

Those two failures leave three Level 1 requirements unmet, because the ownership control shares a requirement with two others and the session control satisfies two. The ledger reads 53 of 56 Level 1 met, 50 of 51 Level 2 met, 14 of 14 GDPR articles met, and names the three open Level 1 requirements. Fix the two controls, re-test, and it reads 56 of 56.

What is outside the ledger

ASVS 5.0 has 345 requirements. Ninety-two are Level 3 and are excluded. Of the remaining 253, 178 can be observed by one of the four signals; the rest live in hosting, organisational process or identity-provider duties, or cannot be observed at all, and are excluded with the reason stated. Every one of the 60 observable Level 1 requirements is reached by at least one control. Sixty-four Level 2 requirements are in scope but beyond what four signals can see; they are shown to you as a count and never counted against you or shown publicly.

Evidence expires

Probe evidence is valid for 24 hours. Evidence from the coding-tool signal is bound to the commit it was checked at and lapses when the code changes. Cross-check evidence lapses when either the document or the controls it depends on change. A control whose evidence has lapsed is not yet tested again, and every requirement it satisfies drops with it.

On paid plans re-testing is continuous. On the free plan you re-test when you ask.

Note

The ledger describes the app as it is, not as it was the week you set it up. That is inconvenient and it is the reason it means anything.

What the evaluation found

The fair objection to any security number is that somebody chose what counts. Here nobody at VibeLock did: the requirements are OWASP's, the GDPR's and the EU AI Act's, and the evaluation counts how much of each a set of four signals can reach, which signal carries the weight, and what the application profile does to the denominator.

Figure 1
ASVS Level 1 requirements met as each signal is connected

Reference profile, 56 applicable Level 1 requirements, every checked control passing. The probe reaches a third of them; the coding-tool signal reaches the rest.

01428425611None21Probe22+ Repo56+ Tool56+ Cross
Figure 2
Applicable Level 1 requirements when one profile fact is flipped

The profile is the one input you set, and the accounts fact is the one that moves the denominator. That is why you can describe your app but cannot exempt a control from it.

  • accounts56 to 33
  • managed auth56 to 56
  • hosted backend56 to 56
  • payments56 to 55
  • sensitive56 to 56
  • eu56 to 56
  • uploads56 to 60
  • ai56 to 56
Figure 3
The 77 controls by inherited tier and by signal

Sixty of the seventy Level 1 requirements in ASVS 5.0 can be observed by a signal, and every one of those is reached by at least one control. The other ten are documentation or identity-provider duties.

By tier
  • Level 141
  • Level 225
  • Legal6
  • Advisory5
By lane
  • Coding tool49
  • Live URL probe20
  • Cross-check5
  • Repository3

The load-bearing signal is the coding tool, because it is the only one that can see handlers, middleware, migrations and configuration. The load-bearing input is the profile, and the profile is eight plain facts about the application rather than a list of exemptions.