Trace dependency graphs, verify release identity and build provenance, and turn vulnerability findings into time-bound decisions.
55 min 195 XPSkills: Dependency integrity, Build provenance, Vulnerability decisions
Brief
Halcyon Clinics ships a patient messaging service with two declared libraries. A release scan finds 47 components, including a vulnerable parser nobody remembers selecting. The release manager calls the other 45 components 'scanner noise' and points to a signed archive as proof that the release is safe.
Your job is to reconstruct what entered the release, where it came from, and which build produced these exact bytes. Inventory, signatures and vulnerability assessments answer different questions. A credible release dossier joins them by artefact digest, records decision owners, and retains the evidence needed to reproduce a release decision rather than merely its green status.
A signature can authenticate malicious bytes. An inventory can accurately list vulnerable bytes. Neither is a safety verdict.
Resolve the graph, then freeze the inputs
A direct dependency is declared by your application; a transitive dependency arrives through another dependency. If messenger declares template-kit 2.4, which declares text-parser 1.8, the parser is transitive relative to messenger but direct relative to template-kit. Two paths can resolve different parser versions, so inventory must preserve versions and graph edges rather than collapse everything to a package name. Build-time tools matter too: an installer hook can execute before the application ever starts.
A manifest may allow a version range; a lockfile records the exact resolution, often including source locations and integrity digests. Commit and review lockfile changes, use frozen resolution that fails on manifest drift, and verify retrieved bytes against recorded digests. A lockfile is not a complete reproducible-build guarantee: compiler versions, build flags and environment inputs still matter. It also cannot make an already malicious locked package trustworthy.
Dependency confusion occurs when a resolver selects a public package for an intended internal name, for example because public version 90 outranks internal version 3. Typosquatting exploits a near-spelling of an intended name instead. Bind internal namespaces to an authorised registry with no public fallback, review new names and sources, and restrict installation hooks. For change-control evidence, retain the dependency diff and resolver policy; an auditor should be able to ask why a newly introduced source was permitted.
Lock exact resolutions and control their origins, including dependencies introduced through other libraries.
Inventory is a release-specific claim
An SBOM is a structured software bill of materials, not a vulnerability verdict. SPDX and CycloneDX are open formats for representing components and relationships. Include component names, versions, stable identifiers such as package URLs where applicable, hashes, dependency relationships, generation time and tool context. Both formats can express relationships; selecting one does not automatically supply complete coverage or accurate versions.
Generate inventory from resolved inputs and inspect the built artefact, then reconcile differences. A source-only list can miss bundled binaries; a runtime-only list can miss a build tool that influenced the output. Bind the SBOM to the released artefact's digest and declare scope and exclusions. A list for release 6.2 cannot silently stand in for 6.3 even when both use the same human-readable release label. For component-inventory controls, retain the SBOM, its generation record and reconciliation results; ask whether a sampled deployed digest has a matching inventory.
Verify bytes, identity and build history separately
An artefact digest identifies bytes; a signature binds a signing identity to a statement about those bytes. Verification must check the signature, the trusted identity and applicable validity policy, and the digest of the actual deployment candidate. A mathematically valid signature from an unapproved signer is insufficient. Protect signing keys or short-lived signing credentials from untrusted build steps; otherwise a compromised step can obtain a legitimate signature on its own output.
Provenance describes how an artefact was built: its subject digest, source revision, builder identity, invocation and relevant resolved inputs. Verify the attestation's signature and compare its claims with policy; provenance supplied by an attacker-controlled builder is not independently persuasive. Under the SLSA v1.0 Build track, L1 provides provenance, L2 adds a hosted build platform with authenticated provenance, and L3 requires a hardened platform with stronger isolation and protections against provenance forgery. These are build assurance levels, not severity scores; specify the track and version, and do not mistake a signed file for an L3 build.
At deployment, require the artefact digest, approved signer, trusted builder and permitted source revision to agree across the release and attestation. Retain verification outcomes and denied deployments as operating evidence for release-integrity controls. An auditor can then sample one deployment and follow its digest backwards to source and builder rather than accepting a screenshot saying 'signature valid'. Even a correctly attested build may contain a vulnerable dependency.
Deployment verification joins the artefact to an authenticated build claim and an explicit trust policy.
Put findings on a clock without hiding applicability
Set severity-based remediation SLAs as organisational policy, not as universal standard requirements. Here the clock starts at confirmed detection: critical 24 hours, high 7 days, medium 30 days, low 90 days. A high finding confirmed on 4 June at 10:00 is due on 11 June at 10:00. Exposure, active exploitation and business impact can justify escalation beyond a base CVSS score. Record owner, detection time, due time, deployed scope and verification of the fix; closing a ticket without checking the deployed version does not stop exposure.
VEX communicates vulnerability exploitability status for identified products and vulnerabilities, using statuses such as affected, not affected, fixed and under investigation. A defensible not-affected claim needs scoped evidence and justification, for example that the vulnerable code is absent from this exact artefact, not simply 'we have a firewall'. Under investigation is not a clearance. Preserve issuer, issue time, product identifiers, vulnerability identifier, supporting analysis and reassessment triggers when code or configuration changes.
A VEX statement informs prioritisation; it does not remove a component from the SBOM or magically approve overdue work. An affected finding that cannot meet its deadline needs documented risk acceptance by an authorised owner, compensating measures and an expiry. For vulnerability-management assurance, measure overdue affected findings separately from justified not-affected cases and retain both decisions. Ask who approved the exception, what evidence limited applicability, and when either decision must be revisited.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: Two libraries, forty-seven components
Scenario sim+65 XP
Read the brief and answer both questions.
Incident brief
The service declares template-kit, which imports text-parser. A developer labels text-parser a direct dependency of the service because its code executes in production. The manifest permits a version range, and tomorrow's clean installation selects a newer parser. The team proposes saving another copy of the manifest rather than the file that records exact resolutions.
1.1Relative to the service, what kind of dependency is text-parser? (two words)
1.2Which file should record the exact resolved dependency versions? (one word)
Task 2: The public package won
Scenario sim+65 XP
Read the brief and answer both questions.
Incident brief
An internal package named clinic-core exists at version 3. A public package with the identical name advertises version 90, and a resolver with public fallback installs it. The manager calls this typosquatting even though the spelling is identical. The incident team also needs an open SBOM format: their contract explicitly requires the format whose abbreviation starts with S, not the other accepted format taught here.
Term bank, not all of these are right
dependency confusionSPDXtyposquattingCycloneDX
2.1Which attack exploited the resolver's choice between internal and public sources? (two words)
2.2Which SBOM format matches this contract? (one abbreviation)
Task 3: Signed does not mean unaffected
Scenario sim+65 XP
Read the brief and answer both questions.
Incident brief
A critical vulnerability is confirmed at 09:00 in a deployed parser. The local policy uses the severity deadlines taught in this room, measured in hours or days from confirmed detection. The release manager demands closure because the archive is signed. An analyst instead prepares a product-and-vulnerability-scoped statement with an exploitability status and supporting justification; no applicability conclusion has yet been verified.
Term bank, not all of these are right
24VEX168SBOM
3.1How many hours after confirmation is remediation due under this policy? (a number)
3.2What is the abbreviation for the scoped exploitability statement being prepared? (one abbreviation)
Labs
80 bonus XP
Hands-on work. You edit the artefact, the server runs the checks: the expectations and the reference solution never reach your browser.
Halcyon Clinics is formalising its release gate. The release manager says a valid signature is enough and asks you to allow public fallback for internal packages to improve availability. Translate the approved requirements below instead of implementing that request.
Complete every empty scalar. The gate must freeze resolutions, restrict internal package origins, produce the contracted inventory, verify identity and provenance, and apply the local severity deadlines. The applicability note must describe evidence, not a blanket waiver.
Approved release requirements
resolution: frozen lockfile required; internal namespace must never fall back to public sources
inventory: contract requires SPDX, bound to artefact digest
verification: require signature and provenance; approved builder identity is release-builder
SLA hours from confirmed detection: critical 24; high 168; medium 720; low 2160
applicability: VEX not-affected justification must cite absent vulnerable code or unreachable vulnerable code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Checks
Frozen dependency resolution without public fallback
Six release dossier claims await approval. The manager says every claim mentioning a signature or a security acronym should pass. Evaluate whether each claim supports its stated conclusion, not whether the terminology sounds reassuring.
Accept claims with sufficient scoped evidence. For a rejection choose the most specific reason: origin for resolver trust-boundary errors, binding for missing byte identity, assurance for unsupported build-level claims, or applicability for unsupported exploitability conclusions.
Verdicts are accept or reject. Every rejection needs one reason code from: origin | binding | assurance | applicability.
Release dossier claims
SC-1 | Internal namespace can fall back to a public registry when a public package has the highest version; this prevents dependency confusion.
SC-2 | Release SBOM records exact component versions and dependency edges, declares scope, and identifies the deployed artefact by verified digest.
SC-3 | A valid artefact signature alone proves this build meets SLSA v1.0 Build L3; no builder isolation evidence is needed.
SC-4 | The retained SBOM is associated only with a mutable release label; no digest links it to deployed bytes, but it proves their inventory.
SC-5 | A not-affected VEX decision needs no technical justification because the download has a valid signature.
SC-6 | A high affected finding is due 168 hours after confirmed detection; closure requires evidence that the corrected version is deployed.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Checks
Every line in the fixture carries a verdict
Accept and reject land on the right lines
Each rejection cites a valid reason code
Next on your path · Application Fundamentals
Release and Runtime
Promote tested releases through isolated environments, enforce independent approval, and operate with reversible changes, protected secrets and actionable telemetry.
