SecDB is the past, OSV is the future

If you use a vulnerability scanner to scan Chainguard Containers, there's a good chance it's been consuming our SecDB security feeds for Wolfi and Chainguard distros. Since mid-2024, we've also been publishing an Open Source Vulnerabilities (OSV) schema format security feed alongside SecDB – steadily expanding its precision and coverage of vulnerability data. As OSV has matured, the gap between what it can express and what SecDB can represent has grown to the point where the legacy format can no longer keep up. Today, we're formally announcing that SecDB is deprecated and will sunset at the end of 2026.

Why we're moving on from SecDB

The decision to use SecDB was largely influenced by our decision to build Chainguard packages based on the Alpine packaging format – Alpine uses SecDB feeds, so adopting it was a natural starting point. But SecDB was designed around a simpler model of vulnerability tracking. As Chainguard's advisory data (i.e., our formal, public notifications about vulnerabilities in our packages) has grown more precise, two fundamental limitations have made it an increasingly poor fit.

First, SecDB lacks a formal way to indicate that a vulnerability exists but has no fix yet. Because it can only communicate a vulnerability once a remediation exists, scanners consuming it get an incomplete picture. For false positive determinations (i.e., when triage confirms a package is not vulnerable to a CVE and requires no remediation), our SecDB feed works around this limitation by setting the fixed version to "0." Still, unfixed vulnerabilities that Chainguard has triaged and is actively tracking cannot be represented in SecDB.

Second, SecDB tracks advisories at the "origin" package level only, using two coordinates: package and vulnerability. Historically, Chainguard tracked vulnerability data at a similarly coarse level of granularity. Still, recent improvements to our internal advisory database now enable tracking at a much finer grain, including six coordinates: package, vulnerability, architecture, component location, component type, and component name. The additional granularity matters because the same vulnerability can have different statuses across components of the same package. When six-coordinate advisories get collapsed down into the two-coordinate format that SecDB requires, information is lost, and scanners can end up with a partially inaccurate picture. At this stage, decisions must be made on how to represent a mixed-status vulnerability as a single entry in the feed: do we bias toward NAK or not?

The table below shows how each decision affects scanner behavior.

Why OSV is the right answer

Two years of running both the SecDB and OSV feeds in parallel have made it increasingly clear why OSV is the better choice for the modern supply chain, and why the limitations of SecDB are harder to ignore.

OSV's extensible schema is a key part of why it's the better fit. Through Chainguard's extensions to the ecosystem_specific field, our feed can represent per-component, per-architecture, per-location advisory status – rather than flattening advisory data into a single origin-level entry. Our upcoming OSV V2 enhancements will surface this full granularity to scanner vendors, including package, vulnerability, architecture, component location, component type, and component name.

To make this concrete, consider a package like druid with a vulnerability in several bundled JARs. In our advisory database, we may have determined that the vulnerability is a false positive in four of eight component locations, genuinely fixed in two others, and still under investigation in two others.

Here's what each feed communicates to scanners:

Note: As stated earlier, Chainguard's introduction of more precise coordinates highlighted the impact and need for bias in our SecDB feed. To maintain scanner compatibility and avoid regressing on vulnerability reporting for downstream users, we made the short-term decision to bias our SecDB toward NAK. This prevents scanners from over-flagging vulnerabilities, but, as the table illustrates, some degree of inaccuracy is unavoidable in SecDB either way. This is precisely why we are deprecating our SecDB feed and working closely with scanner partners to adopt the more accurate OSV feed as soon as possible (more details below).

In addition to the granularity improvements, V2 will also introduce advisories for unfixed vulnerabilities in our OSV feed – covering statuses such as under investigation, pending upstream fix, affected, and fix not planned. This closes another critical gap that SecDB was never able to address but is crucial to customers.

OSV also benefits from an active and growing ecosystem. Maintained by Google and adopted across the broader open source community, tooling support continues to expand independently of Chainguard's own efforts – something SecDB, as a format tied to the Alpine packaging ecosystem, was never designed to do. Chainguard's advisories are also indexed on osv.dev, a centralized public database that aggregates feeds from across the industry, making our data discoverable and interoperable well beyond the scanners we directly partner with.

On a related note: Chainguard plans to publish a Vulnerability Exploitability eXchange (VEX) feed for our package vulnerability data to supplement our OSV feed. An OSV feed lists vulnerabilities, but VEX tells you whether they actually impact your specific software or environment (i.e., context rather than just raw vulnerability data). It explains if something is exploitable or already mitigated. These VEX feeds can be used alongside OSV feeds to help scanners surface only the most relevant vulnerability insights while minimizing noise. Currently, Chainguard publishes a VEX feed for our secure libraries product – details here.

How to start using OSV today

Chainguard's current OSV data is available at https://osv.dev/list?ecosystem=Chainguard, and our scanner integration guide walks through detailed instructions for consuming it. In parallel with launching the updated V2 feed in the coming weeks, we're working with scanner partners to get them migrated from SecDB to OSV. Google Artifact Analysis and Docker Scout already support our OSV feed. Black Duck also now supports OSV, and more scanners are expected to follow suit in the coming months, including Amazon Inspector, Grype, Qualys, and Wiz. If you want to understand why Chainguard partners with scanner vendors to consume our advisory data, we've written about that in depth here.

Using a different scanner?

If your scanner isn't listed above and you'd like it to support Chainguard's OSV feed, the most effective approach is to register the request directly with your scanner vendor, then let your Chainguard account team know. We're tracking scanner partner adoption and can help prioritize engagement where there's demonstrated customer demand.

Our SecDB feeds for Wolfi and Chainguard distros will remain functional through the end of 2026, so there will be no immediate disruption. But we'd encourage moving sooner rather than later. OSV gives a more accurate, more complete view of vulnerability status in your Chainguard Containers, and that's the picture worth acting on.