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.
Expanded Definition
A scanner property is a tool-specific configuration key that maps an analysis source, such as a coverage report, test results file, or other scanner input, into SonarQube’s processing pipeline. In practice, it is less about the data itself and more about whether the scanner can locate, parse, and trust that data during analysis. For glossary purposes, the important distinction is that a scanner property is not the report content and not the analysis outcome. It is the pointer that connects the two.
Definitions vary across vendors because each scanner family names, structures, and deprecates properties differently, but the operational pattern is consistent: if the key is wrong, removed, or formatted incorrectly, the engine may continue without error and simply omit the input. That makes scanner properties especially important in CI and DevOps pipelines where failing “open” can look like a healthy build. The most authoritative mental model is to treat these properties as control-plane instructions for code quality telemetry, not as passive metadata. The NIST Cybersecurity Framework 2.0 is useful here because it emphasises repeatable governance over configuration drift, even when the term itself is not formally defined there. The most common misapplication is assuming a successful scanner run means the report was ingested, which occurs when a deprecated property name still appears in pipeline code but no longer maps to a valid input.
Examples and Use Cases
Implementing scanner properties rigorously often introduces configuration fragility, requiring organisations to weigh analysis accuracy against the maintenance burden of keeping paths, keys, and build definitions aligned.
- A CI job sets a coverage-report property to the wrong directory, so SonarQube completes the scan but publishes 0% coverage because the file was never found.
- A repository upgrade changes a property name, and the pipeline still passes until teams notice that test evidence is no longer being imported.
- A monorepo uses separate scanner properties for frontend and backend reports, helping the scanner associate each artefact with the correct project component.
- An organisation validates scanner properties in pull request checks to catch deprecated keys before they reach mainline builds.
- A platform team documents approved property sets alongside NIST Cybersecurity Framework 2.0 aligned change control, reducing silent loss of security or quality data during tool upgrades.
These use cases show that scanner properties are operationally small but diagnostically important. A single incorrect path can break trust in the entire quality signal, especially when the scanner does not raise an obvious failure.
Why It Matters for Security Teams
For security and governance teams, scanner properties matter because they determine whether pipeline evidence is actually collected. If a property silently points to the wrong location, security-relevant telemetry such as test coverage, dependency findings, or code analysis output may never reach the control points that depend on it. That creates blind spots in SDLC assurance, auditability, and release gating.
This becomes especially important where application security, compliance evidence, and software supply chain controls depend on reliable scanner output. A misconfigured property can make a pipeline look compliant while the underlying evidence is absent, stale, or incomplete. In that sense, scanner properties support the broader discipline reflected in the NIST Cybersecurity Framework 2.0 by reinforcing repeatable, verifiable control execution. Teams that standardise property names, version them with build definitions, and review deprecations reduce the chance of hidden control failure. Organisations typically encounter the real impact only after an audit, failed release, or security exception review exposes that the expected evidence was never ingested, at which point scanner properties become operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-01 | Configuration governance underpins reliable security tooling and evidence collection. |
Standardise scanner property ownership and review changes before they affect assurance outputs.
