Add govulncheck CI workflow

[Arnaud M. (ameukam)]

No description provided.

[Arnaud M. (ameukam)]

cc Benjamin Elder (@BenTheElder) Julian Gutierrez Oschmann (@juli4n)

[Benjamin Elder (BenTheElder)]

I think it might be more useful to run periodically on the merged code, since vulns can appear even with no pull request, and probably aren't related to the pull request?

[Arnaud M. (ameukam)]

Added a cron.

[Benjamin Elder (BenTheElder)]

I think we should drop the PR flow as well, so it doesn't block PRs while we remediate.

[Arnaud M. (ameukam)]

Done

[Benjamin Elder (BenTheElder)]

does this do symbol level by default, or only package level?

[Arnaud M. (ameukam)]

I believe it does symbol level by default.

[Benjamin Elder (BenTheElder)]

OK, I'd like to make sure it is symbol level to cut down noise.

[Benjamin Elder (BenTheElder)]

AIUI in Kubernetes it is only running at the package level.

[a4-a4s1]

Skim — clean addition; the minimal-scope permissions: contents: read is right.

One observation worth raising before this lands:

• Trigger is schedule-only. Weekly Mondays at 04:37 UTC catches CVEs published in the prior week, but does NOT catch vulnerabilities introduced by dependency-bump PRs at PR-time — dependabot (or any contributor) opens a PR pulling vulnerable-transitive-X, it merges before next Monday's run, and the project ships the vulnerable version for up to ~6 days before govulncheck flags it. Most security-conscious repos pair schedule: with pull_request: so dep-bump PRs get gated by the same check:

  on:
    schedule:
      - cron: "37 4 * * 1"
    pull_request:
      paths:
        - 'go.mod'
        - 'go.sum'
        - '**.go'

  govulncheck exits non-zero on found vulns, so under branch protection this becomes a merge gate.

Q: is the schedule-only shape intentional (e.g. to defer the cost of a PR-time check until governance lands), or would you accept a follow-up adding the PR-trigger?

[Benjamin Elder (BenTheElder)]

let's also run on push to main