Skip to content

fix(release): reject malformed UTF-8 SBOM evidence - #113

Open
seonghobae wants to merge 3 commits into
mainfrom
fix/release-evidence-fatal-utf8
Open

fix(release): reject malformed UTF-8 SBOM evidence#113
seonghobae wants to merge 3 commits into
mainfrom
fix/release-evidence-fatal-utf8

Conversation

@seonghobae

@seonghobae seonghobae commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

Purpose

Test-first repair for #112. Release-evidence parsing now rejects malformed UTF-8 bytes instead of accepting Node's replacement-character normalization before JSON/CycloneDX validation.

Exact source / test-first identity

  • protected/live base: main c85d710804139c0697d7ef8fa47d02b1389e6d84;
  • branch: fix/release-evidence-fatal-utf8;
  • RED head: 42cb0c53d94dd21b73f5de7d07468bdeec1fd1f2;
  • GREEN head: 13849868812c7dc52cd3b973d89fa261ea5e9011.

RCA -> RED -> GREEN

readFileSync(sbomPath, "utf8") performed non-fatal UTF-8 decoding. An invalid byte inside an otherwise irrelevant JSON string became U+FFFD and the resulting different Unicode document could still satisfy CycloneDX structural validation.

The RED regression writes exact malformed bytes into an additional SBOM string field and requires fail-closed rejection plus absence of a release-evidence manifest. Application ci run 31439291632 completed failure on exact RED head 42cb0c53d94dd21b73f5de7d07468bdeec1fd1f2; the sibling reviewer and central Security Scan runs completed successfully, proving the intended application regression rather than a scanner/infrastructure failure.

GREEN 13849868812c7dc52cd3b973d89fa261ea5e9011 reads exact SBOM bytes and decodes them using TextDecoder("utf-8", { fatal: true }) before JSON.parse, retaining a separate JSON syntax failure boundary. Digest generation still hashes the retained SBOM bytes rather than decoded text.

Current exact-head technical evidence

For unchanged GREEN head 13849868812c7dc52cd3b973d89fa261ea5e9011:

  • application ci run 31439391439: terminal success;
  • reviewer-ci run 31439391449: terminal success;
  • central Security Scan run 31439391436: terminal success;
  • central scanner authority was independently re-read at .github revision 6eb06cdd08c79a06f7b390069d4ffa49e2eb7dba, workflow blob c3b8fa5dbbb21a684209683a3d4b6d29c8e0d536: PRs targeting main|master|develop are eligible; OSV and dependency-review are diff-scoped hard gates; fixable MEDIUM/HIGH/CRITICAL Trivy findings are repo-wide hard failures; Scorecard is soft evidence;
  • current formal reviews: 0;
  • current inline review threads: 0;
  • GitHub reports the PR mergeable and Ready for review.

Boundary / authority

This changes only the retained-SBOM byte-decoding boundary and its regression. It does not choose an outbound license, publish a release, deploy, modify workflow permissions, alter attestation authority, or manufacture production/acquisition evidence.

Technical exact-head success is not merge authority. Live enforceable governance under #27 and a qualifying independent non-author review path under #29 remain separate fail-closed gates where required. No self-approval, protection weakening, synthetic status, release or deployment is performed.

Related: #5, #68, #69, #112

@coderabbitai

coderabbitai Bot commented Aug 10, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@seonghobae, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 56 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: bc26ae9e-419e-4773-8f3a-3554f072fadf

📥 Commits

Reviewing files that changed from the base of the PR and between c85d710 and fca221d.

📒 Files selected for processing (2)
  • scripts/release-evidence.mjs
  • test/release-evidence.test.ts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@seonghobae
seonghobae marked this pull request as ready for review August 10, 2026 22:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant