Know which of your projects are exposed, and whether it matters.
An advisory lands. Nobody can say which services ship the affected version, and the scanner lists every occurrence as if each one were exploitable. The team spends the day on the list instead of on the fix.
Scanners report presence, not exposure.
A software composition scan lists every vulnerable package it can find in the dependency graph. Many are dev-only, pulled in transitively and never loaded, or declared and forgotten. Each one is reported with the same severity as a package your request handler actually calls.
Exposure is a question about releases, not repositories. Which version of which service is running with the affected package, and was it the release before the fix or the one after? Without a bill of materials per release, the answer is reconstructed from deployment history.
A count of findings per repository does not say which team owns the service or which one to patch first.
A bill of materials per release, and an exposure answer per project.
Projects in Dependably Packages holds a software bill of materials for every release of every project, tracks which packages each one ships, and uses whether first-party code can reach the affected package to order each advisory. The reachability comes from a companion tool that runs in your CI.
Analyze the build in CI
sbom-reach runs against the repository, generates a CycloneDX SBOM, looks up vulnerabilities against the public OSV database or a private vulnerability service you point it at, and annotates each one with package-level reachability: whether first-party code imports the package or never references it, and, given a symbol manifest, whether the vulnerable functions are ever called. Reachability covers npm, NuGet, and Python. A Python package whose import name has to be guessed is reported unknown rather than not-observed.
bom.cdx.json · results.sarifUpload to the project version
The SBOM is uploaded to the project version, and the SARIF log writes the reachability facts onto it. A version can be promoted to latest, and the dashboard answers for the promoted release.
PUT /api/v1/sbom · /api/v1/sarifPriority by reachability
Each advisory is placed in a priority bucket, track, attend, or act, from its CVSS score, KEV listing, and EPSS probability. A KEV listing puts it in act whatever the analysis says. Otherwise it is moved by what the analysis observed: reachable promotes it one bucket, not-observed demotes it one where the analysis covered that ecosystem and the package has no install script, and imported-not-called or unknown leave it in place.
reachable · not-observedRoll up across projects
The projects nest in collections, and severity, policy status, and last-upload time roll up the tree, so a team's exposure and a portfolio's exposure are the same query at different depths. Any version exports its SBOM, and its vulnerability decisions as VEX.
rollup · exportThe list of what to patch first, per service.
When an advisory lands, which releases ship it and whether your code can reach it is an answer in the dashboard.
- Every project version carries the SBOM it was built from, so the answer is per release.
- Advisories your code can reach sit at the top; ones nothing references sit below, still visible.
- Policy status per version says whether a release passes your rules before it ships.
- Rollups by collection show which team or portfolio carries the exposure.
- advisory example-parser@3.1.0 · high
- reachable src/api/upload.ts imports it
- priority attend → act
- ships in billing-api 2.8.0 · portal 5.1.2
Self-hosted, or hosted by us on request.
Projects is part of Dependably Packages, which ships as a single container image under Apache-2.0. sbom-reach is Apache-2.0 licensed and is built from source with Node and pnpm; NuGet reachability also needs the .NET SDK. Dependably Cloud runs the same engine on a paid plan we operate; get in touch to talk about a hosted deployment.