chore(ci): govulncheck - extend SARIF upload to cover contrib modules

[kakkoyun]

Why

The govulncheck-analysis job (non-blocking SARIF upload) only scanned core packages. Contrib module vulnerabilities were caught by govulncheck-tests (blocking, sandboxed) but never appeared in the GitHub Security tab / Code Scanning. This created a gap: a contrib CVE would fail the PR check but leave no trace in the Security dashboard.

This PR closes that gap by adding a parallel non-blocking govulncheck-contribs-analysis job that scans every contrib module and uploads results to GitHub Code Scanning.

What

• New script: govulncheck-contribs-sarif.sh — mirrors govulncheck-contribs-v2.sh but uses -format sarif. It scans each contrib module, writes a per-module SARIF file to a temp directory, then merges all runs into a single output file via jq.
• New job: govulncheck-contribs-analysis — sets up Go, installs govulncheck, runs the script, and uploads the merged SARIF under the govulncheck-contribs category.
• Updated comment in govulncheck-analysis: replaces the TODO with a reference to the new job.
• Updated paths filter: adds govulncheck-contribs-sarif.sh so changes to the script trigger the workflow.

Design decisions

Why merge SARIF with jq instead of uploading per-module files?
The upload-sarif action accepts a directory, but uploading N files (one per contrib module) would create N separate tool runs in Code Scanning, making the Security tab noisy. Merging runs into one SARIF file keeps results grouped under a single govulncheck-contribs category.

Why not sandbox this job?
The govulncheck-contribs-analysis job is non-blocking and informational, consistent with govulncheck-analysis. The sandboxed govulncheck-tests job provides the security boundary for blocking checks.

Stack

This PR is part of a stack:

main
 └── #4595 kakkoyun/govulncheck (base)
      └── #4597 kakkoyun/govulncheck-persist-credentials
           └── #4598 kakkoyun/govulncheck-sandboxed-step
                └── #4599 kakkoyun/govulncheck-action-allowlist
                     └── this PR kakkoyun/govulncheck-contrib-sarif

Merge order: #4595 → #4597 → #4598 → #4599 → this PR.

Test plan

• CI passes on this branch (all three jobs green)
• govulncheck-contribs-analysis job appears in the Actions run
• SARIF upload succeeds (check upload-sarif step output)
• GitHub Security tab shows findings under govulncheck-contribs category after merge to main

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (kakkoyun/govulncheck-action-allowlist@b8999e7). Learn more about missing BASE report.

Additional details and impacted files

🚀 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-official]

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 59.94% (-0.01%)

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

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-03-26 10:50:36

Comparing candidate commit 2198ae3 in PR branch kakkoyun/govulncheck-contrib-sarif with baseline commit b8999e7 in branch kakkoyun/govulncheck-action-allowlist.

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