A scanner checks each Alpine package version in your image against a security database that Alpine publishes for every release branch. That database lists which package versions fixed which CVEs. If your installed version is older than a listed fix, the scanner reports the CVE. It is a list of fixes, not a list of every open problem.
What the published data looks like
Alpine hosts a security database at secdb.alpinelinux.org, with one directory per release branch such as v3.21, plus edge. Inside each branch, files for the main and community repositories are JSON. A fetched sample shows the shape: each package has a name and a field called secfixes, which maps a fixed version to a list of CVE identifiers. For example, one entry maps a version string ending in r0 to three CVE ids.
The same file also carries the architectures the branch supports and a URL template for the package files. The data is organized by package, then by the version in which the fix landed.
What this means for a scan
The logic is simple:
- The scanner reads the installed package name and version from the image.
- It finds that package in the database for the image's Alpine branch.
- For each fixed version listed, it compares. If the installed version is lower, the CVE applies.
Two consequences follow.
First, the database tells you about CVEs that were fixed. A vulnerability that Alpine has not yet fixed does not appear as a fix entry. A scanner that only uses this file will not show it, so many scanners combine it with other sources such as the national vulnerability database or upstream advisories to cover unfixed items. Ask your vendor which sources it merges.
Second, the branch matters. An image built on one release is compared against that release's data. If you run an old branch that is no longer maintained, new fixes may never be added, and the scan can look clean for the wrong reason. Alpine's release page explains that a release branch is made from edge each May and November, and that the main repository is typically supported for two years, with the community repository supported until the next stable release. Check the exact dates on the release page for your branch.
Why version strings matter
Alpine versions carry a revision suffix, such as r0 or r1. The suffix records packaging revisions, so comparing versions correctly needs Alpine's own ordering rules, not a plain text comparison. A scanner that compares versions loosely can miss a fix or flag a fixed package. When you test a tool, include an Alpine image with a package you know was patched in a later revision.
Questions for a vendor
- Which Alpine data do you use, and how often do you refresh it?
- How do you report vulnerabilities with no fix yet?
- What happens when an image uses a branch that is out of support?
- How do you compare Alpine version strings?
A worked example with real data
The database is easy to inspect yourself. Fetching the v3.21 main file and looking at the apache2 package shows how fixes are recorded. In the fetched data, the entry for version 2.4.51-r0 lists CVE-2021-42013, the entry for 2.4.50-r0 lists CVE-2021-41524 and CVE-2021-41773, and the entry for 2.4.49-r0 lists five CVEs including CVE-2021-40438.
Now suppose an image carries apache2 at 2.4.50-r0. A scanner compares that version with every fix entry for the package. Fix entries at or below 2.4.50-r0 are already included in that version, so they do not apply. Any fix entry above it, such as 2.4.51-r0 with CVE-2021-42013, applies, because the image has not reached that fix.
That is the whole mechanism. You can reproduce it with a download and a short script, and it is a good way to sanity check a tool during a trial.
Cross-checking with an independent source
OSV, an open vulnerability database, also carries Alpine data. A query for apache2 version 2.4.50-r0 in an Alpine ecosystem returns, among other records, ALPINE-CVE-2021-42013, which names CVE-2021-42013 as its upstream identifier and records a fix at 2.4.51-r0. That agrees with the Alpine file. Agreement between two independent sources raises your confidence in a tool that reports the same result.
Step by step: check one package by hand
- List the installed packages in the image with the package manager inside it.
- Pick one package and note its exact version string, including the revision suffix.
- Download the security file for the image's Alpine branch and repository (main or community).
- Find the package and read its fix entries.
- Mark every fix entry whose version is higher than your installed version.
- Compare your list with the scanner's output for that package.
If the lists differ, check the branch first. A common cause is a scanner using a different branch than the image reports.
What the database leaves out
| Not in the fix list | Where it may come from |
|---|---|
| Vulnerabilities with no fix yet | Other advisory feeds, or the national database |
| Packages installed outside the package manager | Binary or file scanning, which is a different technique |
| Vulnerabilities in your application libraries | Language ecosystem databases |
| Branches that no longer receive updates | Nothing, which is the risk |
The last row is the most important for buyers. If your image sits on a branch that has reached end of support, the fix list stops growing, and a scan can look reassuring while real issues go unrecorded. Compare your branch with the dates on the release page every quarter.
Common mistakes
- Comparing version strings as plain text. Use Alpine's ordering rules.
- Ignoring the revision suffix.
- Scanning an Alpine image with data for a different branch.
- Reading "no findings" as "no problems" on an unsupported branch.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how the report lists the package, the installed version and the version that contains a fix.
Where Safeguard fits
Safeguard scans image contents and dependencies and reports fix versions where they are known. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Does a clean Alpine scan mean no known vulnerabilities?
Not necessarily. It means no fixed CVEs apply to your installed versions, and possibly that unfixed ones were not in the data used.
Is Alpine data the same for every release?
No. Each release branch has its own database, so the branch of your image decides what it is compared against.
Can I verify a scanner's Alpine result without trusting the scanner?
Yes. Read the package version in the image and compare it with the fix entries in the published security file for that branch. A second check is a query to a public database such as OSV.
Sources
Last reviewed: 19 October 2026.
