Update SLSA v1 schema _type value

[st3penta]

The schema and validation logic now accept both the new v1 statement type (https://in-toto.io/Statement/v1) and the legacy v0.1 type to maintain backward compatibility with Tekton Chains bug while supporting the latest in-toto specification.

Note: bumping in-toto dependency to v0.10.0 caused many deprecation warnings. Dealing with these deprecations requires a major refactoring, which doesn't fit in this PR. For this reason, i added a commit to ignore all of the warnings for now, and deal with them in a later moment. (https://issues.redhat.com/browse/EC-1648)

Co-Authored-By: Claude Sonnet 4.5 noreply@anthropic.com

Ref: tektoncd/chains#920
Ref: https://issues.redhat.com/browse/EC-1633

[qodo-code-review]

Review Summary by Qodo

Support SLSA v1 statement type with v0.1 backward compatibility

✨ Enhancement 🐞 Bug fix

Walkthroughs

Description

• Update SLSA v1 schema to accept both v1 and v0.1 statement types
• Add validation logic for backward compatibility with Tekton Chains bug
• Upgrade in-toto-golang dependency from v0.9.0 to v0.10.0
• Update multiple Go dependencies to latest versions

Diagram

flowchart LR
  A["SLSA Provenance Validation"] --> B["Accept v1 Statement Type"]
  A --> C["Accept v0.1 Statement Type"]
  B --> D["Updated Schema"]
  C --> D
  D --> E["Tekton Chains Bug Workaround"]
  F["Dependency Updates"] --> G["in-toto-golang v0.10.0"]
  F --> H["Other Go Dependencies"]

Loading

File Changes

1. internal/attestation/slsa_provenance_v1.go 🐞 Bug fix +2/-1

Add dual statement type validation for backward compatibility

• Modified statement type validation to accept both StatementInTotoV1 and StatementInTotoV01
• Added comment explaining the v0.1 acceptance is for Tekton Chains bug workaround
• Changed from single equality check to dual condition check

internal/attestation/slsa_provenance_v1.go

---

2. pkg/schema/slsa_provenance_v1.json ✨ Enhancement +5/-1

Update JSON schema to support dual statement types

• Changed _type field from const to enum accepting both v1 and v0.1 URIs
• Added $comment field documenting the Tekton Chains bug reference
• Maintains backward compatibility while supporting latest in-toto specification

pkg/schema/slsa_provenance_v1.json

---

3. go.mod Dependencies +32/-39

Upgrade in-toto and related Go dependencies

• Upgraded github.com/in-toto/in-toto-golang from v0.9.0 to v0.10.0
• Upgraded github.com/in-toto/attestation from v1.1.0 to v1.1.2
• Updated github.com/secure-systems-lab/go-securesystemslib from v0.9.0 to v0.10.0
• Updated numerous other dependencies including spf13/cobra, spf13/pflag, golang.org/x packages
• Removed unused dependencies like github.com/cucumber/godog and related packages

go.mod

---

View more (1)

4. go.sum Dependencies +67/-92

Update dependency checksums

• Updated checksums for all modified dependencies
• Added new checksums for upgraded versions
• Removed checksums for removed dependencies

go.sum

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Wrong attestation type output 🐞 Bug ✓ Correctness

Description

• SLSAProvenanceFromSignatureV1 now accepts both in-toto Statement v1 and v0.1, but the resulting
  slsaProvenanceV1.Type() still always reports v0.1.
• This makes AttestationResult.Type inconsistent with the actual _type in the attestation
  payload, which can confuse users and any downstream consumer relying on the reported type field.

Code

internal/attestation/slsa_provenance_v1.go[R55-56]

+	if statement.Type != in_toto.StatementInTotoV1 &&
+		statement.Type != in_toto.StatementInTotoV01 { // StatementInTotoV01 is needed to deal with this tekton chains bug: https://github.com/tektoncd/chains/issues/920"

Evidence

The parser explicitly accepts Statement/v1, but the attestation wrapper’s Type() method is
hardcoded to Statement/v0.1; that hardcoded value is then emitted into the report’s
AttestationResult.Type field.

internal/attestation/slsa_provenance_v1.go[50-58]
internal/attestation/slsa_provenance_v1.go[86-88]
internal/applicationsnapshot/attestation.go[42-47]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`SLSAProvenanceFromSignatureV1` now accepts in-toto Statement v1 (`https://in-toto.io/Statement/v1`) as well as v0.1, but `slsaProvenanceV1.Type()` still always returns `StatementInTotoV01`. This misreports the attestation type in `AttestationResult.Type`.

### Issue Context
The returned `attestation.Attestation` is converted into an `applicationsnapshot.AttestationResult` for reporting/JSON output, which uses `att.Type()`.

### Fix Focus Areas
- internal/attestation/slsa_provenance_v1.go[55-58]
- internal/attestation/slsa_provenance_v1.go[86-88]
- internal/applicationsnapshot/attestation.go[42-47]

### Suggested change
- Update `func (a slsaProvenanceV1) Type() string` to return the parsed statement’s type (e.g., `return a.statement.Type`).
- Update/extend unit tests in `internal/attestation/slsa_provenance_v1_test.go` to cover both v0.1 and v1 cases (and adjust the existing `Type()` expectation accordingly).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Flag	Coverage Δ
acceptance	55.47% <100.00%> (+<0.01%)	⬆️
generative	18.59% <0.00%> (-0.01%)	⬇️
integration	27.60% <0.00%> (-0.01%)	⬇️
unit	68.35% <100.00%> (+<0.01%)	⬆️

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

Files with missing lines	Coverage Δ
internal/applicationsnapshot/attestation.go	95.83% <ø> (ø)
internal/attestation/attestation.go	90.16% <ø> (ø)
internal/attestation/slsa_provenance_02.go	100.00% <ø> (ø)
internal/attestation/slsa_provenance_v1.go	100.00% <100.00%> (ø)
internal/image/fake.go	92.30% <ø> (ø)

🚀 New features to boost your workflow:

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