What happened
On PR #351, coderabbitai flagged CWE-494 (download of code without integrity check) on the gh release download step in .github/workflows/fullsend-poll-jira.yaml. The step downloads and immediately extracts a tarball from fullsend-ai/fullsend releases without verifying its SHA256 checksum or Sigstore signature. The fullsend-ai review agent's security sub-agent did not flag this pattern — it focused on permission blocks and secrets instead. The v0.38.0 release provides checksums.txt and checksums.txt.sigstore.json that could be used for verification.
What could go better
The Jira poll workflow downloads and executes a binary with Jira credentials available in the environment. While the binary comes from a first-party repo (fullsend-ai/fullsend) and exploitability is rated difficult, verifying the download against the published checksum is a low-cost defense-in-depth measure. This is a pre-existing pattern that PR #351 did not introduce, but the version pinning change (from latest to v0.38.0) makes it a natural time to add verification.
Confidence: Moderate. The risk is low (first-party binary, pinned version, private repo), but the fix is simple and aligns with supply-chain security best practices. The Jira credential exposure elevates the concern slightly.
Proposed change
In .github/workflows/fullsend-poll-jira.yaml, update the download step to verify the tarball checksum before extracting. Replace the current single-line download-and-extract with:
run: |
gh release download v0.38.0 --repo fullsend-ai/fullsend \
-p 'fullsend_*_linux_amd64.tar.gz' \
-p 'checksums.txt'
sha256sum --check --ignore-missing checksums.txt
tar xzf fullsend_*_linux_amd64.tar.gz
sudo mv fullsend /usr/local/bin/This downloads both the tarball and the checksums file, verifies the tarball against the published checksum, and only then extracts it.
Validation criteria
The next workflow run of fullsend-poll-jira.yaml should: (a) successfully download and verify the checksum before extraction, (b) fail the job if the checksum does not match, and (c) pass coderabbitai's CWE-494 check on future PRs modifying this file.
Generated by retro agent from #351
What happened
On PR #351, coderabbitai flagged CWE-494 (download of code without integrity check) on the
gh release downloadstep in.github/workflows/fullsend-poll-jira.yaml. The step downloads and immediately extracts a tarball fromfullsend-ai/fullsendreleases without verifying its SHA256 checksum or Sigstore signature. The fullsend-ai review agent's security sub-agent did not flag this pattern — it focused on permission blocks and secrets instead. The v0.38.0 release provideschecksums.txtandchecksums.txt.sigstore.jsonthat could be used for verification.What could go better
The Jira poll workflow downloads and executes a binary with Jira credentials available in the environment. While the binary comes from a first-party repo (
fullsend-ai/fullsend) and exploitability is rated difficult, verifying the download against the published checksum is a low-cost defense-in-depth measure. This is a pre-existing pattern that PR #351 did not introduce, but the version pinning change (fromlatesttov0.38.0) makes it a natural time to add verification.Confidence: Moderate. The risk is low (first-party binary, pinned version, private repo), but the fix is simple and aligns with supply-chain security best practices. The Jira credential exposure elevates the concern slightly.
Proposed change
In
.github/workflows/fullsend-poll-jira.yaml, update the download step to verify the tarball checksum before extracting. Replace the current single-line download-and-extract with:This downloads both the tarball and the checksums file, verifies the tarball against the published checksum, and only then extracts it.
Validation criteria
The next workflow run of
fullsend-poll-jira.yamlshould: (a) successfully download and verify the checksum before extraction, (b) fail the job if the checksum does not match, and (c) pass coderabbitai's CWE-494 check on future PRs modifying this file.Generated by retro agent from #351