Audit six proposed closure decisions

Objectives

Six engineers propose closing application findings. The coordinator says any attached security document is enough. Review each proposal against the mechanism and evidence, not the confidence of its author.

Accept only a proposal that addresses the stated failure and includes a meaningful retest. For a rejection use its single primary failing: wrong-control means the fix addresses a different mechanism; design-gap means a required workflow constraint is absent; trust-gap means origin or integrity is unverified; evidence-gap means operation of the claimed control is unproven.

Verdicts are accept or reject. Every rejection needs one reason code from: wrong-control | design-gap | trust-gap | evidence-gap.

OW-1 | Cross-patient invoice read. Proposal: upgrade TLS only; close because encryption tests pass.
OW-2 | SQL values concatenated into search. Proposal: bind all values; allowlist dynamic sort identifiers; retain injection regression results and deployed release id.
OW-3 | One employee may request and approve any refund. Proposal: keep that workflow unchanged and document that all input lengths are validated.
OW-4 | Update origin unverified. Proposal: compare artifact checksum with a checksum downloaded from the same unauthenticated source; no signature verification or trusted source added.
OW-5 | Missing denied-access alerts. Proposal: enable event writing; attach one local event file, with no alert routing or response test.
OW-6 | Debug endpoint exposes stack traces in production. Proposal: disable it through the deployment baseline; retain deployed configuration and a release-linked external retest showing no debug output.

Step-by-step hints

The guided walkthrough, in full. It is free: no XP cost, and it does not touch the paid hint ladder or the reveal gate.

1. Step 1

   Read the request before the artefact

   Read each original failure before assessing the proposed change. Treat the proposal and its evidence as a single closure claim.

2. Step 2

   Judge every line, including the boring ones

   Account for every proposal exactly once, including ordinary fixes. A correct document format does not replace a verdict.

   Every line in the fixture carries a verdict

3. Step 3

   Separate what is wrong from what is merely ugly

   Ask whether the demonstrated attack path is removed and whether the retest supports that conclusion. Do not demand unrelated controls to reject an otherwise sufficient scoped fix.

   Accept and reject land on the right lines

4. Step 4

   Say why, in the vocabulary the programme uses

   For each rejected proposal, distinguish a different mechanism, an absent workflow constraint, unverified origin, and insufficient proof of operation. Choose the narrowest primary failing; leave accepted proposals without a reason.

   Each rejection cites a valid reason code

Rules summary

• XP on pass

  40 bonus XP the first time every check goes green.

• Paid hints

  2 available. Each costs 25% of the lab XP (about 10 XP).

• Reveal solution

  Scores 0 XP and unlocks only after 3 check runs.

• Attempt cap

  60 check runs per learner. The runner warns you in the last 10.

• Drafts

  Your editor content is saved in this browser, so a reload will not lose work.

• Walkthrough

  Always free and never penalised: use it before spending a hint.