Set up container scanning in this order: choose trusted base images, scan at build time, check for secrets and configuration defects, rescan images stored in the registry, and only then enforce at deploy time. Each step is cheap on its own, and each one shrinks the problem the next step has to handle.
Why does the order matter?
NIST SP 800-190 groups container risk into image, registry, orchestrator, container and host risks. The image risks come first in the guide and in practice: vulnerable components, configuration defects, embedded malware, embedded clear text secrets and the use of untrusted images. Most of those are decided before a pipeline ever runs.
Starting with deploy-time blocking is the common mistake. It stops releases for problems nobody has had a chance to fix, so teams turn it off. Build up from the cheap, early steps.
What does each step look like?
1. Fix the base image rules. NIST names untrusted images as one of the most common high-risk scenarios, and notes that base layers from third parties with unknown provenance are a possible source of embedded malware. Pick a short list of approved bases, pull them from a source you trust, and pin them by digest rather than by a moving tag.
2. Scan at build time. Run the scan on the image you just built, in the same pipeline job, and fail on the severities and rules you agreed. Start by reporting only. NIST explains why this matters: an image can be free of known vulnerabilities when built and have some days or weeks later, and the fix is a new image, since containers are not patched in place.
3. Check configuration and secrets. The same guide lists configuration defects, such as running as a privileged user or shipping an SSH daemon, and clear text secrets baked into image layers. A scan should look inside every layer, not only the final filesystem view.
4. Rescan the registry. NIST calls out stale images in registries: vulnerable old versions that increase the chance of an accidental deployment. Schedule rescans of what is stored, and remove or flag images past a defined age.
5. Restrict who can push and pull. Registries are trusted as the source of approved software, so weak authentication there puts every downstream container at risk. Use authenticated, encrypted connections.
6. Add admission control last. Once the earlier steps are quiet, let the cluster refuse images that fail policy or lack a signature you expect. It is your backstop, not your first filter.
What are the honest limits?
Image scanning finds known problems in known components. It does not catch a flaw nobody has published, and it says nothing about how your application behaves at runtime. Reachability data, where a tool offers it, helps you tell which library findings your code can actually trigger, but treat it as input to a human decision.
Scanners also disagree on results because their data sources and matching rules differ. Pick one as the system of record and learn its blind spots.
What to do
- Approve a short list of base images and pin them by digest.
- Add a build-time scan in report-only mode and read the first week of results.
- Set fail rules for the severities you will fix, then turn blocking on.
- Extend the scan to secrets and image configuration.
- Schedule registry rescans and a retirement rule for old images.
- Lock down registry access and use encrypted connections.
- Add admission control and test it on one namespace first.
Quick check
Is scanning at build time enough?
No. New vulnerabilities are published after an image is built, so stored and running images need rescans too.
Should the first scan block the build?
Usually not. Start in report mode, tune the rules, then enforce the ones the team has agreed to act on.
Sources
- NIST SP 800-190, Application Container Security Guide (PDF), fetched 18 October 2026
- NIST SP 800-190 publication page, fetched 18 October 2026
Last reviewed: 18 October 2026.
