Free · no account · ten to fifteen minutes
See where your security controls actually act — and where nothing does.
You already run scanners, gates and reviews. What none of them can tell you is how far they reach — which environments, which technologies, which part of the lifecycle. Answer six short steps about what you build and what you already have, and get the map of every place a control is required, what covers it, and what does not.
No account, no repository access, no scanner credentials. Nothing to install.
Your answers are measured against a catalog, not against a template
The catalog exists before you arrive and is the same one the worked example is scored against. Your answers decide which of it applies to you; they never change what it says. A control acts at a named point in a named phase — nine phases, sixteen control points — so “we run SAST” becomes a claim about particular places, and the places it does not reach are the result. The two frameworks are OWASP SAMM v2 and NIST SP 800-218 (SSDF 1.1); we name the ones we have actually mapped rather than a logo wall.
- security controls
- 86
- capabilities they group into
- 40
- tools whose abilities we already know
- 26
- frameworks mapped, control by control
- 2
What you get
Three numbers, and they never collapse into one — a single score would hide that these are three different problems with three different fixes.
Coverage
Do you have the necessary controls everywhere you need them? Every requirement is expanded into the concrete places it applies — environment, technology, phase, control point — and each place is either covered by something you told us about, or it is not.
Effectiveness
Are those controls effective, or do scanners just run alongside? A tool that reports and a gate that blocks are not the same control. Enforcement, automation, how much of the application the control sees, and where findings go are weighed separately.
Maturity
Has this become a process you can govern? Six cumulative levels, from missing to optimized. Enforcement alone is not level three: that also wants a deadline, an exception process and an owner.
And a list of what to do next, in order
Each recommendation carries the coverage it would move. That figure is not an estimate — it is the exact share of the same fraction the headline number is computed from, so the list is ordered by effect rather than by opinion.
Yours to take away
A printable report, the whole assessment as JSON, and the gap list as CSV. No account for any of it: the export is part of what the free assessment is for, not a reason to sign up.
What we will ask you
Six steps, ten to fifteen minutes, all of it from memory. We ask what you know about your own delivery — not for a token that would let us find out.
What are you building?
Name, type, whether it faces the internet, how bad an outage would be, and whether it holds personal or financial data. This decides what is even asked later.
What is it built from?
Languages, frameworks, data stores, infrastructure. Static analysis is never asked of a database, and this is how it knows.
Where does it run?
Your environments. Coverage is measured per environment, so a control that stops at test is not a control that reaches production.
Which security tools do you use?
Pick from tools we already have on file. Because we know what each one can do, choosing it answers several questions at once.
How is each tool actually run?
Where it runs, whether it blocks or only reports, and what your team does with what it finds. This is the difference between having a tool and having a control.
And the rest
Only the capabilities your profile requires that none of your tools already covers. Nobody is asked about all forty.
No repository access, no CI credentials, no API tokens, no scanner keys. There is nothing to connect and nothing to install.
What happens to what you tell us
The product measures how carefully other people handle sensitive data, which makes this section the one we can least afford to be vague about.
It starts with nobody’s name on it
An assessment begins as its own isolated tenant, reachable only from a signed cookie in this browser. There is no account, no email address and nothing linking it to you.
It expires after 30 days
An assessment nobody has claimed is set to expire 30 days after it starts, and is deleted when it does. You can also delete it yourself at any point, from the assessment itself — one button, no confirmation email, no support request.
Signing in is offered last, and it is optional
You see your coverage map before anything is asked of you. An account exists for one reason: it is what stops the 30-day clock. If you never want one, take the export instead — it holds the same numbers.
Nothing is shared with anyone
No analytics, no tracking script, no third-party fonts or assets, and a content security policy that permits no outbound connection at all. One external service is used, for one thing: Resend, to send a sign-in link if you ask for one.
Rather see it on somebody else’s data first?
The worked example is a complete assessment of a fictional internet-facing payment platform — Java and Spring Boot on Kubernetes, Terraform, Azure, three environments — rendered by exactly the code your own would be. Its coverage is deliberately uneven: container scanning is solid, infrastructure checks stop at the pull request, dynamic testing never leaves test. A demo where everything was green would prove nothing.
Fifteen minutes from now, you could know where your controls stop.
Nothing to install, nothing to connect, nothing to cancel.
Want the account first? Create an account