Scan Go SDK dependencies for known vulnerabilities in CI - #70915
Merged
potiuk merged 1 commit intoAug 3, 2026
Conversation
Go modules resolve directly to upstream repositories with no central registry that pre-scans releases the way PyPI and npm now do, so a known-vulnerable or compromised dependency can enter the graph without any external scanner flagging it first. Add a govulncheck step to the Go SDK test job on both the amd and arm CI workflows. govulncheck checks the module graph against the Go vulnerability database and is reachability based, so it only fails the build on advisories that affect code the SDK actually calls, keeping the signal low-noise. This complements the daily CodeQL scan (which covers our own Go source, not dependency advisories) and the advisory-driven Dependabot security updates.
jason810496
requested review from
amoghrajesh,
ashb,
bugraoz93,
gopidesupavan,
jscheffl and
potiuk
as code owners
August 1, 2026 15:48
boring-cyborg
Bot
added
area:dev-tools
backport-to-v3-3-test
Contributor
Backport failed to create: v3-3-test. View the failure log Run detailsNote: As of Merging PRs targeted for Airflow 3.X In matter of doubt please ask in #release-management Slack channel.
You can attempt to backport this manually by running: cherry_picker 679cfca v3-3-testThis should apply the commit to the v3-3-test branch and leave the commit in conflict state marking After you have resolved the conflicts, you can continue the backport process by running: cherry_picker --continueIf you don't have cherry-picker installed, see the installation guide. |
This was referenced Aug 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Go modules resolve directly to upstream repositories. Unlike PyPI or npm — where releases are now scanned at publish time — there is no central registry that pre-scans a Go release, so a known-vulnerable or compromised dependency can enter the Go SDK's graph without any external scanner flagging it first.
We already limit Dependabot to advisory-driven security updates for Go modules (#70914) and CodeQL scans our own Go source daily, but neither continuously checks the dependency graph against known advisories.
What
Add a
govulncheckstep to theGo SDK testsjob on both the amd and arm CI workflows (kept in sync).govulncheck:The
@v1.6.0pin is immutable: Go module versions are content-addressed through the checksum database, unlike mutable Git tags used foruses:actions.This runs whenever the Go SDK job runs (i.e. when Go files change), catching a vulnerable dependency at the moment it is added or bumped.
Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 4.8) following the guidelines