feat(ci): govulncheck - add PR checks, SARIF Code Scanning, and automated remediation

[kakkoyun]

What does this PR do?

Migrates vulnerability scanning from Dependabot Security Alerts to `govulncheck`-based scanning. Three changes:

1. `govulncheck.yml` (updated): adds a `pull_request` trigger so govulncheck now gates PRs; adds a SARIF upload job that feeds into GitHub Code Scanning (replaces Dependabot alerts in the Security tab); always installs `govulncheck@latest`; adds a concurrency group to cancel stale runs; pins all actions to latest SHA.

2. `govulncheck-fix.yml` (new): weekly remediation workflow (Mondays 6 AM UTC, also `workflow_dispatch`) that scans all modules, identifies reachable vulnerabilities with available fixes, updates the affected `go.mod` files, and opens a PR automatically.

3. `govulncheck-fix.sh` (new): remediation script that parses `govulncheck -json` streaming output, extracts `(module, fixedVersion)` pairs from `finding.trace[-1]`, runs `go get module@version` across all affected `go.mod` files (core + all 65+ contrib modules), and runs `go mod tidy`.

Motivation

Dependabot Security Alerts flag every CVE in transitive dependencies regardless of whether the vulnerable code is actually reachable — the push that triggered this PR showed 32 alerts. `govulncheck` uses Go call graph analysis to only report vulnerabilities in code paths that are actually called, eliminating false positives.

After this merges, Dependabot Security Alerts for Go can be disabled in repo settings (Settings → Code security → Dependabot alerts). The `dependabot.yml` config is kept as-is since it only manages GitHub Actions version updates, which is still useful.

How SARIF + GitHub Code Scanning works

The `govulncheck-analysis` job runs `govulncheck -format sarif` and uploads the result via `github/codeql-action/upload-sarif`. Here is what happens end-to-end:

1. SARIF file generated: `govulncheck -format sarif` emits a structured JSON file (Static Analysis Results Interchange Format) describing each reachable vulnerability — including file path, line number, severity, CVE reference, and the full call chain that reaches the vulnerable symbol. Critically, `-format sarif` exits 0 even when vulnerabilities are found, so the upload step always runs regardless of findings.

2. Uploaded to GitHub Code Scanning: The SARIF is posted to the GitHub Code Scanning API under the `govulncheck` category. GitHub parses it and creates persistent alerts in Security → Code scanning alerts. Each alert includes the call stack showing exactly how the vulnerable code is reached from this module.

3. De-duplication across runs: If the same vulnerability appears in multiple scans, GitHub tracks it as a single alert (not a new one each time). When a dependency is updated and the vulnerability disappears from the SARIF, GitHub automatically closes the alert.

4. PR annotations: When a PR introduces a new reachable vulnerability, GitHub adds an inline annotation on the diff pointing to the call site.

5. Two-job design — soft gate + hard gate:

   • `govulncheck-analysis`: non-blocking, uploads SARIF for Code Scanning visibility. Always succeeds so the upload always runs.
   • `govulncheck-tests`: blocking PR check, runs `govulncheck` in text mode (exits non-zero on any reachable finding). This is the gate that fails the PR.

   Why not use `golang/govulncheck-action`? The official action is blocked by the DataDog enterprise action allowlist (it internally uses `actions/checkout@v4` and `actions/setup-go@v5` which are not in the allowlist pattern). The `govulncheck -format sarif` flag is available natively in `govulncheck@latest`, so we install it directly via `go install` instead.

Reviewer's Checklist

• Changed code has unit tests for its functionality at or near 100% coverage.
• System-Tests covering this feature have been added and enabled with the va.b.c-dev version tag.
• There is a benchmark for any new code, or changes to existing code.
• If this interacts with the agent in a new way, a system test has been added.
• New code is free of linting errors. You can check this by running `make lint` locally.
• New code doesn't break existing tests. You can check this by running `make test` locally.
• Add an appropriate team label so this PR gets put in the right place for the release notes.
• All generated files are up to date. You can check this by running `make generate` locally.
• Non-trivial go.mod changes, e.g. adding new modules, are reviewed by @DataDog/dd-trace-go-guild. Make sure all nested modules are up to date by running `make fix-modules` locally.

References

• Filippo Valsorda: Turn Dependabot Off — rationale for replacing Dependabot with govulncheck
• golang/govulncheck-action — official Go team action with SARIF support
• Setting up govulncheck with GitHub Code Scanning — detailed integration walkthrough
• govulncheck JSON output format — streaming JSON format used by the remediation script
• CodeQL Action v4 — SARIF upload action (v3 deprecated Dec 2026)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 60.67%. Comparing base (b22fbe0) to head (54c1038).

Additional details and impacted files

see 437 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[datadog-datadog-prod-us1-2]

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 60.03% (+3.89%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 54c1038 | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback!}

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-03-27 11:33:43

Comparing candidate commit 54c1038 in PR branch kakkoyun/govulncheck with baseline commit b22fbe0 in branch main.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 216 metrics, 8 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

• 🟩 = significantly better candidate vs. baseline
• 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

[darccio]

I agree with the spirit of Filippo's post, and I like this approach, but a heads-up: IMO we'll get more support tickets and escalations because we aren't going to bump dependencies with a CVE unless the impacted code is used (directly or not) by ours.

[darccio]

@codex review

[kakkoyun]

but a heads-up: IMO we'll get more support tickets and escalations because we aren't going to bump dependencies with a CVE unless the impacted code is used (directly or not) by ours.

This is something we should live with. The recent incident showed us that just upgrading forward for sake of upgrading can make us more vulnerable.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5bd1ecd736

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Trigger govulncheck on go.work dependency changes

The PR trigger is filtered to *.go, go.mod, and go.sum, but this repo also has go.work/go.work.sum; a PR that only changes workspace replacements or workspace dependency pins will skip this workflow entirely, so reachable-vulnerability gating and SARIF upload are bypassed for that change. Add go.work and go.work.sum to the pull_request.paths list so dependency-only workspace changes are still scanned.

Useful? React with 👍 / 👎.

[darccio]

cc @kakkoyun

[kakkoyun]

Fixed in 169fc65 and added go.work and go.work.sum to the pull_request.paths filter. Workspace-level dependency changes will now trigger both jobs.

[darccio]

[darccio]

@kakkoyun I was going to merge this, but there is a conflict. Can you take care of it? Thanks!