chore(ci): govulncheck - use official golang/govulncheck-action for SARIF analysis

[kakkoyun]

What does this PR do?

Replaces the manual go install govulncheck@latest + govulncheck -format sarif in the govulncheck-analysis job with the official golang/govulncheck-action@v1.0.4 maintained by the Go Security Team.

This PR will fail CI because golang/govulncheck-action is blocked by the DataDog enterprise action allowlist. It internally uses actions/checkout@v4.1.1 and actions/setup-go@v5.0.0 which are not in the allowlist. This PR exists to start the discussion for adding it.

Motivation

The official Go Security Team action provides:

• Automatic govulncheck version management — always uses the latest govulncheck without manual go install maintenance
• Built-in SARIF output with the correct schema, handling the --format sarif flag internally
• Less workflow code — one step instead of three (setup-go + go install + govulncheck)
• Official support from the Go team — bug fixes and improvements flow in automatically

The manual approach (from #4595) works correctly but requires us to maintain the invocation ourselves.

Note: The govulncheck-tests job (blocking CI check) retains direct invocation via the sandboxed-step from #4598, since golang/govulncheck-action doesn't support the multi-module scanning pattern needed for the 65+ contrib modules.

CI failure context

When we first tried this action in #4595, CI failed with:

"The actions actions/checkout@v4.1.1 and actions/setup-go@v5.0.0 are not allowed in DataDog/dd-trace-go because all actions must be from a repository owned by your enterprise, created by GitHub, verified in the GitHub Marketplace, or match one of the patterns..."

The action itself is from the golang GitHub org (official Go project). The only blocker is that its internal transitive dependency on older SHA-pinned action versions triggers the allowlist check.

To merge this PR: request adding golang/govulncheck-action to the DataDog enterprise GitHub Actions allowlist.

References

• golang/govulncheck-action — official Go team action with SARIF support
• Filippo Valsorda: Turn Dependabot Off — rationale for this migration
• PR #4595 — original govulncheck migration with workaround
• PR #4597 — persist-credentials: false
• PR #4598 — geomys/sandboxed-step (stacked below this PR)

Reviewer's Checklist

• N/A — CI/workflow-only change, no Go code modified

[datadog-prod-us1-4]

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 60.06% (+0.01%)

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 60.66%. Comparing base (f5cf6b9) to head (528e489).

Additional details and impacted files

see 9 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.

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-03-27 11:54:41

Comparing candidate commit 9341efc in PR branch kakkoyun/govulncheck-action-allowlist with baseline commit aa79d34 in branch kakkoyun/govulncheck-sandboxed-step.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 215 metrics, 9 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 ----------------------------------'