A container scan report is a table of findings, and each column has a specific meaning. Installed version is what the image holds, fixed version is the first release with the patch, source package is what the binary was built from, and layer is the build step that added it. This glossary defines the rest.
Core terms
| Term | Definition |
|---|---|
| Finding | One match between a package in the image and a known vulnerability |
| Package | An installed unit of software, from the OS package manager or a language ecosystem |
| Installed version | The version recorded in the image's package database or metadata |
| Fixed version | The first version the vendor says contains the patch. Blank usually means none published for your release |
| CVE | An identifier for a publicly disclosed vulnerability |
| Severity | A rating of impact, from a vendor or a scoring system. Different sources can disagree |
| Vendor status | The distribution's own state for the issue, such as fixed, deferred or ignored |
| Source package | The upstream source a distribution builds binary packages from |
| Binary package | The installable package in the image |
| Layer | A filesystem changeset added by one build step |
| Digest | A content hash that identifies an image or layer. It changes when content changes |
| Tag | A movable label such as latest. It can point to different digests over time |
| Base image | The image named in the first line of a build, whose layers come first |
| Path or location | Where the scanner found the package in the filesystem |
Reading across a row
Start at the package and installed version. Check the fixed version. Look at the vendor status, since a High with status ignored behaves differently from a High with a fix ready. Then read the path to learn who owns it: an OS location, a language package directory, or a compiled binary.
For versions, the rules differ by ecosystem. Debian policy defines epoch, upstream version and revision, compared in that order. Other systems have their own rules, so use the right package manager when comparing.
Terms people confuse
- Digest versus tag. A digest is content, a tag is a pointer. Deploy and scan by digest. See can you rely on a tag staying the same.
- Severity versus status. Severity is how bad, status is what the vendor will do.
- Installed versus exploitable. A package can be present without its vulnerable code running. See installed is not exploitable.
- Layer versus image. A fix cannot edit a layer, since layers are immutable. You rebuild the image with different inputs.
Terms about the report itself
| Term | Definition |
|---|---|
| SBOM | A list of components in the image, which a scan matches against vulnerability data |
| VEX | A statement about whether a product is affected by a given vulnerability |
| Exception | A recorded decision to accept a finding for a limited time |
| Gate | A rule that fails a build or blocks a deploy on certain findings |
| Rescan | A new scan of the same image after vulnerability data changes |
Using the glossary
Share it with teams who receive scan reports but do not build images, such as managers, auditors and customers' security reviewers. It cuts back-and-forth. For how to work a long list, see what to do first when a scan shows hundreds of findings.
Where Safeguard fits
Safeguard's SBOM and dependency scanning produces these fields per image, and you can try it with a free scan at gold.safeguard.sh/scan.
Quick check
Is the fixed version the version I should install?
It is the minimum. Installing the latest available from your vendor's repository is normally fine and includes it.
Why does my report show a digest and a tag?
The tag is the human label you scanned, and the digest is the exact content. Keep the digest as evidence.
Sources
Last reviewed: 19 October 2026.
