Detect it by alerting when a Lambda function is updated to use a new layer or a layer version from an unexpected source. Review whether the layer changes runtime behaviour, adds binaries, or introduces network or credential access. Also watch for changes to functions that are otherwise unchanged, because attackers may hide payloads in a layer rather than the function code.
What to look for when a Lambda function changes layers
Layer attachment is a deployment-time trust decision, not just a packaging detail. The useful detection question is whether a function that previously behaved one way now points to a different layer version, especially one that introduces code you did not expect, changes the runtime footprint, or alters the function without a matching code commit. Treat the layer as part of the executed surface, not as passive metadata.
Because layers can carry binaries, helper libraries, and startup hooks, a malicious change often shows up as a mismatch between the function’s apparent source and its runtime behaviour. If the function code itself is unchanged but logs, outbound traffic, environment access, or process execution patterns shift after a layer update, that is a strong signal that the layer is doing the real work.
In practice, the easiest detection path is to compare CloudTrail or equivalent control-plane events for function updates against your known-good deployment record. A layer that arrives from an unexpected account, repository, or publishing pipeline deserves the same scrutiny you would give to a new dependency in production, because it can quietly become the payload delivery mechanism.
Why malicious layers are effective for hiding payloads
Lambda layers are attractive because they let an attacker alter behaviour without rewriting the main function package. That separation lets the visible application code stay stable while the layer introduces additional files, native libraries, or helper logic that is harder to spot in a quick review. This is especially important in environments where teams focus on function diffs but do not inspect the attached layer contents with the same care.
A layer can also expand what the function is able to do at runtime. If the attachment brings in command execution capability, filesystem changes, network reachability, or access to credentials and tokens already available to the function, the security impact can be much larger than the layer’s size suggests. For that reason, a layer change should be treated as a potential privilege or capability expansion, not just a code update.
Detection is stronger when you correlate attachment events with behaviour changes. Look for new egress destinations, new child processes, new loaded modules, altered error patterns, or unusual access to AWS APIs after the layer is introduced. The most important clue is often not the layer event alone, but the combination of a layer update and a newly visible runtime capability.
For teams building broader serverless detection coverage, NHIMG’s Serverless Security Guide is a useful parent reference for function execution roles, secrets, dependencies, and logging across serverless platforms.
How to operationalise detection and triage
Start by alerting on any Lambda configuration update that changes the attached layer ARN or version, then enrich that alert with the publishing source and the deployment path that approved it. In mature environments, the important question is not merely “was a layer attached?” but “was it attached through the expected pipeline and does it match the approved artifact lineage?”
Review the layer contents when the alert fires, especially for binaries, startup scripts, unusual dependencies, and anything that could reach the network or access secrets. If the function is otherwise unchanged, put extra weight on the layer as the likely source of the change. That is the pattern attackers rely on: preserve the obvious code, hide the behaviour in the attached dependency.
Enriching the alert with the function’s recent permission changes helps separate benign releases from suspicious ones. If the layer update is paired with new access paths, environment variable reads, or unusual API calls, escalate quickly and treat the function as potentially modified even if the function code package hash did not change.
Risk and Threat Considerations
Malicious layers are risky because they exploit trust in the attachment process and can persist while the main function appears unchanged. That creates a blind spot for teams that only compare function code hashes or deployment diffs and do not inspect the runtime behaviour introduced by the layer.
Failure mechanism: An attacker gets a layer attached through a compromised pipeline, permissive publishing process, or overlooked update path, then uses that layer to add hidden execution logic, data access, or outbound communication without altering the visible function code.
Impact: The function can continue to look legitimate while exfiltrating data, invoking unwanted APIs, or expanding access through credentials already available to the execution environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Unauthorized Personnel, Connections, Devices and Software | Layer swaps are unauthorized software change signals in the control plane. |
| Recommendation — Monitor Lambda configuration changes and alert on unexpected layer attachments. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Layer attachment is a controlled configuration change that needs approval and traceability. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Detection depends on reviewing update events and correlating them with behaviour anomalies. | |
| Recommendation — Require approved change control for Lambda layer updates and version swaps. Review Lambda update logs and investigate anomalous layer-related events. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Unexpected layer attachments indicate drift from secure, approved serverless configuration. |
| Recommendation — Baseline approved Lambda layers and alert on any drift from the expected configuration. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | A malicious or compromised layer can behave like risky third-party dependency supply. |
| Recommendation — Vet layer provenance before allowing it into production Lambda functions. | ||
Practitioner Guidance
What to verify: Verify the layer publisher, version lineage, and whether the attached layer matches the expected artifact for that function. If the function code is unchanged but behaviour shifted, treat the layer as the primary suspect until proven otherwise.
Decision rule: If a layer attachment cannot be traced to an approved release path, isolate the function for review before assuming the change is benign. If the layer introduces native binaries or new network behaviour, escalate the alert even when the function diff is empty.
What good looks like: A clean deployment process produces a known layer inventory, alerting on every layer change, and a quick way to compare the observed runtime behaviour with the approved build. That makes suspicious attachments visible before they become durable footholds.
Practitioner takeaway: The most reliable signal is not “a Lambda function changed”, but “an unchanged function suddenly inherited new capability through a layer”, which is exactly the pattern defenders should make loud and reviewable.