+91 98726 60544 hello@mitstech.co Mon–Sat · 09:00–18:30 IST

Container images: the supply chain nobody audits

Security By Mits Engineering Team 2 min read
Container images: the supply chain nobody audits

A container image built from a standard base contains an operating system, a language runtime, and every transitive dependency your package manager resolved. Your own code is a rounding error in that total. Everything else arrived on trust, and most teams have never looked at what is in there or where it came from.

The cheapest improvement is a smaller base image. A full distribution base carries package managers, shells and utilities your application never uses, and each one is a vulnerability that will appear in scans and an additional tool available to anyone who gets a foothold. Slim, alpine or distroless variants cut the surface dramatically - often from hundreds of reported vulnerabilities to a handful - without changing your application at all.

Pin what you depend on. A base image referenced by a floating tag can change under you between builds, which makes your builds non-reproducible and means a compromised upstream tag propagates silently. Reference base images by digest, and commit a lockfile for application dependencies so the resolved versions are recorded rather than recalculated. Reproducibility is what lets you answer what was actually in the build that shipped last Tuesday.

Scan in the pipeline, not on a schedule. Tools such as Trivy or Grype run in seconds and can fail a build on critical vulnerabilities in the image or its dependencies. Scanning is also the point at which teams discover the counterintuitive part: most findings are in the base image rather than in anything they wrote, which is why the base image choice matters more than any amount of care in application code.

Then there is what you accidentally include. Build secrets in intermediate layers remain in the image history even if a later layer deletes them - a credential passed as a build argument is recoverable by anyone with the image. Use multi-stage builds so the final image contains only the compiled artefact and its runtime, and never the build tooling, the source, or the credentials used to fetch private dependencies.

Two operational habits close the loop. Run as a non-root user, declared in the image, because container escapes are considerably less damaging when the process inside had no privileges to begin with. And rebuild regularly even when your code has not changed - an image built six months ago accumulates known vulnerabilities in its base without a single commit, and a weekly rebuild of unchanged services is the cheapest patching strategy available.

Need help with this? Explore our Cybersecurity & Compliance services. Learn more Back to all news

Keep reading

More on Security