Yes. A Lambda layer is a zip archive that usually holds library dependencies, so the code a function runs includes it. Record each layer as a component with its exact layer version ARN, and list the function's own dependencies separately. Layer versions are immutable snapshots, which makes the ARN a precise identifier.
What the AWS documentation says
According to the AWS Lambda developer guide, a layer is a .zip file archive containing supplementary code or data, usually library dependencies, a custom runtime or configuration files. When you add a layer to a function, Lambda extracts the contents into the /opt directory of the execution environment. You can include up to five layers per function, and layers work solely with functions deployed as a .zip file archive.
For functions defined as container images, you package the runtime and all dependencies into the image when you create it. For Go and Rust functions, AWS recommends against layers, because those functions are delivered as executables that already include compiled code and dependencies.
The guide also explains versions. A layer version is an immutable snapshot. Creating a layer produces version 1, and each publish increments the number. Every layer version has a unique ARN, and when you add a layer to a function you must specify the exact layer version.
Why this matters for an SBOM
If you generate an SBOM from the function's source repository, it covers the packages in the deployment zip. The layers are attached outside that zip, possibly built by another team, possibly shared across many functions. A file that ignores layers describes solely part of what runs.
| What runs | Where it comes from | Where an SBOM tool looks |
|---|---|---|
| Your function code | Your repository | Source or lockfile |
| Dependencies in the deployment zip | Your build | Source or lockfile |
| Dependencies in a layer | A layer version | Not in your repository unless you also own the layer |
| The runtime | The service or a custom runtime layer | Not in your repository |
A worked example
Imagine a function called invoice-render. Its zip holds 6 dependencies. It attaches two layers: a shared PDF library layer owned by a platform team, and a monitoring layer. All names and numbers here are invented.
- List the function's configuration to see the attached layer version ARNs.
- For each ARN, find the owner and the source of the layer. The platform team keeps a repository and a build for the PDF layer.
- Obtain the SBOM for that layer from the owning team, keyed by version number.
- In the function's SBOM, add each layer as a component whose version is the layer version and whose identifier is the ARN, with a link to the layer's own SBOM.
- Store the function SBOM with the deployment record.
When a vulnerability appears in the PDF library, you search layer SBOMs by version, then find every function attached to that version. Because versions are immutable, the answer is precise: a function pointing at version 7 is affected, and a function pointing at version 9, which fixed it, is not.
Updating layers
Since a function must name an exact layer version, publishing a fixed layer version does not change existing functions. Each function has to be updated to the new version. That is good for reproducibility and a trap for patching: an inventory that tracks layer versions per function is how you know what remains to roll out.
Cases that differ
Container image functions have no layers in this sense. Generate the SBOM from the image, including the base image packages.
Go and Rust functions compile dependencies into the executable. Generate the SBOM from the lockfile and, ideally, the built binary.
Custom runtimes delivered as layers belong in the SBOM too, since they decide which interpreter version executes your code.
Checklist
- For every function, capture the attached layer ARNs at deploy time.
- Require each layer to publish an SBOM for each version.
- Link function SBOMs to layer SBOMs by ARN.
- Track which functions use which layer version.
- After a layer update, list functions still on the old version.
- Review the count of layers per function, remembering the limit of five.
Ownership
Decide who owns a shared layer's SBOM and its patching. Shared layers are convenient, and they also create a situation where nobody feels responsible. Put an owner in the layer's description and in your inventory. Safeguard can scan SBOMs and dependencies, and its asset discovery and compliance evidence features help keep the inventory connected. The free scan at gold.safeguard.sh/scan can check a layer's dependency list.
What to ask the team that owns a layer
Ask five questions before you trust a shared layer. Where is the source and who builds it? Is there an SBOM for every published version? How are vulnerabilities in it tracked and who is told? What is the plan for retiring old versions, given that functions must name an exact version? And who approves adding a new dependency to the layer? The answers go into your inventory, next to the ARN.
What a good record looks like
For each function, a record with the function name, the deployment date, the layer ARNs with their version numbers, the link to each layer's SBOM and the link to the function's own SBOM. For each layer, a record with an owner, a source repository, the list of functions attached and the date of the last review. Even a spreadsheet works at first. The point is that a vulnerability search can walk from a package to a layer version to the functions that use it.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how components are listed with exact versions, the same way a layer version should be.
Quick check
How many layers can one function have?
Up to five layers per function, per the AWS Lambda developer guide.
Do container image functions use layers?
Layers are for functions deployed as a .zip archive. For container images you package the runtime and dependencies in the image.
Can a layer version change after it is published?
No. A layer version is an immutable snapshot. Publishing an update creates a new version number.
Sources
Last reviewed: 19 October 2026.
