Choose a Base Container Image with Gold Open Source

To choose a base container image with Gold Open Source, shortlist two or three candidates from trusted publishers, scan each one with Safeguard's container image scanning to see the OS packages and libraries it actually carries, then look those packages and the CVEs that matter up in the free Gold Open Source search at gold.safeguard.sh (CVSS, EPSS, CISA KEV status, affected and fixed versions, and the "Am I affected?" check). Pin the winner by digest and gate it in CI. Gold Open Source tells you what is publicly known about a component. Your own scan tells you what is inside the exact image you will ship.

Those last two sentences are the honest core of this post. A base image is the one dependency every service in your fleet inherits, and the decision usually gets made once, by one engineer, on a Friday, by copying a FROM line from an older project. This guide replaces that habit with a short, repeatable method that uses Gold Open Source for the public intelligence and the Safeguard platform for the image-specific evidence.

Key takeaways

• Gold Open Source (GA) is free and needs no login. Its package and CVE search shows, for each library or CVE, which versions are hit and which fix it, along with the CVSS score, the EPSS probability and whether CISA lists it as exploited. You use it to check the OS packages and libraries inside each candidate, one by one or in a script.
• "Gold Certified" has a narrow meaning. Safeguard's docs say it means Gold knows of no vulnerabilities in the version it indexed and the component is not deprecated. Gold Open Source does not rebuild, sign or attest components.
• The Gold Open Source CVE database (GA) shows CVSS, EPSS, CISA KEV status and affected and fixed versions, and each CVE page has an "Am I affected?" check. Not every CVE is in the index yet, so a "not found" result is not a clean bill of health.
• Container image scanning (GA, part of SCA) in the Safeguard platform reads the candidate image's layers and lists the OS packages and libraries in each one, so you compare candidates on their real contents rather than on their reputation, and you know exactly which packages to look up.
• The Safeguard CLI (GA) scans an image in CI with safeguard ci scan --image, records it per environment and can fail the build at a severity you choose.
• Policies and gates (GA) keep the chosen base from drifting. SBOM generation (GA) gives you an inventory of the image you picked.

Why choosing a base image is a security decision

What goes wrong without a method

Every container image you build starts from a parent. Everything in that parent ships with your service: the C library, the shell if there is one, the package manager, certificate bundles, compression libraries, locale data and whatever else the publisher decided to include. If you build forty services on the same parent, you have forty copies of each of those components to track.

Three failure modes show up again and again.

The first is inherited vulnerability volume. A general purpose distribution image carries hundreds of packages, most of which your application never touches. Each one can pick up a CVE. Your scanner reports them all, your team learns to ignore the report, and the one finding that matters gets lost in the pile.

The second is drift. A tag such as ubuntu:24.04 or python:3.12-slim is a pointer, not a fixed artifact. Docker's own build best practices note that over time a tag may resolve to a different underlying version as the publisher rebuilds it with new patches. That is good for freshness and bad for reproducibility. Two builds of the same Dockerfile a month apart can produce different images, and nobody decided that on purpose.

The third is the untracked choice. Nobody wrote down why the team picked a given base, who maintains it, how often it is rebuilt or what happens when it reaches end of life. When the next serious library CVE lands, nobody knows which services are exposed until someone scans all of them.

What the standards say

You do not need a regulation to tell you that inherited risk is still your risk, but the main references are clear and worth citing in your own internal policy.

NIST SP 800-190, the Application Container Security Guide. Section 3.1 lists the risks that live in images. Section 3.1.1 explains that images are static archives, so components inside them fall out of date and, unlike traditional servers, the fix has to be made upstream in the image, which is then redeployed. Section 3.1.2 covers configuration defects such as running as a privileged user or shipping an SSH daemon. Section 3.1.5 covers the use of untrusted images from external sources. The matching countermeasures are in section 4.1. Section 4.1.1 asks for visibility into vulnerabilities at every layer of the image, not only the base layer, and for policy driven "quality gates" at each stage of build and deployment, with the example of blocking images whose CVSS ratings exceed a threshold. Section 4.1.2, item 4, recommends base layers from trusted sources only, frequent updates of base layers, and minimal base layers to reduce attack surface. Section 4.1.5 recommends maintaining a set of trusted images and registries and allowing only those to run.

NIST SP 800-218, the Secure Software Development Framework (SSDF). Practice PW.4 is "Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality". Task PW.4.1 is to acquire and maintain well-secured software components, and task PW.4.4 is to verify that acquired commercial, open source and other third-party components comply with your requirements throughout their life cycles, including regularly checking for publicly known vulnerabilities. A base image is an acquired third-party component in exactly this sense. If you attest to the SSDF, your base image selection and refresh process is part of the evidence.

CISA's Known Exploited Vulnerabilities (KEV) catalog. CISA describes KEV as the authoritative source of vulnerabilities that have been exploited in the wild and tells organisations to use it as an input to vulnerability prioritisation. US federal civilian agencies now prioritise under Binding Operational Directive 26-04, which CISA's KEV entries reference for risk-based remediation. BOD 22-01, the older KEV directive, has been revoked and superseded, so treat its fixed deadlines as history.

FIRST's Exploit Prediction Scoring System (EPSS). FIRST describes EPSS as a model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days, published daily for every CVE as a value between 0 and 1 with a percentile. FIRST's CVSS remains the common severity scale. Severity tells you how bad a flaw could be. EPSS and KEV tell you how likely it is to be used. You need both when comparing two base images, because a base with fewer findings is not better if one of them is in KEV.

The OCI Image Specification. The descriptor section of the specification defines the digest as a content identifier that enables content addressability, and explains that a digest is confirmed by independently recalculating it. This is why pinning by digest works: a digest names exactly one set of bytes, while a tag names whatever the publisher points it at today.

Where Gold Open Source fits

Gold Open Source is Safeguard's free, no-login public directory of open source software and what is publicly known about its security, at gold.safeguard.sh. It covers packages across more than 20 ecosystems, CVEs, CWEs, MITRE ATT&CK, AI models, MCP servers, agent skills and chip manufacturers. For this task, three parts of it matter: the package and CVE search with its "Am I affected?" check, the free read API behind it, and the dependency scanner. The Gold Open Source workflow post covers its API, badges and RSS feeds in depth, so this post stays on the base image decision.

What Gold Open Source gives you for a base image decision

A base image is not one component. It is a bundle of OS packages and libraries: a C library, a TLS library, compression libraries, a certificate bundle, and often a language runtime with its own package manager. The useful question is not "is this image good?" but "what is publicly known about the packages inside it?". Gold Open Source answers that second question, one package or CVE at a time, and Safeguard's image scan tells you which packages to ask about.

Package and CVE search

The search box at gold.safeguard.sh takes a package name or a CVE ID. A package page shows the version Gold indexed, its vulnerability count, its license and whether it is deprecated, with the advisories behind the count. A CVE page shows the CVSS score, the EPSS score, whether the CVE is in the CISA KEV catalog, and which versions are affected and which are fixed. Safeguard's docs describe the CVE database as searchable by package, severity or ecosystem.

The "Am I affected?" check

Every CVE page includes an "Am I affected?" check. Enter the version of the package you found in the candidate image and you get an immediate verdict against the advisory's affected and fixed versions. During base image selection this is the quickest way to turn a scan finding into a yes or no for each candidate, as long as you keep the backport caution in step 5 in mind.

The free read API

The same data is available as JSON, with no account and no API key, from the endpoints listed on the Gold developers page. All of them are GET requests rooted at https://gold.safeguard.sh:

That makes it easy to check a whole candidate at once. Copy the CVE IDs from each candidate's Safeguard scan results into a text file, one per line, and loop over them:

while read -r cve; do
  curl -s "https://gold.safeguard.sh/api/vulnerabilities/$cve"
  echo
  sleep 1
done < candidate-a-cves.txt > candidate-a-gold.jsonl

A CVE that Gold has not indexed comes back as {"detail":"Vulnerability not found"}. That is missing information, not a verdict, so look those up in NVD or the upstream advisory. A populated package result carries fields such as name, ecosystem, version, vulnerabilities, vulnerabilityIds, license, deprecated and lastUpdated.

The developers page asks you to cache responses rather than request them on every page load. Run the loop once per candidate during selection, keep the output with your decision note, and do not wire it into every build.

What "Gold Certified" means, and what it does not

Safeguard's Gold Open Source docs define the rule in one sentence: a component shows as Gold Certified when Gold knows of no vulnerabilities in the version it indexed and the component is not deprecated. The docs add that this is the whole rule. It describes what is publicly known about the upstream release. Gold Open Source does not rebuild, sign or attest components, and the labels on a component's verification panel are not separate scans.

For base images, that has three practical consequences:

1. It is about a package version, not an image tag. "No known vulnerabilities" applies to the version Gold indexed. The package version inside the image you pull may differ, and the tag you pull tomorrow may point somewhere else.
2. It is about public knowledge. A CVE that has not been published, or has not reached the sources Gold aggregates, will not show up.
3. It is not your image. Gold describes packages one at a time. It does not tell you what a given image contains or how those packages were built into it. You still need to scan the candidate image itself, and later scan what you build on top of it.

How to choose a base image with Gold Open Source and Safeguard, step by step

The walkthrough below uses only surfaces that exist today: the Gold Open Source web pages and free API, the Safeguard platform's container image scanning, and the Safeguard CLI as Safeguard's docs show it. Where a step depends on something we could not confirm, we say so.

Step 1. Write down what the image has to do

Before you look at a single image, write five lines in the pull request or design note:

1. Runtime. The language runtime and major version (for example, a specific JVM, Python or Node.js release), or "none" for a statically linked binary.
2. C library. Whether your binaries or native extensions need glibc or can run on musl. Switching C library under a working application is a common source of subtle bugs.
3. Shell and package manager at runtime. Whether anything in production needs sh, apt, apk or similar. Usually the honest answer is "only during build".
4. Architectures. Which CPU architectures you deploy to.
5. Support window. How long the publisher commits to security updates for the release you pick.

This list is what lets you reject candidates quickly. It also becomes the "why" that nobody wrote down last time.

Step 2. Build a shortlist from trusted publishers

Pick two or three candidates. Docker's build best practices recommend a trusted source and a small image, and point to curated programs such as Docker Official Images and images from verified publishers. NIST SP 800-190 section 4.1.2 says the same in standards language: base layers from trusted sources only, updated frequently, and minimal where possible.

Typical shortlists look like one of these:

• A slim variant of a general purpose distribution (for example a Debian or Ubuntu based "slim" image) when you need glibc and a familiar package manager during build.
• A small musl based distribution such as Alpine Linux when your stack is known to work on musl.
• A distroless style runtime image with no shell or package manager, used as the final stage of a multi-stage build.
• An empty base (FROM scratch) for a fully static binary.

Docker also recommends using two kinds of base image, one for building and testing and a slimmer one for production, which its multi-stage build docs describe how to do. If you take one idea from this post, take that one: the build stage can be as heavy as you like, and the final stage should carry only what the application needs to run.

Step 3. Scan each candidate in Safeguard

This is the step that produces evidence about the exact bytes you will pull. Safeguard's container image scanning (GA) is part of its SCA. Safeguard's docs say it scans container layers to identify dependencies and vulnerabilities across base image layers, OS packages, application dependencies and embedded binaries. The container scanning post explains what each layer contributes.

There are two documented routes for scanning a candidate.

Route A: the CLI in a pipeline or on a build machine. Safeguard's CI docs for container images show one step after the image is built:

safeguard ci scan --image "ghcr.io/acme/api:$TAG" --environment prod --wait --fail-on critical

For candidate evaluation, point --image at each candidate base instead of your application image, use an environment name that marks it as an evaluation (the docs allow any name made of letters, digits and dashes), and leave off --fail-on so the run reports rather than blocks. The docs explain the rest of the setup:

• You need a Safeguard secret key with the scans:trigger and scans:read scopes. Admins create one in the Set up CI/CD sheet or under Settings → Developer. Store it in CI as SAFEGUARD_API_KEY.
• If the step runs on the machine that has the image in its local Docker daemon, there is nothing else to configure. Otherwise, set SAFEGUARD_REGISTRY_USERNAME and SAFEGUARD_REGISTRY_PASSWORD so the scan can pull it.
• Only the results leave the runner, and no repository integration is needed.
• Each image is recorded under its repository, with one version per environment and tag (for example prod-1.4.2). A latest or missing tag uses the build's commit.

Route B: the registry integration in the app. Every container registry card under Integrations has a Set up CI/CD button. You pick your CI, the image and the environments, and it gives you the steps. If your candidate images are already mirrored into an internal registry, this is the faster way to get them all scanned. The per-environment image tracking post walks through registry credentials and environment naming in detail.

Run the same route for every candidate. What you want at the end is two things: the list of OS packages and libraries in each candidate with their versions, and a small table with candidate, digest, number of OS packages, total findings, findings with a fix available, findings in KEV, and the highest EPSS score.

Step 4. Look up each candidate's packages and libraries in Gold Open Source

With the scan results in hand, you know which OS packages and libraries each candidate carries, and at which versions. Now find out what is publicly known about them.

1. Open gold.safeguard.sh and search for the packages that matter most in a base image: the C library, the TLS library, compression libraries, the certificate bundle, and the language runtime if the image ships one.
2. For each package, read the vulnerability count, the license and any deprecated flag. A deprecated runtime or library is a strong reason to drop the candidate.
3. For each CVE the scan reported against those packages, open its Gold Open Source page, or call /api/vulnerabilities/{cve} with the loop above, and note the KEV status, the EPSS score and the fixed version.
4. Run the "Am I affected?" check with the exact package version from the scan, not the version you think the image carries.
5. Write the package version from the scan next to the Gold result. If they differ, the Gold result is about a different release.

If Gold has not indexed a package or a CVE, record "not in Gold index" and look it up in NVD or the upstream advisory. Absence from the index is not a verdict either way.

Step 5. Rank the findings that matter

Not every finding deserves the same attention. For each one that could change your decision (anything in KEV, anything with a high EPSS score, anything critical), go back to its page in Gold Open Source's vulnerability database, which also shows the remediation for the advisory, and read it in this order:

1. KEV status. If it is in the CISA KEV catalog, it is being exploited. A candidate that ships it without a fixed package available is a weak candidate.
2. EPSS score and percentile. A high probability of exploitation in the next 30 days moves a finding up your list even when CVSS is moderate.
3. CVSS score and vector. The vector tells you whether the flaw needs network access, privileges or user interaction, which you can compare to how the container actually runs.
4. Affected and fixed versions. These tell you whether a rebuild of the candidate would clear it.

Two cautions belong here.

First, Linux distributions often backport security fixes into older package versions without changing the upstream version number. A distribution package can therefore look "affected" by upstream version ranges while already carrying the fix. For OS packages, the distribution's own security tracker is the authority on whether its package is fixed. Use Gold Open Source to understand the CVE and its exploit signals, and use the distribution tracker to decide whether a given package build is patched.

Second, Gold Open Source's CVE index is not complete yet. In our checks on 25 October 2026, some well known CVEs returned "Vulnerability not found" from the CVE page and the API, and some records were missing fields such as affected versions. Treat a "not found" result as "look elsewhere", not as "not affected", and confirm details against the NVD record or the upstream advisory before you act on them.

Step 6. Check the application layer with the Gold Open Source dependency scanner

Your base image is only half of what you ship. The language packages you install on top of it often carry more exploitable findings than the base does. The Gold Open Source dependency scanner lets you paste or upload a dependency manifest, or a CycloneDX or SPDX SBOM, and see which packages carry known vulnerabilities, checked against the Gold corpus. The page says the file is parsed in your browser and never sent to a server, that it is free with no login, and that it checks up to 100 dependencies.

Use it in two ways during selection:

• Check your application's manifest once, because it does not change between candidates. It tells you how much of your future finding count is yours rather than the base image's.
• Check the runtime packages a candidate pre-installs, for example a language runtime image that bundles its own package manager or tooling, if you can export them as a manifest or SBOM.

The dependency scanner is built for language manifests and SBOMs, and Gold Open Source's package coverage is strongest for language ecosystems. For the OS packages in the image itself, start from the Safeguard scan in step 3 and look the packages up as in step 4.

Step 7. Decide, and write the decision down

Now compare. The decision table below is the one we use; adapt the weights to your environment.

Write the outcome in the same note as step 1: the chosen image, the digest, the date, the scan result summary and the reason it won. That note is your SSDF PW.4.4 evidence that you checked an acquired component for publicly known vulnerabilities.

Step 8. Pin the winner by digest

Pin the base image by digest in your Dockerfile so every build uses the exact bytes you evaluated. The OCI specification is the reason this works: the digest is a content identifier, and anyone can recompute it to confirm the content. Docker's best practices recommend pinning base image versions for the same reason, and note that a tag may resolve to a different image over time.

# Build stage: full toolchain, never shipped
FROM <build-image>:<tag>@sha256:<digest> AS build
# ... compile, test ...

# Final stage: the base you chose, pinned
FROM <runtime-image>:<tag>@sha256:<digest>
COPY --from=build /out/app /app
USER 10001
ENTRYPOINT ["/app"]

Keeping the tag next to the digest makes the line readable to humans while the digest decides what is pulled. The USER line answers NIST SP 800-190 section 4.1.2, which asks that images run as non-privileged users. The digest pinning post covers the trade-offs between tags and digests in more depth.

Step 9. Gate the chosen base and keep watching it

Choosing well is a one-time act. Staying on a good base is a process. Three documented Safeguard pieces cover it.

A gate in CI. Add the safeguard ci scan --image step to every environment's pipeline after the image is built. Safeguard's docs show --fail-on critical for production and no --fail-on in development, so production builds stop on the severity you choose while development keeps moving. This is the "quality gate at each stage" that NIST SP 800-190 section 4.1.1 asks for.

Policies and gates in the platform (GA). Safeguard policies can be written in plain English and attached to gates with Block, Warn or Notify outcomes, so a rule such as "block production images with a KEV finding" lives in one place rather than in every pipeline. The plain English policies post shows how.

Rebuild on a schedule. Docker's best practices say images are immutable snapshots and recommend rebuilding often, using docker build --pull to fetch a fresh base and --no-cache to re-run every step. With a digest pin, "rebuild" means "update the digest, rescan, merge". Do it on a regular cadence and whenever a KEV entry lands on a package in your base.

Prioritisation in the platform uses severity, EPSS and KEV for every finding. The prioritisation post explains how Safeguard ranks findings once your images are tracked.

Requirement, what Safeguard does, and what you still own

What Safeguard does not do

These limits are specific, and you should plan around them.

1. Gold Open Source does not certify your image. Gold Certified describes what is publicly known about the upstream version Gold indexed. Safeguard's docs say Gold Open Source does not rebuild, sign or attest components. Your image, with your packages added, needs its own scan.
2. Gold Open Source does not scan images. It describes packages and CVEs one at a time. The list of what is inside a candidate comes from Safeguard's image scan, and the two are meant to be used together.
3. The Gold Open Source CVE index is incomplete. Some well known CVEs returned "not found", and some records lacked affected version data. Confirm against NVD and upstream advisories before acting.
4. Gold Open Source is not a distribution security tracker. It does not model distribution backports. For whether a specific Debian, Ubuntu, Alpine or RPM package build is fixed, the distribution's tracker decides.
5. Safeguard does not choose the image for you. It gives you evidence about candidates. Requirements, publisher trust, support windows and C library compatibility are your engineering decisions.
6. Safeguard does not enforce what runs in your cluster in this flow. CI gates and platform policies stop images in the pipeline. Admission control at the orchestrator, and the trusted registry list NIST SP 800-190 section 4.1.5 describes, are yours to configure.
7. Configuration hardening beyond packages is yours. Running as a non-root user and removing remote administration tools such as SSH (both covered in NIST SP 800-190 section 4.1.2) are Dockerfile and platform decisions, not something this selection flow checks for you.

Common mistakes

Comparing tags instead of digests. Two engineers compare "the same" tag a week apart and get different results because the publisher rebuilt it. Always record the digest you scanned.

Treating "No known vulnerabilities" as "secure". It means no publicly known vulnerabilities in the indexed version. It says nothing about configuration, about versions Gold has not indexed, or about vulnerabilities not yet disclosed.

Treating "not found" as "not affected". If Gold Open Source has not indexed a CVE or a package, that is missing information. Look the CVE up in NVD or the upstream advisory.

Counting findings instead of weighing them. A base image with 30 findings, none in KEV and all with low EPSS, can be a better choice than one with 8 findings where one is in KEV with no fix. Sort by exploitation signals first.

Reading upstream version ranges against distribution packages. Distributions backport fixes. A package version that looks affected by upstream ranges may already be patched. Check the distribution tracker for OS packages.

Choosing a tiny base your stack does not support. A musl based image that saves a few megabytes but breaks a native extension in production is not a security win. Step 1 exists to stop this.

Picking a base and never revisiting it. A clean base today is not clean in three months. Rebuild on a schedule, rescan, and update the digest.

Shipping the build stage. Compilers, package managers and debugging tools belong in the build stage of a multi-stage Dockerfile, not in the final image.

Gating only in production. If the first time a base image is scanned is the production deploy, the team learns about problems at the worst moment. Scan in every environment and fail only where it matters.

Worked example: two candidates for a Python service

Here is how the method plays out on a typical decision, without naming specific results, because your numbers will depend on the day you scan.

A team runs a Python web service with one native extension that needs glibc. Step 1 rules out musl based candidates, which leaves two: a "slim" Debian based Python image and a distroless style Python runtime image used as the final stage of a multi-stage build.

In step 3 they run safeguard ci scan --image against each candidate digest with an eval environment and no --fail-on. The slim image shows more OS packages, including a shell and package manager, and more findings overall. The distroless style image shows fewer packages and fewer findings.

In step 4 they search Gold Open Source for the C library, the TLS library and the Python runtime from each scan, run the CVE loop against both candidates' CVE lists, and use "Am I affected?" with the exact versions the scan reported. Where Gold has not indexed a CVE, they check NVD instead.

In step 5 they rank the handful of findings that are critical, high EPSS or in KEV, and check the distribution tracker for the OS packages. One finding on the slim image is already fixed in the distribution's package despite the upstream range; they mark it as such.

In step 6 they paste their requirements.txt into the Gold dependency scanner and see that most of their real exposure is in their own dependencies, which no base image choice will change.

In step 7 the distroless style runtime wins on package count and the absence of a runtime shell, and both candidates are equal on KEV. They keep the slim image as the build stage. In step 8 they pin both by digest. In step 9 they add the CI scan step to every environment with --fail-on critical in production, and put a monthly rebuild on the team calendar.

The decision took an afternoon. The note it produced will save the next engineer a week.

FAQ

Is Gold Open Source free for container images?

Yes. Gold Open Source is free and needs no login, including the package and CVE search, the "Am I affected?" check, the dependency scanner and the read-only API. The API needs no key, and the developers page asks you to cache responses rather than request them on every page load.

What does "Gold Certified" mean for the packages in a base image?

Safeguard's docs say a component is Gold Certified when Gold knows of no vulnerabilities in the version it indexed and the component is not deprecated. It describes public knowledge about the upstream release. It applies to one package version, not to an image, and it does not mean Safeguard rebuilt, signed or attested anything.

How do I use Gold Open Source to check what is inside a base image?

Scan the candidate with Safeguard's container image scanning to get its OS packages, libraries and CVEs. Then search those packages and CVEs at gold.safeguard.sh, or call the free read API, and use the "Am I affected?" check with the exact versions the scan reported. Gold tells you what is publicly known; the scan tells you what is actually there.

How do I check whether my base image has a known exploited vulnerability?

Scan the image with Safeguard and look for findings flagged as CISA KEV, or open the CVE on its Gold Open Source page, which shows KEV status. You can also check the CISA KEV catalog directly. For OS packages, confirm in the distribution's tracker whether its package build is fixed.

Should I pin my base image by tag or by digest?

By digest, with the tag kept alongside for readability. The OCI specification defines the digest as a content identifier, so a digest always names the same bytes, while a tag can move when the publisher rebuilds. Update the digest deliberately on a schedule.

Is a smaller base image always more secure?

Not always. Fewer packages usually means fewer future findings, and NIST SP 800-190 recommends minimal base layers. But a tiny image that does not support your runtime, or that you cannot patch on a predictable cadence, can be worse in practice. Weigh exploitation signals and the publisher's update record, not only size.

Can Safeguard scan a candidate base image before I adopt it?

Yes. Container image scanning is GA and part of Safeguard's SCA. Safeguard's CI docs show safeguard ci scan --image with an environment name, and the registry cards under Integrations offer a Set up CI/CD flow. Use an evaluation environment name and leave off --fail-on while you compare.

Does Gold Open Source scan the OS packages inside an image?

Not as a scan of your image. Gold Open Source describes indexed components and CVEs. Its dependency scanner checks manifests and SBOMs against the Gold corpus, which is strongest for language ecosystems. To see the OS packages in a specific image, scan it with Safeguard, then look those packages up in Gold Open Source.

How often should I rebuild my base image?

Often enough that fixed findings do not pile up, and immediately when a KEV entry lands on a package in your base. Docker's best practices recommend rebuilding regularly with --pull. Many teams pick a monthly cadence plus event-driven rebuilds.

Which NIST controls cover base image selection?

NIST SP 800-190 sections 3.1 and 4.1 cover image risks and countermeasures, including trusted and minimal base layers (4.1.2) and trusted image lists (4.1.5). NIST SP 800-218 practice PW.4, tasks PW.4.1 and PW.4.4, covers acquiring well-secured components and checking them for known vulnerabilities.

After you choose: closing the fix gap

Choosing a clean base image lowers how many findings you start with, but every base and every package you install on top of it will eventually carry a CVE. The section below is how Safeguard helps close that gap once you have chosen, for the open source dependencies and images you build yourself.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal with safeguard, and asks it to fix a lodash CVE in a repository: the CLI reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs the install and tests with approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan .. The same CLI (GA) is what runs safeguard ci scan --image against your candidate base images in step 3.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard local runner on your own machine, approves it with its device code, and then scans from the terminal. If your candidate images live in a registry you do not want to expose to a hosted service, running scans from a machine you control is the natural fit for the evaluation in step 3.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. In Claude, add Safeguard from the connector directory rather than configuring a custom server; Safeguard is listed there as a community connector. Once connected, you can ask Claude to list the vulnerabilities in the projects where your candidate images are recorded and compare them, using your own Safeguard data. The connector directory post covers the install.

Click through it at your own pace, or open it full screen.

To try the method on your own candidates, download Safeguard and follow the container image setup in the Safeguard docs.

Quick check

Sources

• NIST SP 800-190, Application Container Security Guide (CSRC page)
• NIST SP 800-190 full text (PDF)
• NIST SP 800-218, Secure Software Development Framework (CSRC page)
• NIST SP 800-218 full text (PDF)
• CISA Known Exploited Vulnerabilities Catalog
• FIRST, Exploit Prediction Scoring System (EPSS)
• FIRST, CVSS v4.0
• OCI Image Specification, Descriptors and digests
• Docker Docs, Building best practices
• Docker Docs, Multi-stage builds
• Gold Open Source, package and CVE search
• Gold Open Source, Vulnerability database
• Gold Open Source, Scan your dependencies
• Gold Open Source, Developers (API and badge)
• Safeguard Docs, Gold Open Source
• Safeguard Docs, CI/CD integration: container images

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.