TL;DR: Most 0% coverage results come from handoff failures such as missing reports, wrong formats, deprecated properties, or CI timing, according to Sonar. The broader lesson is that coverage is a pipeline integrity problem, and AI-generated tests can still pass while verifying nothing.
At a glance
What this is: Sonar explains that SonarQube coverage failures usually come from broken handoffs between tests, coverage tools, scanner configuration, and file paths rather than from SonarQube itself.
Why it matters: This matters because teams can waste time debugging the wrong layer, while the real control problem is whether CI is producing, locating, and interpreting coverage evidence correctly.
Context
Code coverage only has value when the report can move cleanly from the test runner into the analysis engine. In this case, the governance gap is not test execution alone but evidence handoff, where report format, file location, scanner timing, and path resolution all have to align.
For IAM and NHI practitioners, the important parallel is control integrity: a metric or policy is only reliable if the upstream identity, build, or telemetry pipeline preserves the data it depends on. Sonar’s analysis is a reminder that silent failure at a handoff point can make a security signal look healthy when it is not.
The article is typical of CI-based engineering environments where coverage tooling, scanner configuration, and repository layout evolve separately. That makes this a familiar operational failure pattern rather than an unusual product defect.
Key questions
Q: Why does SonarQube show 0% coverage when tests pass?
A: Because the scanner only reports what it can find in a valid coverage report. If the report is missing, misformatted, produced too late, or pointed at the wrong path, tests can pass while SonarQube sees no usable evidence. The failure is usually in the pipeline handoff, not in test execution itself.
Q: What is the difference between SonarQube coverage and language tool coverage?
A: Different tools count different executable units. SonarQube focuses on executable logic and may combine line and branch coverage, while language tools may count imports, class declarations, method signatures, or closing braces differently. That means two numbers can both be correct while measuring different scopes.
Q: How do teams know whether coverage is failing because of configuration or code?
A: Start with the report file, the scanner property, and the scanner run order. If the report does not exist, uses the wrong format, or cannot be resolved from the scanner working directory, the problem is configuration. If the report is present and parsed, then investigate test scope, branch depth, and assertion quality.
Q: What should engineers check when coverage is lower than expected after a CI change?
A: Check for deprecated property names, changed report paths, altered working directories, and container path differences introduced by the new pipeline. CI changes often break the evidence chain without changing the tests themselves, so the first task is to confirm the scanner still sees the same report in the same place.
Technical breakdown
Why coverage data is a handoff problem
SonarQube does not generate coverage data. It imports report files created by tools such as JaCoCo, coverage.py, Istanbul, or c8 after tests have already run. That means the pipeline depends on four distinct transitions: test execution, coverage instrumentation, report generation, scanner ingestion, and dashboard interpretation. A failure in any one stage produces the same symptom on the surface, which is why teams misdiagnose the issue. In practice, the report file is the control point, because it is the artifact that must survive format, path, and timing checks before SonarQube can read it.
Practical implication: Treat coverage as a chain of evidence and validate each handoff before you trust the dashboard number.
Why different tools report different coverage numbers
Coverage tools and SonarQube often count different things. Some tools count imports, class declarations, or method signatures as coverable lines, while SonarQube focuses on executable logic statements. Java tools such as JaCoCo also count closing braces differently from SonarQube. SonarQube further combines line and branch coverage into one metric, so a project with weak branch test depth can look lower than a tool that reports line coverage separately. The result is not a contradiction, but a difference in measurement scope and formula.
Practical implication: Compare like with like, and separate line coverage, branch coverage, and executable statement coverage before you draw conclusions.
Why silent failures make configuration hygiene critical
Several common misconfigurations fail quietly. Deprecated scanner property names, wrong report formats, incorrect relative paths, or a scanner that runs before the report exists can all leave coverage at 0% without a useful error message. File-path mismatches are especially common in CI because coverage tools may write container paths or module-relative paths that SonarQube cannot resolve. That creates a governance problem: the pipeline appears to work, but the evidence never lands in the analysis stage. The issue is not just misconfiguration, but undetected misconfiguration.
Practical implication: Harden scanner configuration checks so deprecated properties, stale paths, and early scanner execution are caught before merge.
Threat narrative
Attacker objective: The practical outcome is not theft but control deception, where the pipeline reports a misleading quality signal that can mask weak test assurance.
- Entry occurs when the test pipeline runs but coverage data is never produced, never written to disk, or never referenced by the scanner.
- Credentialed escalation is not the issue here; the failure comes from configuration drift, wrong formats, or paths that prevent the scanner from ingesting the report.
- Impact is a false 0% coverage result or a materially understated coverage number, which misleads release and quality decisions.
Breaches seen in the wild
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
- ArtiPACKED 2024: Unit 42 found public GitHub Actions artifacts in major open source projects leaking live GITHUB_TOKENs, runtime tokens and cloud tokens.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Coverage handoff integrity is the real control problem: Sonar’s analysis shows that coverage is not a single metric but a chain of dependencies across test execution, report generation, scanner configuration, and source-path resolution. When teams focus only on the dashboard, they miss the operational point where the signal is lost. Practitioners should govern coverage as an evidence pipeline, not a vanity metric.
Silent configuration failure is more dangerous than noisy failure: Deprecated property names and wrong report locations can fail without warning, which means the analysis layer may appear healthy while ingesting nothing. That is a governance gap as much as a tooling issue, because undetected misconfiguration creates a false sense of assurance. Teams should assume that any zero-value or unexpectedly low metric may be a pipeline integrity issue first.
Coverage metrics are especially weak as a proxy for test quality: Sonar’s own rules show that tests can execute code without asserting outcomes, so line coverage can rise even when behavioural verification is absent. This is where coverage must be paired with test semantics, not treated as evidence of correctness. The practitioner conclusion is simple: measure execution, but inspect assertion quality separately.
What this signals
Coverage metrics need evidence governance, not just test execution: teams should treat report generation, file naming, and scanner timing as controlled dependencies, because a metric that cannot be ingested reliably is not an assurance signal.
Silent failure modes create false confidence: when deprecated properties or path mismatches are ignored by the scanner, the quality gate can look valid even though the coverage report never reached the analysis layer.
Coverage should be paired with verification quality checks: assertion-less tests and dead assertions can inflate line coverage without improving defect detection, so teams need both execution evidence and behavioural verification evidence.
For practitioners
- Validate the coverage artifact before analysis Check that the coverage report exists after the test step and before sonar-scanner runs, then confirm the file format matches the language-specific expectation.
- Replace deprecated scanner properties Review sonar-project.properties and CI flags for old coverage keys such as deprecated report path names, then update them to the current property names.
- Align report paths with the repository layout Make sure report paths are relative to the scanner working directory and that monorepo or module-relative paths resolve to the same source tree SonarQube sees.
- Separate coverage volume from test quality Inspect tests for missing assertions, dead assertions inside exception blocks, and empty test classes so coverage increases reflect real verification rather than execution only.
Key takeaways
- SonarQube coverage failures usually come from broken pipeline handoffs, not from the coverage dashboard itself.
- Differences between SonarQube and language coverage tools often reflect different counting rules, file scope, and branch treatment.
- Teams need to validate report generation, scanner configuration, and test assertion quality if they want coverage numbers to mean anything.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Coverage handoff failures often stem from pipeline configuration drift and uncontrolled analysis steps. |
| Recommendation — Audit pipeline account and job ownership so only approved jobs can generate and submit analysis evidence. | ||
| NIST CSF 2.0 | PR.DS-08 — Integrity of information and records is protected | Coverage reports are records that must remain intact across build and analysis stages. |
| Recommendation — Protect report integrity from test output through scanner ingestion so the metric cannot be silently corrupted. | ||
| MITRE ATT&CK | TA0003;TA0004 — Persistence; Privilege Escalation | Pipeline abuse often depends on enduring access and elevated build permissions. |
| Recommendation — Map CI pipeline abuse to persistence and privilege escalation paths when reviewing build trust boundaries. | ||
Key terms
- Case Handoff: The transfer of an investigation from one analyst or team to another with enough context to continue work without rebuilding the case from scratch. Strong handoff preserves evidence, rationale, and chronology so the next reviewer can trust and extend the analysis.
- Executable line: An executable line is code that a platform considers capable of being run and therefore counted in coverage calculations. Different tools define this differently, which is why SonarQube can show a lower or higher percentage than a language-specific coverage tool on the same codebase.
- Scanner property: A scanner property is a configuration key that tells SonarQube where to find an analysis input such as a coverage report. If the property name is deprecated, misspelled, or points to the wrong path, SonarQube may silently ignore the data and report 0% coverage.
- Assertion Quality: The extent to which a test verifies behaviour rather than merely executing code. Tests can raise coverage numbers while still checking nothing, so assertion quality is a stronger indicator of useful validation than line coverage alone.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org