A startup with no security team can cover container scanning in one day: harden the Dockerfile, scan every image in CI, fail builds only on known exploited critical findings, and keep a short list with owners and dates. Start narrow so people trust the gate, then tighten it.
This plan assumes you build images in CI and run them in a cloud or cluster. Adjust for your setup.
What should you do before any scanner?
Fix the cheap things in the Dockerfile. OWASP's Docker Security Cheat Sheet gives numbered rules. Rule 2 says set a user, so the container runs unprivileged. Rule 3 says limit capabilities: drop all and add back only what is needed, and never use the privileged flag. Rule 8 says set the filesystem and volumes to read-only where possible. Rule 12 says keep secrets out of images and use a secrets mechanism instead. Rule 0 says keep the host and Docker up to date, because containers share the host kernel.
These changes cost an hour and shrink what any finding can do.
Where does the scanner go?
OWASP's rule 9 says integrate container scanning tools into your CI/CD pipeline and pin base image and package versions. Put one scan step after the image build, before the push. Scan the image you will deploy, not the source folder.
The Safeguard CLI is one option. Its page shows safeguard scan --dir . for a directory and says it can also scan a container image, a Git repository or an existing SBOM, with results computed on your machine. Any scanner that runs in CI and exports SARIF or JUnit works for this plan.
Start in report mode. For the first two weeks, do not fail builds. Look at what it finds.
What should fail the build?
Gate narrowly. Fail on findings that CISA's Known Exploited Vulnerabilities catalogue lists, since those are known to be exploited in the wild. For everything else, create a ticket. After a month, add a second rule such as critical severity with a fix available.
A gate nobody trusts gets bypassed. A narrow gate that always means something gets respected.
How do you keep it from becoming noise?
Pick one owner per service. Give each finding an owner and a due date. Use a simple rule: exploited findings within days, critical with a fix within two weeks, everything else in the normal upgrade cycle. NCSC's Cyber Essentials uses 14 days for critical or high risk fixes as a benchmark, and you can borrow it.
Rebuild images weekly so base image fixes arrive without work. Pin versions so rebuilds are deliberate.
Write down every suppression with a reason and an expiry date. A short list of exceptions you can read in five minutes is better than an invisible allow list.
What do customers and auditors ask?
Early customers often ask whether you scan images and how fast you fix serious issues. Save the scan output with dates, and keep your fix rule in a short document. That answers most questionnaires without extra tooling.
NIST SP 800-190, the Application Container Security Guide first published in September 2017, is the standard reference if a customer wants a document to read.
What to do
- Apply the OWASP Dockerfile rules above to your main image.
- Add one scan step in CI after build and before push, in report mode.
- Review results after two weeks and fix obvious base image issues.
- Switch on a gate that fails only on known exploited findings.
- Assign an owner and a due date per finding.
- Rebuild weekly and review your exception list monthly.
Quick check
Should the first scan fail the build?
No. Run in report mode for a couple of weeks, fix the obvious issues, then gate on a narrow rule such as known exploited vulnerabilities.
Is scanning enough without hardening?
No. Scanning finds known flaws. Running as non-root, dropping capabilities and read-only filesystems reduce the damage from what you miss.
Sources
- OWASP: Docker Security Cheat Sheet
- CISA: Known Exploited Vulnerabilities Catalog
- Safeguard CLI
- NIST: SP 800-190, Application Container Security Guide
- NCSC: Cyber Essentials Requirements for IT infrastructure v3.3
Last reviewed: 18 October 2026.
