A coverage report is the file produced by a testing tool that records which lines or branches executed during automated tests. SonarQube does not create this data itself. It imports the report and computes its own metric from the file it receives.
Expanded Definition
A coverage report is a testing artefact that shows which code paths were exercised during automated execution, usually at the line, statement, or branch level. In software security and quality programs, it helps teams distinguish between code that was executed by tests and code that was never touched, which can signal blind spots in validation. The term is often used alongside coverage metrics, but they are not identical: the report is the exported evidence file, while the metric is the percentage or trend calculated from that evidence.
Definitions vary across vendors on how coverage is collected, merged, and displayed, especially when unit, integration, and end-to-end tests are combined. For governance purposes, the report should be treated as a traceable input to quality assurance rather than as proof that the system is safe. A tool such as SonarQube may import the report and compute its own view, but it does not generate the underlying execution data itself. For a broader governance lens, the NIST Cybersecurity Framework 2.0 reinforces the need for repeatable assurance evidence, even though it does not define test coverage as a standalone control term. The most common misapplication is treating a high coverage percentage as evidence of security, which occurs when teams ignore untested logic, weak assertions, or missing negative-path tests.
Examples and Use Cases
Implementing coverage reporting rigorously often introduces measurement overhead, requiring teams to balance faster delivery against the cost of maintaining reliable test instrumentation and report aggregation.
- A backend engineering team exports a line coverage report from its test runner and uses it to identify files that never execute during CI.
- A security engineering group reviews branch coverage on authentication code to confirm both success and failure paths are exercised, using guidance from OWASP Web Security Testing Guide as a practical reference for testing depth.
- A platform team merges coverage reports from multiple pipelines so that unit and integration tests are assessed together instead of in isolation.
- A release manager compares coverage trends across builds to spot regressions after major refactoring or dependency upgrades.
- A compliance-oriented team stores coverage artefacts as part of release evidence, showing that critical functions were at least executed during automated validation.
Coverage reports are especially useful when teams need to identify gaps in test execution rather than just confirm that tests passed. They are also helpful when security-sensitive logic, such as input validation or access checks, needs stronger branch-level scrutiny. In larger pipelines, different tools may format coverage data differently, so the report must be normalized before it can be compared across projects or languages. The OWASP Cheat Sheet Series is useful when teams want to pair coverage review with defensive coding and validation practices.
Why It Matters for Security Teams
Security teams care about coverage reports because unexecuted code is unassessed code, and unassessed code often becomes the hiding place for defects that survive release. Coverage data does not prove that controls work, but it does help identify where assurance is thin, especially in authentication flows, policy enforcement logic, and error handling paths. In regulated or high-risk environments, coverage evidence can support release gates, change review, and investigation after incidents by showing whether critical code paths were ever exercised in testing. It also matters when security and engineering teams rely on automated pipelines to validate changes quickly, because a missing report can leave blind spots in the assurance chain.
For teams working with identity or access logic, coverage is particularly important around session handling, token validation, and privilege checks, where a missed branch can translate into a real exploit path. Coverage reporting becomes operationally unavoidable after a production defect, when responders need to determine whether the faulty path was ever tested and whether the issue reflects a control gap or a test gap.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | Coverage reports support ongoing monitoring of software validation gaps and control assurance. |
| NIST SP 800-53 Rev 5 | CA-2 | Assessment and authorization activities rely on evidence that systems were tested adequately. |
| ISO/IEC 27001:2022 | A.8.29 | Secure testing practices include evidence that verification activities covered critical functions. |
| OWASP Non-Human Identity Top 10 | Coverage evidence matters where NHI workflows and token handling need thorough test execution. | |
| NIST SP 800-63 | Identity assurance depends on well-tested authenticator and session flows, which coverage can help validate. |
Test NHI-related logic broadly enough to prove critical identity and secret-handling paths were executed.
