uv audit Integration with DefectDojo

uv audit Integration with DefectDojo

uv is a Python package and project manager written in Rust by Astral, and uv audit is its command for auditing a project's dependencies. It checks the project's locked dependency set against Python advisory databases and reports each vulnerable package with the advisory identifier (typically a PYSEC ID), its CVE and GHSA aliases, a link, and the versions that fix it. uv marks the command and its JSON output as experimental, so the schema may change. DefectDojo imports the JSON report.

uv audit Integration with DefectDojo

Our Python services moved to uv for dependency management, and running uv audit in the same pipeline means the vulnerability check reads the exact lockfile we ship. DefectDojo turns that report into tracked work: each advisory becomes a Finding on the service's Asset with the package and version, the CVE IDs for cross-referencing, a link to the advisory, and a mitigation that names the upgrade target. Reimporting on every build shows which advisories were closed by an upgrade and which ones are still waiting on a release.

Why uv audit Matters

Dependency audits are only as accurate as the dependency list they read. Auditing the lockfile means the result reflects what actually gets installed, including transitive packages.

• It audits the locked dependency set, so transitive dependencies are covered, not only what is listed in pyproject.toml.
• It lives inside the tool that already resolves and installs dependencies, which removes a separate install step from the pipeline.
• Each advisory comes with aliases, so the same issue can be matched against CVE-based reporting and GitHub advisories.
• Fixed versions are reported where known, which tells an engineer the minimum upgrade to make.

Advantages of This Integration

• CVE-level tracking. CVE aliases are stored as Vulnerability IDs, so uv audit findings can be searched and reported by CVE next to results from other scanners.
• Deduplication by advisory and package version. Findings are hashed on the advisory ID, Component Name, and Component Version, so rescanning an unchanged lockfile does not create duplicates.
• Upgrades close findings. When you bump a package, the old Component Version no longer appears. Reimporting into the same Test mitigates that Finding and records when the fix landed.
• Actionable mitigation. Where uv reports fixed versions, the mitigation reads "Upgrade package to version", which is the exact change to make.
• Consistent with pip-audit. uv audit reports no severity, so every Finding imports as Medium, the same choice DefectDojo makes for pip-audit. Teams that use both see consistent results.
• Schema version on record. The report's schema version is written into each description, so a report produced by a newer uv can be identified if the experimental format changes.

How This Integration Works

DefectDojo imports uv audit output with the uv audit Scan scan type.

1. Produce a JSON report. From the project root, with a current uv.lock, write the JSON report:

uv audit --output-format json > uv-audit.json

Because uv labels this output experimental, pin the uv version in CI and confirm the import still works when you upgrade uv.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select uv audit Scan, and upload the file. For automation, use the API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=uv audit Scan" 
  -F "file=@uv-audit.json" 
  -F "product_name=reporting-api" 
  -F "engagement_name=Dependencies" 
  -F "auto_create_context=true"

DefectDojo Pro users can use Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "uv audit Scan" 
  --report-path "./uv-audit.json" 
  --product-name "reporting-api" 
  --engagement-name "Dependencies" 
  --auto-create-context

3. Reimport on each build. Send later reports to /api/v2/reimport-scan/ against the same Test so upgrades mitigate the old Findings and history stays together.

Data Granularity: What Gets Imported

Use Cases

In a CI/CD pipeline: Every pull request that changes uv.lock runs uv audit and reimports into the service's Test. Reviewers see new advisories introduced by the change, and upgrades show up as mitigated Findings.

Across many Python services: A team maintaining 30 uv-managed services imports each into its own Asset. When an advisory is published for a common package, searching DefectDojo by CVE lists every service and locked version affected.

Tracking fixes that are not yet available: Advisories with no fixed version have no mitigation text. Those can be risk accepted with an expiry date, so they come back for review when a release is likely to exist.

Alongside container and code findings: The same service's image scan and SAST results sit on the same Asset, so a Python dependency advisory can be compared with the OS packages and code issues in the same release.

Operational Tips

• Since every Finding imports as Medium, use DefectDojo's Vulnerability IDs to cross-reference CVE severity from other sources before prioritizing. In DefectDojo Pro, the Rules Engine can set severity on Findings that match a filter.
• Do not rely on minimum_severity to thin out uv audit imports. With every Finding at Medium, a threshold above Medium imports nothing.
• Run the audit against a fresh lockfile. An outdated uv.lock reports packages that are no longer what you deploy.
• Pin the uv version in CI. The JSON schema is experimental, and the schema version in each description helps confirm which format produced a Finding.
• Tag imports with the branch or release so findings can be split between main and long-lived release branches.
• Reimport into one Test per project. A version bump then appears as one Finding mitigated rather than as two open copies.