A container image layer is a set of filesystem changes, stored as a blob and identified by a digest. An image is a manifest that points to a config and an ordered list of layers. Scanners read each layer to find packages, which tells you where a finding came from.
The parts of an image
The OCI image specification defines an image manifest with a config descriptor and a layers array, where the base layer is first and later layers stack on top. Each descriptor refers to content by digest, size and media type. The same content always has the same digest, which is why digests work as identifiers.
An image index sits above this for multi-platform images, referencing one manifest per architecture and operating system.
Why layers matter to a scan
| Question | Layer answer |
|---|---|
| Where did this package come from? | Which layer added it, base or your own step |
| Can I fix it myself? | If it is in the base layers, change the base; if in yours, change the build |
| Why is the image large? | Which layer holds the bulk |
| Is a deleted file really gone? | No. A later layer can hide a file that an earlier layer still contains |
| Can two images share content? | Yes, identical layers are stored once |
The deleted file point is a classic security issue. A secret added in one step and removed in the next still exists in the earlier layer. See deleted secrets in later layers.
Reading a finding by layer
When a scan lists a vulnerable package, look at its layer. If it belongs to the base image, the fix is a newer base, and every service on that base benefits. If it belongs to a layer you wrote, the fix is in your Dockerfile or dependency file. This split tells you who owns the work and how many services are affected.
Practical habits
- Keep the base image small and current.
- Order Dockerfile steps so frequently changing layers come last.
- Install and clean up in the same step so removed files never persist in a layer.
- Use multi-stage builds so build tools stay out of the final layers.
- Scan the final image by digest and keep the layer attribution in the report.
What layers do not tell you
Layer history shows how an image was built, not whether it behaves safely. A clean layer list can still hold a flawed library. See what container scanning cannot see.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a finding and see which package it names and where in the image it sits.
Quick check
Does deleting a file in a later step remove it from the image?
No. The earlier layer still contains it and can be extracted. Avoid adding it at all.
Is the layer digest the same as the image digest?
No. Each layer and the manifest have their own digests. The image digest is the manifest digest.
Safeguard scans dependencies and SBOMs; try the free scan.
Sources
Last reviewed: 19 October 2026.
