SCA (uv): transitive dependency of a dev-only package is reported in Production scope

SonarQube Server / Community Build
, , ,
1

Environment:

  • SonarQube Server Enterprise with Advanced Security, v2026.3.1
  • Scanner: pysonar (Python)
  • Package manager: uv (pyproject.toml + uv.lock)

Description

SonarQube reports the prohibited-license risk with Production scope for a transitive dependency of a development-only dependency. We use formulas in the dev dependency scope (unit tests only), and it has schedula (EUPL licensed) as a transitive dependency. So a transitive dependency of a dev-only package is being classified as Production.

Currently, we have to accept the license risk manually. This creates another concern: if the dependency is later introduced into production code, the risk has already been accepted and we are concerned that Sonar will no longer alert us about this change.

Setup

pyproject.toml:

  [project]
  dependencies = [
      # ... runtime; NOT formulas/schedula
  ]

  [dependency-groups]
  dev = [
      "formulas>=1.3.4",   # test-only; pulls in schedula transitively
  ]
  • formulas (direct, dev group only) → depends on → schedula (transitive).
  • schedula is EUPL-1.1 licensed. Nothing in [project.dependencies] pulls it in — its only path into the graph is via formulas.

uv.lock correctly records the dev scope at the root package:

  [[package]]
  name = "my-project"
  # ...
  [package.dev-dependencies]
  dev = [
      { name = "formulas" },
      # ...
  ]

  [package.metadata.requires-dev]
  dev = [
      { name = "formulas", specifier = ">=1.3.4" },
      # ...
  ]

  [[package]]
  name = "formulas"
  version = "1.3.4"
  dependencies = [
      { name = "schedula" },
      # ...
  ]

  [[package]]
  name = "schedula"
  version = "1.6.15"

Questions

Is this scenario currently supported by SonarQube SCA? In particular, can SCA distinguish a test/development-only dependency from a production/runtime dependency for the purpose of license policy evaluation?

And is an accepted license risk scoped per dependency-scope? Our concern is that once accepted for a dev dependency, a later move into production code would not re-trigger the alert.

Thanks in advance!