Two levers move most of a scan result
Most findings in a container scan belong to the operating system packages the base image brought with it, and most of the rest belong to a handful of application packages pinned behind their fixes. Changing those two things changes the result; triaging the findings one by one does not.
The base image
Container curation reads the layers of each image, finds the base it was built from, and compares that base with the equivalent images Docker Hardened Images, Chainguard, Red Hat and other registries publish: the same runtime, libc and distribution release, ranked by what each one removes.
The packages
Safe Harbour walks every published version of a package and clears the ones with no known vulnerability, exploit or malware report. The dependency curator applies one policy across a whole manifest; the container migration pins the packages your own layers install to versions the new base release ships.
Where it runs
A connected AWS account lists every image EKS, ECS, Lambda and ECR hold or run, so each recommendation sits beside the placement it changes and an image nobody deploys does not jump the queue.
Every claim links to something you can check
A recommendation is only as good as what stands behind it. Each alternative carries the vulnerabilities it still has, the ones it removes, where the image came from and who signed it. The comparison between what a vendor claims and what Vulnetix found in the same image is shown, not smoothed over.
- Advisories: Every vulnerability id links to its record in the Vulnetix database, with the exploit and known-exploited evidence that decides its urgency.
- The registry: Each alternative links to the registry page it came from and the digest its tag resolved to when it was read.
- Signed SBOMs and claims: The vendor signature, the signed SBOM and the vendor vulnerability claim are published through the Transparency Exchange API, with the trust anchors to verify them.
- Independent checks: Copyable commands for cosign, Grype, Trivy and the Vulnetix CLI, so the result is checked with tools you already run rather than taken on trust.
- The gap: When a vendor claim omits a vulnerability Vulnetix found in the same image, the page says so and links each omitted id.
Pick how far each package moves
Safest
The highest stable release that Safe Harbour clears.
Stable
The stable release closest to the one you run.
Latest
The highest stable release by the ecosystem's own version rules.
Rolling
What shipped most recently, closest to the one you run.
A container migration adds a fifth, parity: the version the new release ships that is nearest to the one running now. Every pick comes from versions Safe Harbour clears, worked out with the ecosystem's own version rules; a package with no clean version is shown as such and never pinned to a guess.
Rolling has a window: the newest release day, one release day earlier, or one release earlier by version order, for a team that wants a release to age before it takes it.
Where no registry knows a package, such as a Go module hosted on GitHub or an npm dependency that points at a repository, Safe Harbour reads the project's GitHub releases and checks them the same way. A package with no versions anywhere can be kept as it is or given a version by hand, and when a project has no lockfile you choose the package manager and one is generated with your picks.
The change is written, not described
- A Dockerfile: FROM pinned by digest, a dev stage when the target ships no shell, and install lines in the package manager's own pin syntax under the policy you chose.
- Your manifests: package.json, requirements.txt, go.mod, Cargo.toml, pom.xml, composer.json and Gemfile edited as text, with transitive fixes written in the override section each ecosystem uses.
- Generated lockfiles: Lockfiles are generated from the edited manifests with install scripts switched off, shown read only, and never edited by hand.
- Local setup: The registry login, a .env, compose and devcontainer overrides, a CI login step and a Renovate rule, so the new base keeps working after the first build.
- A pull request: Opened or updated through the GitHub App, with the checks that read your manifests listed first; or the files to download when the app is not installed.
Your image, not a vendor rebuild
A hardened registry rebuilds an open source image and hands you its artifact. That is one of the sources Vulnetix compares, not the only answer. The migration starts from the image you already run: it keeps your layers, swaps the base for the best equivalent across every registry we read, pins what you install, and shows the evidence for each step.
When keeping the current base is the better call, the recommendation says keep. When the base is unknown, because the image was squashed or built from a reference we cannot resolve, the page says that too, rather than guessing.
Images arrive three ways: the Vulnetix CLI records an image's packages layer by layer, the Dockerfile scanner records each FROM and install line in a repository, and a connected AWS account lists what EKS, ECS, Lambda and ECR hold or run. Manifests arrive through the GitHub App or an upload. Read more about container scanning and the dependency curator.