DevSecOps and Software Supply Chain
Container Image and Registry Security
We review the source and contents of your container images and who can write to your registry. We set up controls to allow only approved, signed images in production.
What it is
A container image includes an operating system layer and many packages with your application. If the base image source is unclear or not updated, known vulnerabilities are carried into every new release. Anyone with write access to the registry can push a different image under the same tag. Therefore, images are referenced by digest, not tag, and signatures are verified before admission to the cluster.
Scope
- Approved base image sources and update routine
- Minimal images and removal of unnecessary packages
- Image scanning and release rule for critical vulnerabilities
- Image signing and signature verification at cluster admission
- Registry read and write permissions, immutable tags
- Root user in Dockerfiles and secrets embedded in images
The need
When organizations need it
- When teams start building their own images during a move to Kubernetes.
- When images are pulled directly from public registries and their source is not checked.
- When image scans show many vulnerabilities in each release and their significance is unclear.
Method
How we work
-
Inventory
We list the images running in production, their sources and base images.
-
Review
We assess image contents, Dockerfiles and registry permissions based on CIS Docker Benchmark and NIST SP 800-190.
-
Base images
We define approved, minimal base images for your teams and an update routine.
-
Admission rule
We set the policy to admit only signed images from the approved registry into the cluster.
Outcome
What you have at the end
It is clear which images run in production, their source and contents. The policy rejects any unsigned or unapproved image in the cluster.
Frequently asked questions
Is the security of the Kubernetes cluster itself in scope?
This work covers how images are built, stored and admitted to the cluster. Permissions and isolation of workloads in the cluster are covered by our cloud and Kubernetes security services.
Is image scanning enough on its own?
No. Scanning shows known vulnerabilities but does not prove who built the image. Signing and an admission policy address this gap.
Do we have to move to minimal images?
No. Minimal images reduce the attack surface and scan noise. The transition is planned in stages based on application dependencies.
DevSecOps and Software Supply Chain
Other services in this area
Let's talk about this service.
Tell us briefly what you need. We will agree on the scope and timing together in the first meeting.
Schedule a Meeting