Grounded in research on why compliance fails

The problem it exists for

The people shipping the most software right now are frequently the ones with the least access to security expertise. Somebody with an idea and an AI coding tool can put a working application in front of paying customers in a weekend, without ever having been in a room where threat modelling was discussed.

That is not a criticism of them. It is a description of a gap. The existing tools assume a security engineer is reading the output. Scanners produce findings in a vocabulary you need training to interpret, compliance platforms are priced and scoped for companies with a compliance function, and the free advice is written for people who already know which parts apply to them.

So the honest position most small teams end up in is: probably some problems, no idea which, and nothing to show anyone who asks.

Where the approach comes from

The doctoral research behind VibeLock analysed the effectiveness of information security compliance: not whether organisations have controls, but whether the controls they have produce the outcomes anyone expected. The recurring finding across that literature is unglamorous. Programs fail far more often on evidence and follow through than on the technical content of the controls themselves.

That is exactly the failure mode of a small team. The checking is rarely the hard part. Remembering what you checked, six weeks later, when a buyer sends a questionnaire, is the hard part. VibeLock is built around that observation rather than around scanning, which is already well served.

Why the ledger is observed, not asked

The ledger is computed by a fixed, published method from evidence the platform observes: responses from your live URL, security signals from your repository, what your own coding tool verifies in your code, and whether the documents you publish match it. No status is set by hand and no language model grades you. This is a deliberate constraint and it costs us a more impressive demo.

The reason is that the ledger exists to be shown to somebody who may push back on it. A claim you cannot reproduce or explain does not survive that conversation, and neither does one you could have typed in. Every control maps to a requirement someone else published, so there is no severity or weight of ours to argue with. The method, including an evaluation of how far four signals reach into those requirements, is written up in full and is being submitted for peer review.

What it will not do

VibeLock will not certify you, and it will not tell you that you are secure. It is a software tool, not a security firm, and it does not replace a qualified auditor or a lawyer. Every Trust Center it produces says on its face how it was computed and what it does not constitute.

Those constraints are the product rather than caveats attached to it. A Trust Center that overclaims is worth less than no Trust Center, because the first person to check will find the overclaim and stop believing the rest.