# Reject a correctly signed wrong release

Use the complete synthetic fixture below in a notebook or text file. No live target, paid service or secret is needed. Make your own decision before opening the worked assessment. Then take the implementation option below, a local project in which you repair running code until its tests pass, and keep its test output with your written answers.

Prepare a consumer release decision using an artifact, SBOM, provenance and VEX packet. Several documents are individually valid but refer to different things.

## Supplied material

```text
Expected release: repository acme/widget, source revision c42, builder trusted/build-v2, artifact digest A=sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.
Downloaded artifact computes digest A. Its signature cryptographically verifies under the approved release key.
Provenance P: signature valid; subject digest B=sha256:bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb; source c42; builder trusted/build-v2.
SBOM S1: generated from source c42 before packaging; components widget 1.8 and helper 4.2; no artifact digest binding.
Inspection of final artifact: widget 1.8, helper 4.2, bundled codec 0.9.
VEX V1: signed statement from the codec producer; product digest B; vulnerability SYN-2026-1; status not affected because the optional parser was disabled. Artifact A has that parser enabled.
CI job PR-81 executes fork-controlled build commands without secrets; later publish job downloads its output by a mutable artifact name and signs it.
Previous release inventory contained helper 4.1 and no codec. All identifiers here are synthetic.
```

## Task 1

Create a join table that binds artifact, source, SBOM, provenance and vulnerability decisions to the expected release.

Your assessment:

## Task 2

Decide what can and cannot be concluded from each signature and statement.

Your assessment:

## Task 3

Write a build/publish boundary repair and a release inventory diff.

Your assessment:

## Task 4

Specify the smallest new evidence packet required before accepting A.

Your assessment:

## Decide the fixed cases

### What does each statement establish for artifact A?

Choose from: Applies to A; Applies to A but is incomplete; Does not apply to A.

- The artifact signature under the approved release key: ______
- Provenance P (subject digest B): ______
- SBOM S1 (from source c42, before packaging): ______
- VEX V1 (product digest B, parser disabled): ______

### Decide the release question.

Choose from: Yes; No.

- Can A be accepted on the supplied evidence?: ______

## Evidence

- Per-document acceptance/rejection table with mismatched fields.
- Inventory delta including the bundled component.
- CI trust-boundary diagram and publisher policy.
- Consumer verification checklist with explicit failure outcomes.

## Rubric

Score each criterion with the anchor whose evidence your answer shows: 0, 1 or 2 points. Every anchor describes something a reviewer can point to in your work. Aim for at least 7 of 8, with no unresolved critical failure.

### 1. Joins every accepted claim to A and rejects the B-bound evidence. (2 points)

- 0 points: Accepts P or V1 because their signatures verify.
- 1 point: Rejects P for its digest B but carries V1’s not-affected status over to A, or the reverse.
- 2 points: A join table on digest A: the artifact signature is accepted; provenance P is rejected (its subject is B); SBOM S1 is partial (no digest binding, codec missing); VEX V1 does not apply to A (it names B, and A has the optional parser enabled).

Your score:

### 2. Finds the bundled codec and qualifies the inventory delta. (2 points)

- 0 points: Uses S1 as the complete inventory.
- 1 point: Notes that codec 0.9 is missing from S1, but does not separate real changes from better discovery.
- 2 points: The inventory of the final artifact lists widget 1.8, helper 4.2 and codec 0.9; the delta against the previous release records helper 4.1→4.2 and codec 0.9 as newly shipped, and labels any entry that appears only because inspection improved.

Your score:

### 3. Repairs the untrusted-to-publisher hand-off at its actual boundary. (2 points)

- 0 points: Suggests only keeping secrets away from PR-81, or reviewing the fork’s code.
- 1 point: Identifies the hand-off by mutable artifact name, but the repair still signs output produced by the pull-request job.
- 2 points: The publisher never consumes output of fork-controlled commands: it rebuilds approved source c42 in the trusted release context, or verifies a reviewed immutable digest with provenance from the trusted builder, before signing. The diagram marks the PR job as untrusted.

Your score:

### 4. Signature, provenance, inventory and vulnerability applicability remain distinct decisions. (2 points)

- 0 points: One pass or fail for the whole packet.
- 1 point: Separate rows, but a failure in one is excused by evidence from another, such as the valid signature cited against the provenance mismatch.
- 2 points: A checklist with an explicit failure outcome for each check, and the smallest new packet: provenance for digest A from trusted/build-v2 at c42, an SBOM of the final artifact including the codec, and an A-specific VEX statement or analysis for SYN-2026-1 with the parser enabled.

Your score:

Critical failures (resolve before calling the case complete):

- [ ] Accepts P or V1 solely because their signatures verify.
- [ ] Omits codec because it is absent from the source manifest.

## Implementation option: Build and verify a signed software release

Build the release, then repair the consuming gate in exercise.mjs until all 20 tests pass, so a valid signature cannot approve the wrong source, builder or artifact.

Keep: Failing and passing test output, and a table mapping each trust decision in your join table to the test that fails without it.

Download: https://softwaresecurity.com/downloads/projects/release-verification-bd914fcbede61c32.zip (Node.js 22+ · no dependencies, 20 tests). Instructions: https://softwaresecurity.com/labs/#project-release-verification

## Worked assessment (read after completing the case)

The artifact signature authenticates A under the approved key, but P is about B and cannot satisfy A’s provenance policy. S1 is partial relative to the shipped contents; codec 0.9 is missing. V1 does not apply to A’s digest or enabled-parser configuration. Do not carry its not-affected status across those differences. The mutable PR output hand-off lets untrusted work feed the publisher; rebuild the approved immutable source in the trusted release context or enforce an equivalent reviewed immutable artifact provenance boundary. Require matching provenance, final-artifact inventory including codec, and an A-specific advisory decision. Record helper 4.1→4.2 and the new codec separately from additions caused only by better inventory discovery.

Original teaching material: CC BY 4.0. Attribution: Software Security.