# Write an honest release assurance decision

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.

A product lead asks for a release sign-off from an incomplete evidence bundle. Produce a scoped assurance record, exception and decision.

## Supplied material

```text
Product: tenant invoice API, release r8, artifact digest A. Scope: object reads, export, profile field updates and deployment pipeline. Payment processing and the mobile client are excluded and must not be described as assessed.
Local requirements: R-AUTH owner-or-tenant-finance-admin policy; R-FIELD ordinary users cannot change roles; R-REL deployed artifact must match the verified candidate.
Evidence E1: object-read tests pass on r8/A, including cross-tenant denial; no export tests.
E2: profile-field tests pass on r7/B.
E3: deployment record says tag latest; there is no observed running digest.
E4: reviewer statement says ASVS aligned but has no edition, selected requirement IDs or procedures.
Risk exception X1 proposes allowing untested export for 90 days with owner='security team', no compensating control and no expiry action.
Production policy: cross-tenant disclosure risks block release; a temporary disabled feature may be accepted only with a named product owner, tested disablement, deadline and automatic escalation at expiry.
A remediation branch adds export authorization but has not been built or tested.
```

## Task 1

Build a requirement→implementation→procedure→evidence→status table and distinguish fail, missing evidence and out of scope.

Your assessment:

## Task 2

Rewrite X1 into a bounded decision using only the allowed policy, or reject it if the needed conditions are not met.

Your assessment:

## Task 3

Choose the precise release claim supportable now and list what changes would alter it.

Your assessment:

## Task 4

Specify owner, due date, escalation and evidence retention for every open item.

Your assessment:

## Decide the fixed cases

### What does each item establish for release r8 (artifact A)?

Choose from: Supports only the cases it tested; Missing evidence; Stale: another release; Cannot establish the claim; Out of scope.

- E1: object-read tests on r8/A: ______
- Export authorization (R-AUTH for exports): ______
- E2: profile-field tests on r7/B: ______
- E3: deployment record with tag latest: ______
- E4: "ASVS aligned" with no edition or requirement IDs: ______
- The mobile client: ______

### Decide the requests.

Choose from: Yes; No.

- Accept risk exception X1 as written?: ______
- Release r8 now under the supplied policy?: ______

## Evidence

- Scoped assurance matrix with release and artifact identity.
- Rejected or conditional exception record with concrete conditions.
- Release decision that does not claim a whole ASVS level.
- Action list linking missing tests and deployment observations to owners.

## 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. Matrix binds each result to r8/A and separates missing, failed and excluded scope. (2 points)

- 0 points: Marks requirements as met from evidence on another release or artifact.
- 1 point: The matrix mixes missing evidence with failures, or lists payment or the mobile client as passed.
- 2 points: Rows for R-AUTH, R-FIELD and R-REL bound to r8 and artifact A: object reads passed (E1); export has no evidence; field updates have no r8 evidence (E2 is r7/B); deployed identity is unproven (E3 has only a tag); payment and mobile are out of scope, not assessed.

Your score:

### 2. Rejects the vague exception and states measurable conditions for any reduced scope. (2 points)

- 0 points: Accepts X1.
- 1 point: Rejects X1, but the replacement has no expiry action or no test that export is disabled.
- 2 points: X1 is rejected; any reduced-scope release needs a named product owner who accepts the residual risk, tests proving export is disabled on every route, a deadline and automatic escalation at expiry.

Your score:

### 3. Release wording matches the actual evidence and baseline scope. (2 points)

- 0 points: Claims ASVS compliance or a level, or calls the release secure.
- 1 point: Avoids a compliance claim, but the wording implies export or field updates were verified.
- 2 points: The claim covers tested object reads on r8 and artifact A only, says export, field updates and deployed identity are unverified so the policy blocks release, and lists what would change the claim.

Your score:

### 4. Open items have accountable roles, deadlines, verification and expiry behavior. (2 points)

- 0 points: Open items without owners, or owned by “security team”.
- 1 point: Owners are named, but at least one item has no due date or no verification.
- 2 points: Every open item (export tests, r8 field tests, the observed running digest, building and testing the remediation branch) has an accountable role, a due date, the evidence that closes it and what happens at the deadline.

Your score:

Critical failures (resolve before calling the case complete):

- [ ] Uses E2 to pass r8 field authorization.
- [ ] Approves a broad ASVS compliance claim.
- [ ] Treats an untested branch as deployed remediation.

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

Produce the evidence your release decision asks for: build the release, repair the gate until all 20 tests pass, and record the artifact digest each result applies to.

Keep: Test output tied to the artifact digest, and your assurance matrix updated with the rows this evidence changes and those it does not.

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)

E1 supports the tested object-read cases only. Export remains unverified; E2 is stale for r8; E3 cannot establish deployed identity; E4 establishes no verifiable standard claim. Reject X1 as written. A disabled-export release could be considered only after a named accountable owner accepts the bounded residual risk and tests prove export is disabled through all routes, with expiry/escalation and a repair plan. The proposed branch is not evidence for the candidate. Do not release under the supplied policy until required controls or an allowed, verified reduced scope are established. Excluded mobile and payment surfaces remain excluded, not passed.

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