The number lies

Every security review I have sat in eventually reaches a number that makes the room relax. Coverage is up. Open findings are down. The dashboard is green. And almost none of it answers the only question that matters: are we actually safe?

“90% coverage”

“We are at 90% test coverage” is a comfort, not a security statement. Coverage becomes a vanity metric the moment it is the goal. A test that runs against a line of code tells you the line was executed. It does not tell you the dangerous case was checked, the trust boundary was enforced, or the risk was retired. You can be green and still be exposed. The useful question is never how much you tested. It is which risk this test actually retired.

“1,200 open vulnerabilities”

“We have 1,200 open vulnerabilities” sounds alarming, and it is nearly as useless as it is scary. The number on its own says nothing about how many are reachable, exploitable, and sitting on something that matters. Driving it to zero is how teams burn out and still miss the one that counts.

Mature vulnerability management is not an empty dashboard. It is risk-based triage: know what you ship (an SBOM helps), prioritise by reachability and severity, and make a documented decision about the rest. The goal was never zero. It was no surprises.

“Zero exceptions”

Which brings us to the number people are proudest of and should trust the least: zero exceptions. A documented exception is not a failure. It is a controlled risk acceptance: a deliberate decision to deviate from a requirement, with an owner, a reason, and an expiry date. The teams that claim zero exceptions usually have the most, just undocumented, and undocumented risk surfaces at the worst possible moment. A good exception process turns an audit into verification instead of archaeology.

A number is not a decision

Put the three together and the pattern is clear. Coverage, vulnerability counts, exceptions: each is a number that feels like an answer and is really a question in disguise. A quality gate is not a threshold you clear to look good on a dashboard. It is a decision, made by someone who can defend it. Security is not a number you hit. It is a decision you can stand behind.

What to do

Four shifts, none of them a new tool:

1. Measure retired risk, not volume. Reward the finding that was proven and closed, not the count on the screen.
2. Know what you ship. An SBOM plus reachability analysis turns 1,200 findings into the handful that can actually hurt you.
3. Document your exceptions. Owner, reason, expiry. An undocumented risk is not a smaller risk, it is a hidden one.
4. Make gates decisions, not numbers. Every gate should have a name attached and a reason you could say out loud to an auditor.

A green dashboard is a nice thing to show a board. It is not the same as being able to look someone in the eye and say you understand your risk and chose it on purpose. That is the difference we build with teams: not an empty dashboard, but no surprises.

This is what we train, live and hands-on, not on slides. In workshops we use your own pipeline and findings wherever that is practical and agreed. The engineering side is here: cyberment.ee/ai-code-security.

Build it in. Not on the dashboard.