[Julio-Guerra]

Throwaway prototype. Do not merge. Cross-component prototype for the RFC "CADR for AWS Lambda" (Multica JULIO-11, epic APPSEC-71674). Companion PRs: datadog-lambda-python and system-tests (linked from the Multica issue).

Problem

CADR cannot link an AAP signal on Lambda to Cloud SIEM: every CADR correlation starts from Workload Protection, which does not run on Lambda. The execution environment's AWS access key ID is the join key (CloudTrail userIdentity.accessKeyId), but no Lambda span carries it. This PR checks that the RFC design core (D1 to D8) can be built on the extension AppSec path (Go, .NET, Node.js and Python with DD_SERVERLESS_APPSEC_ENABLED).

This PR

Behind DD_APPSEC_AWS_ACCESS_KEY_ID_TAG_ENABLED (default off), every invocation the AppSec processor monitors gets aws.lambda.access_key_id on its aws.lambda span.

• appsec/mod.rs: is_aws_access_key_id_enabled() reads the flag from the environment only, so it has no datadog.yaml key (per the RFC Contracts tab). read_aws_access_key_id() reads only AWS_ACCESS_KEY_ID and validates ^(ASIA|AKIA)[A-Z0-9]{16}$ without a regex dependency.
• appsec/processor/mod.rs: the Processor reads the value lazily at the first Context, so at the first invocation and after a SnapStart restore, and caches it in a OnceCell for the environment's life.
• appsec/processor/context.rs: new TagName::AwsLambdaAccessKeyId, inserted as TagValue::Always and applied by the existing process_span.

Testing

Test 1: unit tests

Steps

1. In an AL2 toolchain image built from images/Dockerfile.bottlecap.compile: cargo fmt --all -- --check, cargo test --lib appsec, cargo clippy --workspace --all-targets --features default -- -D warnings.

Result

fmt and clippy are clean. 32 appsec tests pass, 6 of them new. They run the real WAF on a Function URL event: tag set (S1); off when unset, false or 0 (S2); malformed values (S5); read once (S6); tag next to a crs-930-120 event (S7); no canary secret or token on the span.

Test 2: end to end in system-tests

Steps

1. cargo build --release (aarch64), copy the binary and scripts/datadog_wrapper into system-tests binaries/, build python_lambda function-url.
2. ./run.sh APPSEC_LAMBDA_AWS_ACCESS_KEY_ID_EXTENSION tests/appsec/test_aws_lambda_access_key_id.py

Result

4 passed. The tag is on the payload the extension sends to the backend, the tracer-side payload has neither the tag nor tracer AppSec, and no canary appears in any payload or log. With the v100 datadog_wrapper instead, tracer AppSec stays on, both paths run, and the S8 test fails as expected. Exclusivity starts with v102 (#1466).

Findings for the RFC

• SnapStart (.NET): AWS_ACCESS_KEY_ID is empty after restore. AWS uses the container credentials endpoint, as secrets/decrypt.rs already handles. Reading the key from that endpoint means fetching the secret and the token too, which conflicts with RFC D1.
• The extension creates a security context for every identified trigger, not only HTTP ones. On SQS, for example, it would tag where the Python tracer does not. The RFC should define "monitored invocation" (D4).

🤖 Generated with Claude Code

[datadog-datadog-prod-us1-2]

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 3b4d36c | Docs | View more details | Give us feedback!}