Home / Knowledge hub / Security test coverage
Knowledge hub
Security test coverage
How much of your application a security test actually reached.
What it means
Security test coverage describes how much of your application a test reached and exercised. It can be counted in pages, endpoints, parameters, user journeys, lines of code or kinds of weakness checked. None of these measures is complete on its own, so a useful report states which one it means.
The point is to separate 'we found nothing' from 'we looked and found nothing'. A test that never reached the admin area, the mobile API or the checkout flow says nothing about them, however tidy its report looks. Coverage is the missing half of every result.
Why it matters
A clean report is only reassuring if the test covered what matters. If the scanner could not sign in, it saw the login page and little else. If it skipped the API your mobile app uses, that API went unchecked, and customers, auditors and insurers will not know the difference unless somebody tells them, which makes the gap your problem.
Coverage also makes results comparable. Last quarter's test reached 40 endpoints and this one reached 120, so a rise in findings may simply reflect looking harder, and a fall may mean the test saw less. Without the number, you cannot tell progress from luck, or a good quarter from a blind one.
How it shows up
Ask what was in scope, what was reached and what was not. A good report lists the areas covered, the accounts used, and the parts that were out of reach and why. The attack surface your team lists should match the one the tester describes.
Common gaps repeat: pages behind a login, steps that need a one-time code, single-page apps that need a real browser, and APIs with no link from the front end. Counting routes in your own code or API inventory gives you a list to compare against.
Questions people ask
Security test coverage, answered
Is code coverage the same as security test coverage?
No. Code coverage measures which lines your unit tests ran. Security coverage asks whether the testing reached the places an attacker could.
The two overlap when a tool reads the code and tests the running app together.
Can coverage reach 100 percent?
Rarely, and 100 percent of pages does not mean every kind of flaw was checked on each page. Aim for stated, justified coverage of the parts that handle money, identity and personal data.
Say plainly what was left out.
How do we ask a vendor about coverage?
Ask for the list of endpoints and journeys reached, the accounts used, and what could not be tested. Ask how the tool handles logins and single-page apps.
A vendor who cannot answer is telling you something.
Does low coverage mean a bad test?
Not necessarily. A narrow test of a payment flow can be exactly what you asked for. It becomes a problem when the report implies the whole app is clean.
The scope and the result should be read together.
How does coverage relate to false negatives?
Every area a test misses is a place where a false negative can hide. Poor coverage is one of the main causes of them.
You rarely see the cost until someone else finds the flaw.
Sources
Where this comes from
Related
Terms that sit next to this one
Penetration test scope
The written list of what a pentest may and may not touch.
False negative
A real vulnerability that a test failed to find.
Attack surface
Everything about your application an outsider can touch.
Crawling
Following links and forms automatically to map out what an app exposes.
Authenticated testing
Testing the parts of an application that only signed-in accounts can reach.
What did the test never reach?
We test web apps and their APIs signed in, so the areas behind a login are covered rather than skipped, and the report shows what was exercised. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.