Comparing changes

## Summary - Add integration tests for Lambda enhanced duration metrics (runtime_duration, billed_duration, duration, post_runtime_duration, init_duration) - Plan on following up with (1) more metrics (2) metrics on other runtimes like LMI. - No changes to Extension code. ## Test plan - [x] New integ tests pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.5 <[email protected]>

…1122) ## Summary - Update `aws-lc-sys` 0.37.1 → 0.39.0 (RUSTSEC-2026-0044, -0045, -0046, -0047, -0048) - Update `aws-lc-fips-sys` 0.13.11 → 0.13.13 (RUSTSEC-2026-0042, -0043) - Update `aws-lc-rs` 1.15.4 → 1.16.2 (required to unlock `aws-lc-sys` 0.39.0) - Update `rustls-webpki` 0.103.9 → 0.103.10 (RUSTSEC-2026-0049) - Update `tar` 0.4.44 → 0.4.45 (RUSTSEC-2026-0067, -0068) Only `Cargo.lock` is modified — all updates are to transitive dependencies. ## Test plan - [ ] Cargo audit CI check passes 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Sonnet 4.6 <[email protected]>

## Overview When the status code from the proxy flusher request is not 200 or 202, right now we log: ``` error!( "PROXY_FLUSHER | Request failed with status {status} to {url}: {body:?}" ); ``` and do not retry. This PR: 1. Adds retries for this type of failure, with 3 attempts in total 2. Changes the log to INFO level if it's not the final attempt. Keep ERROR level if it failed for the final attempt. ## Testing N/A

As part of #incident-51602-public, we are temporarily disabling all automated dependency updaters to reduce exposure to potential zero-day vulnerabilities in recent releases. This PR removes the Dependabot/Renovate configuration from this repository until further notice. ⚠️ Do not merge if your repository is managed by ADMS. Please refer to #incident-51602-public for updates and to confirm when it is safe to re-enable.

## Summary - Add gRPC support for OTLP trace ingestion on port 4317, complementing the existing HTTP endpoint on port 4318 - Implement `TraceService` trait using tonic for gRPC server - Refactor `OtlpProcessor` to accept `ExportTraceServiceRequest` directly (avoids re-encoding for gRPC) - Wire up existing config: `DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_GRPC_ENDPOINT` and `DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_GRPC_MAX_RECV_MSG_SIZE_MIB` ## Motivation Users were configuring gRPC OTLP endpoints (`DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_GRPC_ENDPOINT`) but the feature was not implemented, resulting in silent failures. This PR enables gRPC support. This was for an old ticket, but we should go ahead and add this, especially since OTLP is getting more popular. ## Changes | File | Change | |------|--------| | `bottlecap/Cargo.toml` | Add tonic with transport/server features | | `bottlecap/src/otlp/grpc_agent.rs` | NEW - gRPC server implementing TraceService | | `bottlecap/src/otlp/processor.rs` | Refactor to accept ExportTraceServiceRequest directly | | `bottlecap/src/otlp/mod.rs` | Update enablement logic for HTTP/gRPC | | `bottlecap/src/bin/bottlecap/main.rs` | Start both HTTP and gRPC servers | ## Binary Size Impact Measured from CI layer size checks (arm64): | Metric | Main | PR | Difference | |--------|------|-----|------------| | Zipped | 5,074 KB | 5,164 KB | **+90 KB** | | Unzipped | 11,183 KB | 11,376 KB | **+193 KB** | This is a ~1.7% increase, well under historical concerns (OTLP was removed from Go agent for adding ~1.15MB). ## Test plan - [x] New integration tests for gRPC protocol (4 tests) - [x] All existing OTLP tests continue to pass - [x] `cargo fmt`, `cargo clippy`, `cargo test` pass - [x] All CI checks passed (47 checks including integration suites) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.5 <[email protected]>

Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.69.3 to 2.69.9. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's releases</a>.</em></p> <blockquote> <h2>2.69.9</h2> <ul> <li> <p>Update <code>uv@latest</code> to 0.11.1.</p> </li> <li> <p>Update <code>osv-scanner@latest</code> to 2.3.5.</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.3.14.</p> </li> </ul> <h2>2.69.8</h2> <ul> <li> <p>Update <code>just@latest</code> to 1.48.0.</p> </li> <li> <p>Update <code>uv@latest</code> to 0.11.0.</p> </li> <li> <p>Update <code>rclone@latest</code> to 1.73.3.</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.3.13.</p> </li> </ul> <h2>2.69.7</h2> <ul> <li> <p>Update <code>prek@latest</code> to 0.3.8.</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.3.12.</p> </li> <li> <p>Update <code>cargo-valgrind@latest</code> to 2.4.1.</p> </li> </ul> <h2>2.69.6</h2> <ul> <li> <p>Support signature verification for <code>mise</code> and <code>syft</code>. (<a href="https://redirect.github.com/taiki-e/install-action/pull/1611">#1611</a>)</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.3.10.</p> </li> <li> <p>Update <code>knope@latest</code> to 0.22.4.</p> </li> <li> <p>Update <code>cargo-binstall@latest</code> to 1.17.8.</p> </li> <li> <p>Update <code>tombi@latest</code> to 0.9.9.</p> </li> </ul> <h2>2.69.5</h2> <ul> <li>Update <code>cargo-nextest@latest</code> to 0.9.132.</li> </ul> <h2>2.69.4</h2> <ul> <li> <p>Support artifact attestations verification for <code>biome</code>, <code>cargo-cyclonedx</code>, <code>cargo-hack</code>, <code>cargo-llvm-cov</code>, <code>cargo-minimal-versions</code>, <code>cargo-no-dev-deps</code>, <code>martin</code>, <code>parse-changelog</code>, <code>parse-dockerfile</code>, <code>prek</code>, <code>uv</code>, <code>wasmtime</code>, <code>zizmor</code>, and <code>zola</code>. (<a href="https://redirect.github.com/taiki-e/install-action/pull/1606">#1606</a>)</p> </li> <li> <p>Update <code>biome@latest</code> to 2.4.8.</p> </li> <li> <p>Update <code>tombi@latest</code> to 0.9.8.</p> </li> <li> <p>Update <code>parse-dockerfile@latest</code> to 0.1.5.</p> </li> <li> <p>Update <code>parse-changelog@latest</code> to 0.6.16.</p> </li> <li> <p>Update <code>cargo-llvm-cov@latest</code> to 0.8.5.</p> </li> </ul>  </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's changelog</a>.</em></p> <blockquote> <h1>Changelog</h1> <p>All notable changes to this project will be documented in this file.</p> <p>This project adheres to <a href="https://semver.org">Semantic Versioning</a>.</p>  <h2>[Unreleased]</h2> <h2>[2.69.9] - 2026-03-25</h2> <ul> <li> <p>Update <code>uv@latest</code> to 0.11.1.</p> </li> <li> <p>Update <code>osv-scanner@latest</code> to 2.3.5.</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.3.14.</p> </li> </ul> <h2>[2.69.8] - 2026-03-24</h2> <ul> <li> <p>Update <code>just@latest</code> to 1.48.0.</p> </li> <li> <p>Update <code>uv@latest</code> to 0.11.0.</p> </li> <li> <p>Update <code>rclone@latest</code> to 1.73.3.</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.3.13.</p> </li> </ul> <h2>[2.69.7] - 2026-03-23</h2> <ul> <li> <p>Update <code>prek@latest</code> to 0.3.8.</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.3.12.</p> </li> <li> <p>Update <code>cargo-valgrind@latest</code> to 2.4.1.</p> </li> </ul> <h2>[2.69.6] - 2026-03-21</h2> <ul> <li> <p>Support signature verification for <code>mise</code> and <code>syft</code>. (<a href="https://redirect.github.com/taiki-e/install-action/pull/1611">#1611</a>)</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.3.10.</p> </li> <li> <p>Update <code>knope@latest</code> to 0.22.4.</p> </li> <li> <p>Update <code>cargo-binstall@latest</code> to 1.17.8.</p> </li> <li> <p>Update <code>tombi@latest</code> to 0.9.9.</p> </li> </ul>  </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/taiki-e/install-action/commit/328a871ad8f62ecac78390391f463ccabc974b72"><code>328a871</code></a> Release 2.69.9</li> <li><a href="https://github.com/taiki-e/install-action/commit/b8df13537ac44c27b4f2b0780e8ebf612a596657"><code>b8df135</code></a> Update <code>uv@latest</code> to 0.11.1</li> <li><a href="https://github.com/taiki-e/install-action/commit/09ab1d9849f464fac4d4454a5d4746ef2e5e987a"><code>09ab1d9</code></a> Update <code>osv-scanner@latest</code> to 2.3.5</li> <li><a href="https://github.com/taiki-e/install-action/commit/4168e018ba765ebd2c235a1a800127da53e8bb4e"><code>4168e01</code></a> Update <code>mise@latest</code> to 2026.3.14</li> <li><a href="https://github.com/taiki-e/install-action/commit/7bc99eee1f1b8902a125006cf790a1f4c8461e63"><code>7bc99ee</code></a> Release 2.69.8</li> <li><a href="https://github.com/taiki-e/install-action/commit/b3b4c93c56f15a2d0eb66c1cd1d94d982fdd3d5b"><code>b3b4c93</code></a> Fix error message grammar (<a href="https://redirect.github.com/taiki-e/install-action/issues/1616">#1616</a>)</li> <li><a href="https://github.com/taiki-e/install-action/commit/1558ceeaaeb96b1a5a99296705851d3a5484b2fe"><code>1558cee</code></a> Update <code>just@latest</code> to 1.48.0</li> <li><a href="https://github.com/taiki-e/install-action/commit/26d156ba84bb2fc548172729dbf937f31e44a99e"><code>26d156b</code></a> Update <code>uv@latest</code> to 0.11.0</li> <li><a href="https://github.com/taiki-e/install-action/commit/f2b7c0747d53fcf8c8139b89da4deae201f0309d"><code>f2b7c07</code></a> Update <code>rclone@latest</code> to 1.73.3</li> <li><a href="https://github.com/taiki-e/install-action/commit/cc168bc1a8ce5b410d75df76a03f85a8d4dec5fd"><code>cc168bc</code></a> Update <code>mise@latest</code> to 2026.3.13</li> <li>Additional commits viewable in <a href="https://github.com/taiki-e/install-action/compare/c12d62a803cbdfe2e7263af15f5a9548065cb4f2...328a871ad8f62ecac78390391f463ccabc974b72">compare view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=taiki-e/install-action&package-manager=github_actions&previous-version=2.69.3&new-version=2.69.9)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

https://datadoghq.atlassian.net/browse/SLES-2739 In Kafka's wire protocol (KIP-82), header values are always byte[]. Every Kafka client library enforces this: | Tracer | Injection code | Mechanism | | ----------- | ----------- | ----------- | | dd-trace-java | headers.add(key, value.getBytes(UTF_8)) | String.getBytes() → byte[] | | dd-trace-go | Value: []byte(val) | Go type conversion → []byte | | dd-trace-dotnet | _headers.Add(name, Encoding.UTF8.GetBytes(value)) | UTF8.GetBytes() → byte[] | All three tracers accept string trace context values from the propagation layer, convert to UTF-8 bytes at the carrier adapter boundary, and hand byte[] to the Kafka client. This isn't a quirk of Java's getBytes() — it's the only way Kafka headers work. ### What MSK Lambda does When MSK triggers a Lambda, AWS serializes the Kafka record to JSON. Since header values are byte[] on the wire, AWS encodes them as decimal byte values. However, the exact JSON shape depends on the Lambda runtime: - Array format (observed in the existing msk_event.json testing payloads, i didn't change the support for this to be safe): byte values as a JSON array of integers "headers": [{"x-datadog-trace-id": [51, 54, 57, ...]}] - Object format (observed with the Java Lambda runtime): both the records list and the per-header byte values are JSON objects with numeric string keys, and byte values are decimal strings "records": { "topic-0": { "0": { "headers": { "0": {"someOtherHeader": ["70", "114", ...]}, "2": {"x-datadog-trace-id": {"0":"52","1":"54",...}}, "4": {"x-datadog-sampling-priority": ["49"]} } } } } - Note that Datadog headers can appear at any index — non-instrumentation headers may precede them. ### What's the difference between the [msk_event.json](https://github.com/DataDog/datadog-lambda-extension/blob/main/bottlecap/tests/payloads/msk_event.json) and the newly added `msk_event_with_headers.json` here? - msk_event.json represents a standard MSK trigger where the producer didn't attach any Kafka headers — i.e. no Datadog tracer was running on the producer side (or it's a non-instrumented producer like a raw Kafka client, a Kinesis Firehose delivery stream, or a schema-registry message). In those cases Lambda still delivers the event but with "headers": []. It's also the format you get when testing MSK triggers manually in the AWS console, which doesn't inject headers. ( source: Claude Code) - msk_event_with_headers.json reflects the real-world object format produced by the Java Lambda runtime, with a producer instrumented with a Datadog tracer injecting trace context as Kafka headers. It includes non-Datadog headers at lower indices to verify that the carrier extraction correctly finds Datadog headers regardless of their position. (source: I did a real world example and below is the evidence of testing) <img width="1753" height="442" alt="Screenshot 2026-03-12 at 11 14 33 PM" src="https://github.com/user-attachments/assets/f354dc54-77aa-4dcd-9e84-df4dc36102ca" /> --------- Co-authored-by: Claude Sonnet 4.6 <[email protected]> Co-authored-by: Copilot Autofix powered by AI <[email protected]>

#1118) ## Background traces/stats that go through Lambda extension can generate stats in three ways: 1. tracer generates stats and sends them to extension at `/v0.6/stats`. Only works if the env var `DD_TRACE_STATS_COMPUTATION_ENABLED` is `true`. 2. extension generates stats from traces. It's off by default, and works only if env var `DD_COMPUTE_TRACE_STATS_ON_EXTENSION` is true. 3. Datadog backend generates stats from traces. Works only if the trace tag `_dd.compute_stats` is `1`. A separate thing: the Go tracer sends a dummy `aws.lambda` span to the extension, just to send metadata. The extension extracts metadata from this span received, and sets it on the real `aws.lambda` span generated on the extension side. The latter is what's finally sent to the trace intake. ## Summary If a trace has the header `Datadog-Client-Computed-Stats` with a truthy value (which means 1 is on), then turn off 2 and 3 to avoid duplicate counts, i.e. 1. make extension not generate stats 2. set trace tag `_dd.compute_stats` to 0 As a special case, if the dummy `aws.lambda` span sent by the Go tracer has a `Datadog-Client-Computed-Stats` header with truthy value, then extension propagates this value to the `aws.lambda` span generated by the extension. The `_dd.compute_stats` tag is determined by the combination of `compute_trace_stats_on_extension` and `client_computed_stats`: | Input: `compute_trace_stats_on_extension` | Input: `client_computed_stats` | Expected: `_dd.compute_stats` | Expected: Extension generates stats? | |-------------------------------------------|--------------------------------|-------------------------------|--------------------------------------| | `false` | `false` | `"1"` | No | | `false` | `true` | `"0"` | No | | `true` | `false` | `"0"` | Yes | | `true` | `true` | `"0"` | No | ## Details - `_dd.compute_stats` is now always set in `process_traces()` (centralized from `tags_from_env()` in `tags.rs`), with the value determined by both `compute_trace_stats_on_extension` and `client_computed_stats` as shown in the table above - When `client_computed_stats` is true or `compute_trace_stats_on_extension` is true, the extension skips stats generation in `send_processed_traces()` to avoid double-counting - `COMPUTE_STATS_KEY` is `pub(crate)` in `tags.rs` so it can be referenced from `trace_processor` - Propagates `client_computed_stats` to the extension-generated `aws.lambda` invocation span: when the Go tracer sends its placeholder span (`dd-tracer-serverless-span`) with `Datadog-Client-Computed-Stats: t`, that flag is stored in the invocation `Context` and passed through to `send_spans`, so the extension also skips stats generation for the `aws.lambda` span it creates ## Test plan ### Automated tests Passed the new unit tests ### Manual tests #### Steps 1. Deploy a Lambda function that uses `github.com/DataDog/dd-trace-go/v2 v2.6.0` 2. Set env var: 1. `DD_TRACE_STATS_COMPUTATION_ENABLED`: `true`, which turns on 1 2. `DD_COMPUTE_TRACE_STATS_ON_EXTENSION`: `true`, which tries to turn on 2 #### Result Before: 2 hits (duplicate): 1. one with `resource_name=dd-tracer-serverless-span`, generated by Go tracer 1. one with `resource_name=yiming2-xxx` <img width="699" height="286" alt="image" src="https://github.com/user-attachments/assets/6545cf12-c90b-4ed1-832e-1dab7b6c4d7c" /> After: 1 hit. Only the one with `resource_name=dd-tracer-serverless-span` <img width="696" height="283" alt="image" src="https://github.com/user-attachments/assets/d2e49c3a-473c-4043-a952-9a555eada0e7" /> 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Sonnet 4.6 <[email protected]>

## Overview Migrate trace context propagation from a local implementation to the datadog-opentelemetry crate in dd-trace-rs. This removes ~750 lines of propagation logic (Datadog headers, W3C TraceContext) that we were maintaining locally in favor of the shared upstream implementation. Key changes: - Add datadog-opentelemetry as a dependency - Delete local propagation modules: traces/context.rs, traces/propagation/error.rs, traces/propagation/text_map_propagator.rs - Keep a thin DatadogCompositePropagator wrapper that adds ot-baggage-* header extraction, which is not yet supported upstream - Update all consumers to import SpanContext, Sampling, TracePropagationStyle, and header constants directly from datadog-opentelemetry - Adapt to upstream types: u128 trace IDs (cast to u64 for Datadog protocol), Sampling struct, SamplingPriority newtype # Motivation Not have to own this piece as its tracer logic and [SVLS-7466](https://datadoghq.atlassian.net/browse/SVLS-7466) ## Testing - All 476 existing tests pass - Propagation tests updated to use Datadog/TraceContext styles (upstream does not expose B3/B3Multi variants) - Config parsing tests updated to reflect valid upstream style names - [Trace Propagation e2e tests pass](https://gitlab.ddbuild.io/DataDog/serverless-e2e-tests/-/pipelines/101405643) Co-authored-by: jordan.gonzalez <[email protected]>

## Overview Consolidates the OTLP agent code by merging grpc_agent.rs into agent.rs, eliminating ~280 lines of duplicated code. A single Agent struct now owns a shared TracePipeline and starts HTTP, gRPC, or both servers based on config. ## Changes - Introduced TracePipeline struct holding shared state (config, processor, trace channels, stats generator) with a process_and_send_traces method used by both HTTP and gRPC handlers - TraceService (gRPC) is implemented directly on TracePipeline, removing the redundant OtlpGrpcService struct - Agent now holds Option<u16> for http_port/grpc_port, spawning whichever protocols are configured - Collapsed should_enable_otlp_http + should_enable_otlp_grpc into a single should_enable_otlp_agent - Deleted grpc_agent.rs - Simplified start_otlp_agent in main.rs: one Agent, one spawn ## Bug fixes - parse_port scheme handling — HTTP agent's split(':').nth(1) broke on endpoints with schemes like http://localhost:4318. Replaced with the gRPC version that strips http:///https:// prefixes and uses rsplit(':') for IPv6 support - Empty trace check — HTTP handler checked size_of_val(&traces) == 0, which always evaluates to false (returns the 24-byte stack size of the Vec struct). Replaced with traces.iter().all(Vec::is_empty) in the shared pipeline ## Tests Merged and deduplicated parse_port tests (gained scheme-handling coverage), consolidated enablement tests into should_enable_otlp_agent. All 28 OTLP tests pass, zero clippy warnings.

## Overview We'll be using this to check serverless-init against the latest main datadog agent nightly.

…gration test (#1136) https://datadoghq.atlassian.net/browse/SVLS-8767 ## Summary - `_dd.compute_stats` was moved from general log tags to trace-only payloads in commit `55659d93` - The `test_logs` integration test mock still required `_dd.compute_stats:1` in the log body - The mock never matched → httpmock returned non-2xx → `Flusher::send()` retried infinitely → test hung forever ## Test plan - [ ] `cargo test --test logs_integration_test test_logs` passes and completes in < 1s 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Sonnet 4.6 <[email protected]>

…1133) ## Summary - Adds `.github/copilot-instructions.md` to guide GitHub Copilot auto-review toward security-relevant patterns on every PR - Instructs Copilot to flag PII in log statements (HTTP headers/bodies, user-identifiable fields, structs containing PII) - Instructs Copilot to flag `SendData` values and variables derived from them (e.g. `traces_with_tags`), since these embed the Datadog API key via `.with_api_key(...).build()` - Instructs Copilot to flag new `unsafe` Rust blocks with missing invariant documentation - Instructs Copilot to flag silently swallowed errors in external-input/network code paths ## Context Jira: https://datadoghq.atlassian.net/browse/SVLS-8660 This is the first deliverable of the CI security scanning strategy (Approach C — phased). Copilot auto-review is confirmed enabled for this repo, making this a zero-overhead advisory layer at PR open/update time. Full strategy documented in `.github/docs/ci-security-scanning-strategy.md`. ## Test plan - [ ] Open a PR that includes a log statement referencing an HTTP header or user field — confirm Copilot flags it in review comments - [ ] Open a PR with no suspicious log statements — confirm Copilot review passes cleanly 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Sonnet 4.6 <[email protected]>

## Summary - Sandbox layers were published without any resource-based permissions, blocking the self-monitoring account (`093468662994`) from accessing dev layer versions during CDK deployments. - When `ADD_LAYER_VERSION_PERMISSIONS=0` (sandbox), the publish script now grants `lambda:GetLayerVersion` to the testing account instead of leaving the layer inaccessible. ## Test plan - [ ] Trigger a sandbox layer publish and verify the layer version has a resource-based policy for `093468662994` - [ ] Deploy `lmi-dev-agent` stack in self-monitoring repo using `ENVIRONMENT=dev` (pulls from `layers-dev.json` / sandbox account `425362996713`)

## Summary - Adds \`gitleaks\` secrets scanning workflow (\`.github/workflows/secrets-scan.yml\`) triggered on every PR and push to \`main\` - Pins \`gitleaks-action\` to commit SHA (v2.3.9) consistent with repo convention - Adds \`.gitleaks.toml\` with documented allowlist structure for paths, regexes, and historical commits — includes maintenance guidance for future contributors - Addressed Copilot review feedback: add \`permissions: contents: read\`, enable \`--redact\` to prevent secrets appearing in CI logs, fix allowlist key reference in comments ## Why Secrets accidentally committed to a public repo (API keys, tokens, credentials) are the highest-severity risk for a public repository. Neither \`cargo audit\` nor Copilot catch this category. \`gitleaks\` uses pattern matching to block merges before a credential lands in \`main\`. ## Test plan - [ ] Verify \`Secrets Scan\` job passes on this PR (no secrets in changed files) - [ ] After merging: add \`Secrets Scan\` as a required status check under \`Repository Settings → Branches → main → Branch protection rules\` - [ ] Optional smoke test: add a fake credential (e.g., \`AKIAIOSFODNN7EXAMPLE\`) to a comment on a test branch, confirm the job blocks it, then remove it ## Related - JIRA: https://datadoghq.atlassian.net/browse/SVLS-8660 - Part of Phase 1 CI security scanning — see \`.github/docs/ci-security-scanning-strategy.md\` - Companion PR: #1133 (Copilot instructions for PII/security review) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Sonnet 4.6 <[email protected]>

## Overview - In the nightly builds of serverless-init, set the agent version to be the most recently released version of datadog-agent - In the release build of serverless-init, if `AGENT_VERSION` is not set, use the most recently released version from the Datadog agent branch given ## Testing Ran the nightly workflow manually off this branch and made sure the logs print the correct agent version https://github.com/DataDog/datadog-lambda-extension/actions/runs/23804573812 https://github.com/DataDog/datadog-lambda-extension/actions/runs/23804573812/job/69374220028#:~:text=AGENT_VERSION%3A%207.77.1 ``` AGENT_VERSION: 7.77.1 ```

## Summary - Migrate `get_secrets.sh` from `aws ssm get-parameter` to `vault kv get`, matching the pattern used by `datadog-lambda-js` - Remove `DATADOG_API_SECRET_ARN` from CI secrets — the ARN is a public resource identifier, not sensitive data - Hardcode the Secrets Manager ARN directly in `integration-tests/lib/util.ts` ## Test plan - [ ] Verify CI pipeline can fetch secrets from Vault KV at `kv/k8s/gitlab-runner/datadog-lambda-extension/secrets` - [ ] Verify integration tests pass with the hardcoded secret ARN - [ ] Confirm `DD_API_KEY`, `DD_APP_KEY`, and external ID are correctly resolved

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Comparing changes

Open a pull request

Commits on Mar 23, 2026

Commits on Mar 24, 2026

Commits on Mar 25, 2026

Commits on Mar 26, 2026

Commits on Mar 27, 2026

Commits on Mar 30, 2026

Commits on Mar 31, 2026

Commits on Apr 1, 2026

This comparison is taking too long to generate.

Uh oh!