Lambda Layers were introduced to solve a packaging problem: large dependency trees were inflating deployment package sizes, multiple functions in a project shared the same runtime libraries, and CodeDeploy was being asked to ship duplicates of the same node_modules tree to dozens of functions in the same account. Layers let you publish a versioned artifact once and attach it to many functions by ARN, which is genuinely useful, but the convenience has obscured what a layer actually is from a security perspective. A layer is code that the Lambda runtime extracts into /opt at cold start and that runs in the same execution context as your handler, which means with the same IAM role, the same VPC access, and the same access to environment variables containing secrets.
This post is about the 2026 supply chain controls for Lambda Layers. We assume you already use layers in production and you are trying to decide which of your current layer references are acceptable, what to require of new layers, and how to keep the inventory honest as the function fleet grows.
What does a Lambda Layer actually have access to?
A layer is a zip artifact extracted to /opt before the runtime imports your handler. For Node.js layers, /opt/nodejs/node_modules is automatically prepended to the require path. For Python, /opt/python is prepended to sys.path. For custom runtimes, the layer can supply the runtime itself in /opt/bootstrap. In every case, anything in the layer can register import-time hooks, monkey-patch the SDK, replace HTTP clients with instrumented variants, or read environment variables before your code runs. There is no privilege boundary between the layer and your handler.
The trust implication is that adding a layer to a function is operationally equivalent to adding a dependency to your code, but with weaker guardrails. A Lambda function reference to a layer is just an ARN and a version, with no SBOM, no signature, no provenance, and no transitive dependency view by default. Engineers who would never paste an unknown npm package into package.json will routinely add a layer ARN they found in a blog post, which produces the same end state with less scrutiny.
How do public and org-shared layers complicate the trust model?
Layers can be shared three ways: within a single account, across an organization through resource policies, and publicly to any AWS principal. Public layers are the most interesting case because they are advertised in blog posts and SAR applications as ready-to-use building blocks for observability vendors, secrets managers, and runtime instrumentation. Attaching a public layer is a trust decision identical to installing software from a vendor, but the AWS console presents it as a configuration setting rather than a software install.
Org-shared layers introduce a different problem. The team that publishes the layer is rarely the team that consumes it, and the consumer typically does not know how the layer was built, what dependencies it contains, or whether its build pipeline is hardened. We have seen incidents where a platform team published a layer with a curl-bash install step in its build, the build host was compromised, and a malicious version of the layer was published and propagated across hundreds of functions in the organization before anyone noticed. The layer ARN is the wrong granularity for trust decisions because it tells you nothing about how the artifact behind the ARN was produced.
What does a hardened layer policy look like in 2026?
The minimum bar is that every layer attached to a production function comes from a build pipeline you control or from a supplier you have explicitly approved. For internally built layers, the build should run in an isolated environment, produce a CycloneDX SBOM that lists every dependency in the layer, sign the artifact with a workload identity attested to the build event, and publish to a private layer with the resource policy scoped to specific accounts. The function configuration should reference the layer by ARN and version, never by latest, and the deploy pipeline should refuse to attach a layer whose attestation does not pass policy evaluation.
For supplier layers, you need a TPRM record for the supplier, a signed attestation that maps the published ARN to a specific git commit and build, and an inventory entry that records which functions consume the layer. The supplier should publish layer SBOMs as a matter of course, and if they do not, you should treat their layers as you would an unvendored binary blob. The 2026 norm for observability vendors and secrets brokers is to publish provenance, and customers should be asking for it.
How do you keep layer inventory honest as the fleet grows?
Functions accumulate layer references the same way Kubernetes pods accumulate sidecar containers, which is to say silently and without anyone reading the diff. The single most useful inventory query is the join of every function in every account against the layers it references, the publisher account of each layer, the version pinning state, and the last time the layer artifact was rebuilt. Surface that as a dashboard, and patterns like a single layer ARN attached to two hundred functions become visible.
The other inventory hygiene practice is deprecation: layer versions accumulate indefinitely because deleting an old version can break functions that reference it. Treat unreferenced layer versions as garbage and clean them up, but more importantly, treat referenced-but-stale layer versions as findings and require functions to upgrade. A layer version that has not been rebuilt in eighteen months is almost certainly carrying CVEs that the latest build does not have, and the function that references it is inheriting those CVEs without anyone noticing.
What runtime controls help when prevention fails?
Even with policy gates in front of deployment, you should expect that some layer somewhere will eventually carry something it should not. Runtime defenses are how you catch that. Lambda extensions, which are a special kind of layer that runs as a separate process, can be used for outbound network policy enforcement against an allowlist of expected egress destinations. CloudTrail data events on the function's IAM role catch unusual API calls. The Lambda runtime API logs catch unexpected initialization patterns.
The defense that pays the highest dividend is egress allowlisting. Most malicious Lambda Layer behavior we have seen involves a callback to an external host to exfiltrate credentials or fetch a second-stage payload. A VPC-attached function with an egress allowlist enforced by a NAT gateway policy or a network firewall denies that pattern by default, and the deny event becomes the alert. Combine that with role permission boundaries that prevent the function from rotating its own keys or modifying its own configuration, and a compromised layer has fewer paths to escalate.
How Safeguard Helps
Safeguard treats every Lambda Layer as a software component with its own SBOM, provenance attestation, and reachable-CVE profile, attached to the function inventory as a first-class relationship. Griffin AI correlates the layers in your function fleet against known supplier risk signals, TPRM scores, and the layer's own dependency graph, surfacing the cases where an org-shared or public layer is the actual blast-radius driver behind a function's risk score. Policy gates can refuse to deploy a function whose attached layers do not satisfy provenance, SBOM, and reachability requirements, and our reachability engine cuts through the noise of large layer dependency trees by flagging only the CVEs that the function's call graph actually touches. The combination gives security teams the layer-by-layer inventory and the function-by-function risk view that AWS-native tooling alone does not provide.