SonarQube currently supports quality gate conditions based on the total count or severity of vulnerabilities found in dependencies (via SCA). However, it does not distinguish between direct dependencies and transitive dependencies when defining these conditions.
This makes it difficult to enforce policies that reflect real-world risk exposure — where a vulnerability in a direct dependency poses a higher and more actionable risk than the same vulnerability buried several layers deep in the dependency tree.
Problem statement
When a vulnerability appears in a transitive dependency, the fix path is indirect: it requires the direct dependency to release an updated version that pulls in a fixed transitive. The development team has limited control over this.
Conversely, a vulnerability in a direct dependency is actionable immediately: the team can upgrade or replace that dependency.
Current quality gate conditions treat both equally, which leads to one of two undesirable outcomes:
• Teams set lenient thresholds to avoid being blocked by unactionable transitive issues → direct vulnerabilities are silently accepted.
• Teams set strict thresholds → pipelines are blocked by transitive issues the team cannot fix directly, causing alert fatigue and gate bypasses.
Proposed solution
Add new quality gate metrics (or dimensions on existing ones) for dependency vulnerability findings that expose the dependency depth type as a filterable attribute:
• Dependency type: direct | transitive
• Severity: critical | high | medium | low | info
This would allow conditions such as:
✗ “Fail if there are any CRITICAL or HIGH vulnerabilities in DIRECT dependencies”
✗ “Fail if CRITICAL vulnerabilities in DIRECT dependencies > 0”
“Warn if transitive dependencies with CRITICAL vulnerabilities > N”
Example use case: a team wants to enforce a strict security policy for their own dependency choices without being penalized for vulnerabilities in the transitive graph that are outside their direct control.
Expected behavior
In the Quality Gate configuration UI and API, dependency vulnerability conditions should expose a “Dependency scope” filter with at least two values: “Direct” and “Transitive” (and optionally “Any” for backwards compatibility).
The metrics should be available for both:
• New code conditions (vulnerability introduced in this analysis)
• Overall code conditions
Why this matters
This aligns with how mature AppSec and SCA tooling (e.g. Snyk, OWASP Dependency-Check, GitHub Dependabot) categorises findings — by exploitability and actionability, not just by raw severity. Bringing this distinction to Quality Gates would make SonarQube’s SCA feature significantly more useful for teams that need meaningful, enforceable security policies rather than all-or-nothing gates.