From source to trusted release
Generate and compare inventory, assess dependency risk, verify artifacts and retain evidence tied to the shipped release.
- Reconcile inventory and dependency impact for the exact shipped artifact.
- Enforce producer, source and byte identity through a release decision.
- Use provenance and VEX as scoped claims whose evidence can be challenged.
- Distinguish source commits, package versions and artifact digests.
- Read compact JSON/YAML and comparison tables; no registry, signing credentials or live CI system is needed.
Estimated time: about 5.5–6.5 hours across 12 steps, including 3 browser labs.
By the end: A release evidence dossier containing an inventory reconciliation, change/impact assessment and explicit promotion decisions, followed by three tested lab repairs.
0 of 12 steps complete
Reconcile the runtime scan, build manifest and lockfile in the supplied fixture; classify build-only and embedded components separately.
Keep: A corrected component list with inclusion/exclusion evidence.
Complete when: The inventory names the intended artifact/platform and retains the embedded-component uncertainty instead of equating no detection with absence.
Open guide : Generate an SBOM for the software you actually releaseCompare the five supplied package identities, hashes and graph edges through the proposed format conversion.
Keep: A semantic conversion-loss report and acceptance assertions.
Complete when: Keep ecosystem, namespace, architecture and byte identity distinct; successful parsing cannot excuse a lost variant or edge.
Open guide : Choose SBOM formats and identify components accuratelyCompare the lab’s supplied shipped and documented package-URL arrays, including wrong versions, duplicate observations and extra development records.
Keep: A repaired inventory decision and actual lab case results.
Complete when: Return each missing shipped identity once in sorted order. Explain that set comparison does not discover actual archive contents or prove the shipped input is complete.
Open lab : SBOM completeness lab: Find the dependencies missing from a release SBOMClassify upgrade, same-version byte change, runtime removal and improved discovery in the supplied old/new inventories.
Keep: A causal diff with an owned hold/allow decision.
Complete when: The unexplained substitution remains a hold even when other changes are legitimate; the older inventory correction does not invent a software introduction.
Open guide : Review SBOM changes between releasesApply the fictional advisory to exact package coordinates, vulnerable operations and rollout evidence.
Keep: A service-specific triage and closure table.
Complete when: Reject the wrong ecosystem match, distinguish bounded non-reachability from absence and keep the partially patched fleet open.
Open guide : Triage new dependency vulnerability findingsApply the guide's rulesets to one repository: no direct or force pushes, a pull request approved by someone other than the last pusher, code owner review for build and release paths, and protected release tags.
Keep: The exported rulesets and the output of the guide's check showing they hold.
Complete when: Only reviewed pull requests reach the default branch, no one holds a standing bypass, and only the release automation can create release tags.
Open guide : Protect the source repository: rulesets, reviews and signed commitsTrace the report artifact from contributor execution to the privileged consumer and replace executable interpretation with the supplied small schema.
Keep: A trust-boundary diagram and five input decisions.
Complete when: Only the valid counts object passes; authentication of the producer does not make its script safe to execute with release authority.
Open guide : Keep untrusted CI work outside the release boundaryRun the Actions injection lab: flag every attacker-controlled context interpolated into a run script or a github-script body, and accept the environment-variable pattern.
Keep: A repaired workflow linter with the lab's passing cases.
Complete when: Issue titles, branch names and pull request text that reach a shell are flagged, and workflows that pass them through environment variables are not.
Open lab : Actions injection lab: Flag GitHub Actions expression injectionEvaluate the supplied verifier records under the protected policy, including the valid signature from the wrong identity.
Keep: A promotion decision with specific rejection reasons.
Complete when: The policy binds issuer, authorized identity and digest; a tag that now resolves to other bytes does not inherit approval.
Open guide : Verify artifact signatures against an explicit trust policyRepair the lab policy and run the expected producer, wrong producer and altered subject cases.
Keep: A tested policy plus a promotion-path note.
Complete when: The intended release passes and each near miss fails for its own predicate; state that the real deployer must pull the same verified digest.
Open lab : Signed artifact provenance lab: Reject a release from the wrong producerLocate subject, source dependency, builder and invocation in the complete statement and evaluate its near misses.
Keep: A provenance field map and bounded acceptance record.
Complete when: Field matching is conditional on trusted authentication and does not establish source review, application safety or a SLSA level.
Open guide : Read SLSA provenance and verify the claim you needCompare the two product versions, decoder evidence and signed VEX update in the supplied dossier.
Keep: A VEX acceptance/rejection record that preserves the original alert.
Complete when: Reject out-of-scope or contradictory claims even when authenticated; identify the build/configuration change that reopens the decision.
Open guide : Use VEX without losing vulnerability evidenceReject 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
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.Work through the case
Create a join table that binds artifact, source, SBOM, provenance and vulnerability decisions to the expected release.
Decide what can and cannot be concluded from each signature and statement.
Write a build/publish boundary repair and a release inventory diff.
Specify the smallest new evidence packet required before accepting A.
Decide the fixed cases
These parts of the case have one right answer, taken from the worked assessment. Check them here; the rubric below assesses your written reasoning. The capstone meets the bar when every decision is right and the self-check reaches it.
What does each statement establish for artifact A?
Decide the release question.
Evidence to retain
- 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.
Assess your work
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.
Score your answer against the anchors
Choose the anchor that matches your answer for each criterion.
Recorded checks stay in this browser only, so you can compare attempts. This is a self-assessment, not a certification.
Compare with the worked assessment
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.
Save a draft on this device to resume later. Automatic saving begins after you choose Save. Drafts are never sent by this application; use synthetic data.
No draft saved on this device yet.
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.
Node.js 22+ · no dependencies · 60–90 min · 20 tests
Runtime and cloud defense
Review workload identity, cluster boundaries, configuration drift, exposed APIs and incident evidence.
Your progress, your browser
Progress is stored on this device. Export it to carry it to another browser, or clear it whenever you want. Importing a file adds its completed items to the progress already here; items this site no longer offers are skipped and counted, and nothing else is removed.