Start at the pipeline, not the dashboard. Confirm that tests executed, a coverage report was generated, the report uses the expected format, the scanner property points to the right path, and the scanner runs after the report exists. If all of that is true, inspect debug logs for unresolved paths or ignored reports.
Why This Matters for Security Teams
Zero percent code coverage in SonarQube is rarely a SonarQube problem first. It usually means the build pipeline, test execution, or report handoff failed before analysis ever began. That matters because teams can waste time tuning quality gates while the real issue is broken evidence collection. The operational risk is not just bad metrics; it is blind spots in release assurance, where teams assume test visibility that does not exist. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces the need for trustworthy measurement and repeatable control validation, not just tool output.
For practitioners, the key question is whether coverage data is being produced, located, and consumed in the expected sequence. If any one of those steps breaks, SonarQube will often report 0% even when tests ran. That failure mode is common in CI systems where paths change between jobs, containers, or branches. In practice, many security teams encounter missing coverage only after a release decision has already been made, rather than through intentional pipeline validation.
How It Works in Practice
Troubleshooting should follow the data path from test runner to scanner. First, confirm that the test task actually executes and emits a coverage artifact in a format SonarQube understands, such as LCOV, JaCoCo, or OpenCover depending on the language. Next, verify that the scanner property points to the generated file and that the file exists in the scanner’s working directory at scan time. SonarQube does not infer coverage from test success alone.
It also helps to separate generation issues from ingestion issues. A build can pass all tests and still produce no usable report if the coverage tool is disabled, misconfigured, or writing to an unexpected output location. Similarly, the scanner can find a report but ignore it if the path is relative to the wrong folder, the format does not match the project language, or the analysis step runs before the report is written. Debug logging is valuable here because it usually reveals unresolved paths, missing files, or skipped sensor steps.
- Confirm the test command creates a real coverage file, not just a test result file.
- Check the report path against the scanner’s current working directory.
- Validate language and format alignment for the chosen coverage tool.
- Ensure the scan job runs after artifact generation and before workspace cleanup.
- Review debug output for ignored reports, path normalization problems, or permission issues.
In CI/CD environments with ephemeral containers, this guidance tends to break down when the coverage report is written outside the mounted workspace because the scanner cannot see files created in a previous filesystem context.
Common Variations and Edge Cases
Tighter pipeline validation often increases build complexity, requiring organisations to balance coverage accuracy against job fragility. That tradeoff is real in monorepos, multi-language builds, and containerized runners where one scan may depend on several test stages. Best practice is evolving, but the current guidance is consistent: make report generation deterministic and keep the scanner’s file path explicit rather than implicit. When teams rely on defaults, 0% coverage becomes much more likely.
There are also edge cases where the reported 0% is technically correct but operationally misleading. For example, a project may use a language-specific coverage format that SonarQube supports, but the branch being analysed has no matching source files, so the report has nothing to map. In other cases, generated files are present but excluded by path filters, workspace isolation, or file ownership problems in a hardened build agent. This is why path resolution, file visibility, and scanner timing should be validated together rather than one at a time. For broader control mapping around detection and process validation, teams can align the workflow to the NIST Cybersecurity Framework 2.0 and its emphasis on repeatable operational assurance.
Where the project uses mixed test frameworks or generated source code, there is no universal standard for this yet: teams often need a language-by-language check to confirm that coverage tools are producing files SonarQube can actually associate with analysed lines of code.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Reliable measurement supports trustworthy security and quality operations. |
| MITRE ATT&CK | T1059 | Build and test execution issues often surface through command and scripting paths. |
| CIS Controls | 16 | Application software integrity depends on validated build and test evidence. |
Require CI checks that prove tests ran and coverage artifacts were generated before release.
Related resources from NHI Mgmt Group
- How should cloud teams measure Infrastructure as Code coverage in practice?
- How should security teams govern AI-generated code in production environments?
- How should security teams govern S3 access for sandboxed AI code interpreters?
- How should security teams govern AI code assistants that have repository and cloud access?
