A container scan can show both a Linux distribution advisory and a library CVE because they are separate records about one underlying flaw. The OSV schema links them with an upstream field, not as aliases. Read both: the distribution record tells you what its package does, and the library record tells you about the code.
How the two records arise
A library is written upstream, say by an open source project. A Linux distribution then packages that library, sometimes with its own patches. If a flaw is found, the upstream project can get a CVE, and the distribution can publish its own advisory about its package.
The OSV schema addresses exactly this. It says aliases should not be used to refer to vulnerabilities in packages upstream or downstream in a software supply chain. If a CVE describes a flaw in a language library, and a distribution package contains that library and publishes an advisory, the distribution record must not list the CVE as an alias. Instead it uses the upstream field.
| Field | Use |
|---|---|
| aliases | Same vulnerability in another database |
| upstream | This record's flaw originates in another record, up the supply chain |
| related | Closely related, but not an alias or upstream |
The schema also says upstream is transitive: if C is upstream of B and B is upstream of A, then C is upstream of A. And it is one way: if B is upstream for A, A cannot be upstream for B.
What this means in your report
Your scan may show two rows: one for the OS package, with the distribution's ID, and one for the library or CVE. They are not duplicates in the strict sense. They describe the same flaw at two layers.
The practical differences:
- Fix versions differ. The distribution's fixed version is a package version in its own scheme, which may be a backport. The upstream fixed version is the project's release number.
- Status differs. A distribution may rate or defer a flaw differently from the upstream project.
- Ownership differs. You fix the OS package by updating the image or package. You fix an upstream library by changing the project's dependency.
How to read them together
- Find the layer that actually contains the file. Is it an OS package in the image, or a language package your app installed?
- Use the fixed version from the record that matches that layer.
- If the distribution record says the package is fixed at a given package version, compare with the installed package version, not the upstream release number.
- Group the two rows in your tracker, with a note that they share an origin, and close both when the layer you control is updated.
For identifier details, see PURL for Debian packages.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at which layer each finding belongs to, and which fixed version applies to it.
Quick check
Should I merge a distro advisory with its upstream CVE?
Link them, but do not treat them as the same record. They can have different fixed versions and statuses.
Which fixed version do I compare against?
The one from the record for the layer you are fixing. For an OS package, that is the distribution's package version.
Safeguard offers dependency scanning with SBOM output and reachability analysis, and the free scan lets you try it on your own project.
Sources
Last reviewed: 19 October 2026.
