How we measure coverage
Every report we ship carries two numbers: a risk score and a coverage score. The risk score rates what we found. The coverage score estimates how much of your attack surface we were able to look at and assess.
Coverage can only speak to what you put in scope; anything outside the agreed boundary is never measured. That is a different, weaker claim than confidence, which would mean we believe we know every vulnerability you have. No test can honestly promise that, so we only give the coverage estimate.
Background radiation
Any host with a public IP is under constant, untargeted attack. Mass scanners sweep the whole address space, bots fire known exploits at whatever answers, and credential-stuffing tools grind through leaked passwords around the clock. None of it is aimed at you specifically. We call this background radiation.
Coverage is framed against that baseline. A high coverage score means we have looked at the surface that background radiation and a motivated attacker would realistically reach, and can say what holds and what doesn't. A low one means large parts of your exposure are still an open question.
The OWASP risk score
The risk score uses the OWASP Risk Rating Methodology: every score decomposes into factors you can argue with. The shape is simple:
Risk = Likelihood × Impact
Each side is the average of a set of factors, every factor scored from 0 to 9. Likelihood comes from two groups:
- Threat-agent factors: skill level, motive, opportunity, and group size. Who would go after this, and how easily can they start.
- Vulnerability factors: ease of discovery, ease of exploit, awareness, and intrusion detection. Once they start, how easily do they succeed without being noticed.
Impact comes from two more:
- Technical impact: loss of confidentiality, integrity, availability, and accountability. What the exploit does to the system.
- Business impact: financial damage, reputation damage, non-compliance, and privacy violation. What it does to you.
Average the factors in each half to get a Likelihood value and an Impact value, map each to Low (0 to under 3), Medium (3 to under 6), or High (6 to 9), and read the overall severity off the matrix below.
| Impact ↓ / Likelihood → | Low | Medium | High |
|---|---|---|---|
| High | Medium | High | Critical |
| Medium | Low | Medium | High |
| Low | Note | Low | Medium |
A high-impact vulnerability that is very hard to find and to trigger scores lower than an easy one, because a real attacker is less likely to ever reach it. So the surface a breadth-first pass covers, the high / medium likelihood surface, is exactly where most of your risk concentrates.
Why coverage caps at 80%, 95% and 99%
We run engagements in up to three passes, and each pass earns a different ceiling on the coverage we can claim. Each ceiling costs more effort than the one before it, for less coverage gained.
The first pass is typically agentic-enabled. Humans or scope-bound agents sweep the attack surface in breadth, enumerate assets, and surface the high-likelihood issues fast. This is the pass that matches, and then goes past, what background radiation would find. Completing it earns up to 80% coverage. That ceiling is deliberate, and it follows from the risk model above: what a breadth pass leaves behind is the low-likelihood surface, the deep business logic and multi-step chains that take real complexity to reach. A bug hiding there can still be high-impact, but its low likelihood keeps its risk contribution bounded.
The second pass is human and in-depth. A reviewer goes deep on what the first pass surfaced and works exactly that low-likelihood, high-complexity surface automation can't judge. Completing it takes you up to 95% coverage.
The third pass is a supply-chain audit. Your software sits on libraries, runtimes, and operating systems you did not write, and on their dependencies in turn. The first two passes test that layer for known n-day exploits; this one reviews it as part of your attack surface, which means reading your dependency manifests, build pipeline, and the third-party code paths you rely on. Completing it takes you up to 99% coverage.
The upper ceilings also depend on the engagement type. In a black-box engagement we never see your code, so we cannot confirm that the in-depth pass exercised every path in it, and the supply-chain audit has nothing to read. Black box therefore caps below 95%; the 95% and 99% ceilings need a grey- or white-box engagement.
Every ceiling above 80% also depends on us knowing your attack surface. If in-scope shadow infra exists (servers, subdomains, cloud accounts, or forgotten test deployments that fall within the agreed scope but were never told to us or discovered during the first pass), we cannot assess what we do not know is there, and the ceiling drops with it. Reaching the upper ceilings takes an accurate, complete asset inventory from you going in, not just our passes.
We stop at 99% and never claim 100%. Even with the supply chain audited, the surface never fully closes: dependencies pull in dependencies of their own, and the compilers, hardware, and hosting platforms beneath them are out of reach for any single engagement. A score that claims 100% is lying, and the last percent is the honesty margin.
If you want to see your own number, and the risk score that comes with it, request an engagement.
← All posts