AWS Lambda Layer Shared Externally
Description
Identifies the modification of an AWS Lambda layer permission policy to grant another AWS account, an AWS Organization, or the public the ability to use a layer version. Lambda layers package code and dependencies that are loaded into the execution environment of any function that references them. Sharing a layer with an external account or with everyone can leak proprietary code or secrets bundled in the layer, and can serve as a supply-chain mechanism whereby downstream functions load attacker-influenced code. Layer sharing should be infrequent and deliberate, so newly granted external or public access warrants review.
Query · kuery
data_stream.dataset: "aws.cloudtrail"
and event.provider: "lambda.amazonaws.com"
and event.action: AddLayerVersionPermission*
and event.outcome: "success"
Investigation fields
Pivot points the source recommends for triage.
@timestampuser.nameuser_agent.originalsource.ipaws.cloudtrail.user_identity.arnaws.cloudtrail.user_identity.typeaws.cloudtrail.user_identity.access_key_idaws.cloudtrail.user_identity.session_context.session_issuer.arnaws.cloudtrail.request_parametersaws.cloudtrail.response_elementsevent.actionevent.outcomecloud.account.idcloud.region
Known false positives
- Organizations sometimes publish shared utility layers across their own accounts or to partners intentionally. Verify the layer, the granted principal in `aws.cloudtrail.request_parameters`, and the principal in `aws.cloudtrail.user_identity.arn` against approved sharing practices. Known shared layers and distribution accounts can be excluded after validation.
Analyst notes
Investigating AWS Lambda Layer Shared Externally
AWS Lambda layers bundle code and dependencies that are loaded into the runtime of any function referencing them. AddLayerVersionPermission modifies a layer version's permission policy to allow another AWS account, an organization, or the public (principal=*) to use it. This can expose code or secrets contained in the layer and can act as a supply-chain vector for any function that consumes the layer.
This rule detects successful AddLayerVersionPermission calls. Public grants (principal=*) are the highest concern; specific cross-account grants should be validated against approved sharing.
Possible investigation steps
- Inspect
aws.cloudtrail.request_parametersfor thelayerName, version number,action, and the grantedprincipal(a specific account id, an organization id, or*for public). - Identify the actor in
aws.cloudtrail.user_identity.arnandaws.cloudtrail.user_identity.type, and reviewsource.ipanduser_agent.originalto understand how the grant was made. - Determine whether the layer contains sensitive code or secrets and whether external sharing was intended and approved.
- Identify which functions reference the layer and whether the grant could influence their runtime.
- Correlate with other activity by the same principal, such as layer publication (
PublishLayerVersion) or function changes.
False positive analysis
- Shared utility layers distributed across an organization's accounts or to partners are a legitimate pattern. Confirm the grant is approved and exclude known distribution accounts or layers on
aws.cloudtrail.user_identity.arnor the layer name after validation.
Response and remediation
- If the sharing is unauthorized, remove the layer permission (
RemoveLayerVersionPermission) and rotate any secrets that may have been exposed in the layer. - Review which accounts accessed or copied the layer while the grant was in place and assess potential exposure.
- Rotate or restrict credentials for the principal if compromise is suspected, and constrain
lambda:AddLayerVersionPermissionto a small set of trusted roles.