The layer owner publishes a fixed layer version, and every function owner must then point to it, because a function references an exact layer version. Fixing the layer alone changes nothing for existing functions. Build a consumer list first, then roll out version by version and verify.
How layers work, per AWS
According to the AWS Lambda documentation, a layer is a .zip archive that usually holds library dependencies, a custom runtime or configuration files. Layers let you share dependencies across functions, and you can use up to five layers per function. A layer version is an immutable snapshot, each publish creates a new version number with its own ARN, and a function must name the exact version it uses.
Two details matter for security. First, immutability means an old version stays vulnerable forever, so retirement is a deliberate act. Second, layers apply to functions deployed as zip archives. Functions defined as container images package their own dependencies, so they follow your image process instead.
The risk shape
One vulnerable library in a popular layer can sit inside dozens of functions, owned by different teams, in several accounts. None of those functions list the library in their own code repository, so repository scans miss it.
A response plan
- Identify the layer version. Record the component and the layer version that contains it.
- List consumers. Find every function that references that version. If your inventory stores layer ARNs per function, this is a query.
- Publish the fix. Create a new layer version with the updated dependency and test it with one low risk consumer.
- Update consumers. Each function owner changes the reference, or a shared template does it for them.
- Retire the old version. Once no function uses it, stop others from adding it, following the provider documentation for your setup.
- Verify. Re-run the consumer query. The count for the old version should reach zero.
Questions to answer in the inventory
| Field | Why |
|---|---|
| Function name and account | Where to apply the change |
| Layer ARN and version | Whether it is affected |
| Owning team | Who to ask |
| Last deployed date | Finds stale functions |
| Runtime version | Layer compatibility |
Prevent the next scramble
Treat layers as products. Give each an owner, a changelog and a support statement. Add a component list for every layer version, so a new advisory can be matched in minutes. Avoid sharing a layer across teams without an agreed update window.
Try it yourself
Open the demo to see a dependency inventory with components listed per project. Imagine one entry per layer version in your own estate.
Click through it at your own pace, or open it full screen.
Quick check
Can I edit an existing layer version to patch it?
No. The AWS documentation describes layer versions as immutable snapshots, so you publish a new version instead.
Do container image functions use layers?
The documentation says layers apply to zip deployments. Container image functions package the runtime and dependencies in the image.
Safeguard's SBOM and dependency scanning can list components inside packaged artifacts, which helps match advisories to layers. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
