harden-runner: close two egress-allowlist holes (deps.dev, Sonar binaries) - #95
Merged
Merged
Conversation
Dependency Review has been failing on every Go module bump with a bare "fetch failed" (PR #93, run 31419996907) while passing on Docker and Actions bumps. show-openssf-scorecard defaults to true, so for each added dependency the action needs the project's source repo URL. GitHub's dependency-change API supplies source_repository_url for Actions (and the action synthesizes it from owner/repo anyway), but leaves it null for most Go modules, so the action falls back to api.deps.dev to look it up. Unlike the Scorecard lookup that follows it, that deps.dev call has no error handling upstream, so egress blocking surfaces as an unhandled fetch rejection and fails the job before any dependency is reviewed. Allow api.deps.dev and api.securityscorecards.dev. The latter was also being blocked; it fails quietly, so the Scorecard summary was empty rather than fatal.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Docker Image Builtdocker pull ghcr.io/tight-line/ballast:pr-95-910c43aHelm (values override)image:
repository: ghcr.io/tight-line/ballast
tag: "pr-95-910c43a"Image expires ~15 days after PR closes. |
The SonarCloud scan has been failing since 18:34 UTC today with "failed: Connection refused" while fetching the Sonar Scanner CLI zip. It is not transient and it is not related to any change we made: the scan action downloads sonar-scanner-cli from binaries.sonarsource.com, which has never been on this job's allowlist. It went unnoticed because the action caches the CLI under a version-keyed Actions cache and only downloads on a cache miss. The cache predates the flip to block mode (ca837dc, Jul 24), and every run since restored it, refreshing its 7-day eviction window each time. The last restore was the Aug 3 run; seven days later the cache is gone (`gh cache list` shows no sonar-scanner-cli entry), so the download started running for real and hit the blocked endpoint. Allowing the host lets the cache repopulate, after which downloads stop happening again; the endpoint has to stay allowlisted regardless, since any scanner version bump invalidates the cache key.
nickmarden
changed the title
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.
Two unrelated egress holes, both surfacing today. Neither is transient.
1. Dependency Review:
fetch failedon every Go module bumpRun 31419996907 (#93, twice). Docker and Actions bumps pass, which makes it look flaky when it isn't.
show-openssf-scorecarddefaults totrue, so for each added dependency the action needs the package's source repository URL:github.com/<owner>/<repo>from the package name; no network call.source_repository_url: null, so the action falls back tohttps://api.deps.dev/v3/systems/go/packages/....That deps.dev call has no error handling upstream (
getProjectUrlinsrc/scorecard.ts), unlike thegetScorecardcall right after it, which is wrapped in try/catch. With egress blocked the fetch rejects, the rejection escapesmain(), and the job dies before reviewing a single dependency. The docker bump touched nothing in the dependency graph, so it had no changes to score at all.Allows
api.deps.dev:443andapi.securityscorecards.dev:443. The Scorecard endpoint was blocked too; it fails quietly, so the Scorecard summary in the job output has just been empty rather than fatal.2. SonarCloud:
Connection refusedfetching the scanner CLIStarted at 18:34 UTC today, on
mainas well as this branch.binaries.sonarsource.comhas never been on that job's allowlist; the scan action downloadssonar-scanner-cli-7.0.2.4839-linux-x64.zipfrom it.Hidden until now by caching. The action stores the CLI in a version-keyed Actions cache and only downloads on a miss. That cache predates the flip to block mode (ca837dc, Jul 24), and every run since restored it, refreshing its 7-day eviction window. Last restore was the Aug 3 run; seven days on, the cache is gone (
gh cache listshows nosonar-scanner-clientry), so the download ran for real and hit the wall.Allowing the host lets the cache repopulate. The entry has to stay regardless, since any scanner version bump invalidates the cache key.
Not fixed here
#93 also fails to compile, independent of both of the above:
otel/logv0.21.0 drops its ownlog.KeyValuein favor ofattribute.KeyValue, sointernal/logger/logger_test.go:135no longer builds. That fix belongs on the bump branch.Follow-up
pull_requestruns take the workflow file from the PR head, so #93 needs@dependabot rebaseafter this merges to pick these up.No CHANGELOG entry: CI egress allowlisting is not user-visible, matching the other
harden-runner:commits.