fix(EC-1912): validate in-toto statement type in bundle attestation path

[BohdanMar]

ProvenanceFromBundlePayload accepted any _type value in in-toto statements, unlike the SLSA-specific parsers which reject unknown types. This adds the same validation to the bundle path — accept v0.1 and v1, reject anything else.

Defense-in-depth only — the attestation_type policy rule already catches this at evaluation time.

Jira: EC-1912 | Ref: EC-1838

[coderabbitai]

📝 Walkthrough

Walkthrough

ProvenanceFromBundlePayload now validates embedded in-toto statement types before extracting signatures. Tests cover unsupported and missing _type values, including their error messages.

Changes

Attestation validation

Layer / File(s)	Summary
Validate embedded statement types internal/attestation/attestation.go, internal/attestation/attestation_test.go	ProvenanceFromBundlePayload rejects unsupported or missing statement types and tests assert the resulting error contents.

Estimated code review effort: 2 (Simple) | ~10 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly states the main change: validating in-toto statement types in the bundle attestation path.
Description check	✅ Passed	The description matches the change and correctly explains the new type validation and its scope.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 11:12 AM UTC · Completed 11:16 AM UTC
Commit: 87c4a29 · View workflow run →

[fullsend-ai-review]

Review of PR #3418

fix(EC-1912): validate in-toto statement type in bundle attestation path

Summary

This PR closes a validation gap in ProvenanceFromBundlePayload where any _type value in in-toto statements was accepted without checking. The SLSA-specific parsers (SLSAProvenanceFromSignature at slsa_provenance_02.go:55 and SLSAProvenanceFromSignatureV1 at slsa_provenance_v1.go:56-58) already perform this validation, but the generic bundle path did not.

Analysis

Correctness — The validation check exactly mirrors the pattern in slsa_provenance_v1.go:56-58, accepting both StatementInTotoV1 (https://in-toto.io/Statement/v1) and StatementInTotoV01 (https://in-toto.io/Statement/v0.1). The check is placed correctly — after the statement JSON is unmarshaled and before entity signatures are created. Both callers handle the new error appropriately:

• application_snapshot_image.go:334-337 propagates the error (consistent with its existing hard-error handling of all parse failures)
• sigstore.go:442-450 appends to errorTerms and continues processing remaining attestations

Test coverage is adequate: two new table-driven test cases cover an unsupported type string and an empty/missing _type field.

Security — This is a security improvement. It adds defense-in-depth validation to close the inconsistency between bundle and non-bundle attestation paths. The attestation_type policy rule provides a second layer at evaluation time, but rejecting unknown types at parse time is the safer default.

Intent & coherence — The change is well-scoped. The PR description correctly explains why only ProvenanceFromBundlePayload is changed and why ProvenanceFromSignature is intentionally left unchanged (it feeds into downstream SLSA-specific parsers that handle their own type validation; adding validation there would break non-SLSA attestation types).

Style/conventions — Code follows existing patterns exactly: same condition structure, same error message format ("unsupported attestation type: %s"), same table-driven test style. The whitespace addition at line 128 is a trivial cleanup.

Documentation — No documentation updates needed for this internal defense-in-depth change.

Cross-repo contracts — The Attestation interface is unchanged. The stricter validation is in an internal/ package. Callers already handle errors from this function.

Verdict

Approve — Clean, well-tested, defense-in-depth fix that closes a validation gap between the bundle and non-bundle attestation code paths. No blocking findings.

---

Labels: Defense-in-depth bug fix for attestation type validation in bundle path

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Flag	Coverage Δ
acceptance	54.26% <66.66%> (-1.33%)	⬇️
generative	16.15% <0.00%> (-1.68%)	⬇️
integration	26.85% <0.00%> (+0.29%)	⬆️
unit	68.78% <100.00%> (-0.26%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
internal/attestation/attestation.go	91.25% <100.00%> (+0.34%)	⬆️

... and 27 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.