SBOM & dependencies
Which open-source packages put this product at risk
Most of a modern product is open source. CodeDD inventories every package across the estate — every repository in scope — and shows which versions are vulnerable, outdated, or poorly maintained.
1
Critical CVE
3
High
11
Medium
~5 days
To patch all 15
| Package | Scope | Times used | Known CVEs | Maintained |
|---|---|---|---|---|
| marimo | Direct | 4 | Active | |
| dagster | Direct | 72 | Active | |
| lxml | Direct | 1 | Active | |
| duckdb | Direct | 37 | Active | |
| pydantic-ai | Direct | 1 | Active |
Selected · marimo 0.19.10
Critical: remote code execution without login. Fixed in 0.24.0 — cube-pipelines is five releases behind. About a day to upgrade and test.
Trusted by
Beyond an SBOM export
An SBOM is a list. You need the exposure.
A package list says what was declared. The questions that matter are which versions are vulnerable, where they are used, and what will need work anyway.
Every package, from the source
Manifests and imports across npm, pip, Maven, Go, Cargo, .NET, and more — every package, per repository, exportable as a CSV.
Vulnerabilities matched, not guessed
Known CVEs from NVD, OSV, and GitHub Advisory are matched to the exact version shipped. Deterministic — no AI judgement in this step.
Maintenance risk in view
Version lag, maintainer hygiene, and end-of-life dates where available — the packages that need work even without a CVE.
Across the investment cycle
Why it matters in a deal
Pre-deal tech DD
Know whether the product ships a known Critical vulnerability — and what patching it costs — before signing.
Hold period
Patch by severity, not by alert volume, and plan the major upgrades before they turn urgent.
Pre-sale preparation
Patch what a buyer's scan would find, then hand over the SBOM as a CSV. Regulation such as the EU Cyber Resilience Act raises the bar on both.
Version lag
Outdated before it is vulnerable.
Every package shows how far the shipped version lags and whether it is still maintained. Major versions behind are expensive upgrades; an abandoned package needs a replacement. Plan both before a CVE forces the timing.
3
A major version behind
1
No longer maintained
53
Direct packages
| Package | Repos | Version lag | Maintenance |
|---|---|---|---|
| legacy-soap-client | 1 | Major lag (3) | Inactive |
| redis | 2 | Major lag (2) | Active |
| celery | 1 | Major lag (1) | Maintained |
Selected · legacy-soap-client
Three major versions behind, and no release in over a year. Plan a replacement, not an upgrade.
Package health
Know how far to trust a package.
OpenSSF Scorecard rates how a package is maintained, and the map shows where it is used — so the reach of an upgrade is known before anyone touches it.
4.8
OpenSSF · dagster · /10
Used in 42 files across 2 repositories
FAQ
Questions
How is this different from a scanner like Snyk or Dependabot?
Those tools list CVEs per repository for the engineering team. CodeDD matches the same advisories, then puts every package on one estate-wide view: how widely it is used, how far behind it is, how well it is maintained, and what patching costs. It is built for a decision, not only for a backlog.
What is the difference between direct and transitive packages?
Direct packages are the ones the team chose — declared in a manifest or imported in source. Transitive packages come in underneath them. The default view is direct, because that is what the team controls; the full tree is one click away.
Where do the vulnerability matches come from?
Declared versions are matched against NVD, OSV, and GitHub Advisory. The matching is deterministic, not an AI review of the package source. Advisory IDs (CVE, GHSA, PYSEC) stay on each package.
Do you show end-of-life and LTS?
Yes, where a maintained release line can be resolved. Coverage varies by ecosystem and is not a complete end-of-life catalogue, so read it next to version lag rather than on its own.
What does the OpenSSF Scorecard tell me?
It scores how a package is maintained — branch protection, code review, CI, signed releases, and more — out of 10. A low score is a hygiene warning, not a vulnerability; it tells you how much to lean on a package.
Can we export the SBOM?
Yes, as a CSV of the current view: one row per package and repository, with declared and latest version, version lag, LTS, maintenance status, last release date, how often it is used, vulnerability counts by severity, and the OpenSSF score.
Where are licences covered?
On Licences. Same package inventory, different risk: this page asks whether a package is vulnerable, Licences asks whether it can be shipped.
See the open-source risk in a codebase you are evaluating
Run it on a repository yourself, or book a walkthrough of the vulnerable packages, the version lag, and the cost to patch.