Currently gong.go
downloads a pre-compiled binary from a GCS bucket, writes it to disk, and executes it. There is no checksum or signature verification at any point. The only trust anchor is HTTPS to GCS.
This is a problem for a few reasons:
A compromised bucket, misconfigured ACL, or supply chain incident means arbitrary code execution on the installing machine with zero detection
The gong binary runs with access to user database credentials, so the blast radius is not small
There is currently no way for a user or their security team to independently verify the binary was actually built by Bruin.
This comes up a lot in regulated industries where binary provenance is a hard requirement. Happy to work on a PR if the approach is agreed on.
Suggested fix:
Publish a signed checksums.txt alongside each release (SHA256 per platform binary). In downloadGong, after writing to the temp file, fetch the checksum file, verify the binary matches before the os.Rename call, and bail with a clear error if it doesn’t.
For signing, cosign keyless via Sigstore is the lowest-friction option if you’re on GitHub Actions — the signing identity is tied to the OIDC token from the Actions run, no long-lived key to manage. GoReleaser has native support for this so if you’re already using it for the main binary it’s mostly config.
Fallback if that’s too much overhead right now, a hardcoded SHA256 per version in version.txt or a sidecar file would at least catch accidental corruption or a compromised bucket, even without signature verification.
Currently gong.go
downloads a pre-compiled binary from a GCS bucket, writes it to disk, and executes it. There is no checksum or signature verification at any point. The only trust anchor is HTTPS to GCS.
This is a problem for a few reasons:
A compromised bucket, misconfigured ACL, or supply chain incident means arbitrary code execution on the installing machine with zero detection
The gong binary runs with access to user database credentials, so the blast radius is not small
There is currently no way for a user or their security team to independently verify the binary was actually built by Bruin.
This comes up a lot in regulated industries where binary provenance is a hard requirement. Happy to work on a PR if the approach is agreed on.
Suggested fix:
Publish a signed checksums.txt alongside each release (SHA256 per platform binary). In downloadGong, after writing to the temp file, fetch the checksum file, verify the binary matches before the os.Rename call, and bail with a clear error if it doesn’t.
For signing, cosign keyless via Sigstore is the lowest-friction option if you’re on GitHub Actions — the signing identity is tied to the OIDC token from the Actions run, no long-lived key to manage. GoReleaser has native support for this so if you’re already using it for the main binary it’s mostly config.
Fallback if that’s too much overhead right now, a hardcoded SHA256 per version in version.txt or a sidecar file would at least catch accidental corruption or a compromised bucket, even without signature verification.