Chapter 30 — Laboratory II | Bachelor's Application and software supply chain security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 30 — Laboratory II

Lesson map

Lesson 30 published. Map, example, EX088.

flowchart TD
  N0["Learning outcomes"]
  N1["30.1 The exercise"]
  N2["30.2 SBOM and advisories"]
  N3["30.3 Hashes"]
  N4["30.4 Signature and provenance"]
  N5["30.5 Tests"]
  N6["30.6 Report"]
  N7["30.7 Conduct"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX088"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["30.1 The exercise"]
  N2["30.2 SBOM and advisories"]
  N3["30.3 Hashes"]
  N4["30.4 Signature and provenance"]
  N5["30.5 Tests"]
  N6["30.6 Report"]
  N7["30.7 Conduct"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX088"]

[Learning outcomes]
    |
    v
[30.1 The exercise]
    |
    v
[30.2 SBOM and advisories]
    |
    v
[30.3 Hashes]
    |
    v
[30.4 Signature and provenance]
    |
    v
[30.5 Tests]
    |
    v
[30.6 Report]
    |
    v
[30.7 Conduct]
    |
    v
[Worked example] --> [Exercise EX088]

Learning outcomes

You will (1) run a complete supply-chain check on a release; (2) combine SBOM, hash, signature and provenance checks; (3) produce a release verification report; (4) practise authorised lab conduct.

30.1 The exercise

Lena runs a full check on the CampusEats release candidate in the test environment: generate the SBOM, check advisories, verify lockfile hashes, verify the signature and provenance, run ASVS-related tests.

The exercise brings together the checks from earlier chapters into one routine that can be repeated for every release. Lena times each step and finds the whole check takes under an hour. Every step has a pass condition written before the check begins, so the result cannot be judged generously afterwards. The checks run against the exact bundle that would be deployed.

30.2 SBOM and advisories

The SBOM lists 84 components; one medium advisory affects a development-only tool that does not ship; it is recorded as not applicable.

Lena confirms the tool is development-only by checking the SBOM's dependency relationships and the built bundle, which does not contain it. The decision is recorded with the evidence and an expiry date, so it is reviewed again if the tool's role changes. Recording it rather than ignoring it shows readers of the report that the advisory was considered. It is a small note.

30.3 Hashes

All packages match lockfile hashes.

Every package in the release matches the hash recorded in the lockfile, so the installed code is what the society reviewed. Lena also confirms that the lockfile itself was not changed since the last reviewed commit, since an altered lockfile with new hashes would pass the check while installing different code. The check takes seconds and is the same one that stopped the build in her first week. The result goes into the report. No package failed.

30.4 Signature and provenance

The bundle is signed by the expected build identity; provenance shows the expected repository and a reviewed commit.

Lena checks the identity against the value configured in the deployment step and the commit against the main branch's history. Both match. She also confirms the transparency log entry exists, which shows the signature was publicly recorded at build time. The reviewed commit is the one approved in the pull request, so the release contains only reviewed code. If any of these checks had failed, the release would have stopped until the cause was understood.

30.5 Tests

All authorisation, encoding and header tests pass.

The tests include the fixes from the ASVS review: the staff login rate limit, the shorter reset link lifetime, the audit log for price changes and the generic admin error page. Lena checks that each fix has its own test, so a later change that undoes it would be caught. A passing test suite is evidence of what was tested, not of the absence of flaws, and the report says so. Lena reruns them twice.

30.6 Report

A one-page release verification report lists each check, result and evidence link; it becomes part of the release.

Lena writes the report so that a member who was not involved can follow it and repeat each check. It records the release candidate's version and the date, and it states anything not checked, such as performance under load. Keeping reports with each release lets the society show later exactly what was verified before any version went live. Grace receives a copy each term.

30.7 Conduct

All work is done in the test environment under permission; findings are recorded in the private tracker.

The private tracker keeps findings from public view until they are fixed, so an issue is not advertised before CampusEats is protected. Lena's permission letter is linked from the report. If the exercise had turned up a flaw in a third-party package, she would follow the society's disclosure process and report it to the maintainer privately. She closes each finding with its fix linked.

Comparing releases

Lena compares the new SBOM with the previous release's: five components were added and two removed. Each addition is checked for an owner and a reason. Comparing releases shows changes clearly, which is easier to review than the full list of 84 components each time.

Lessons from the lab

The exercise shows that most checks are fast when automated, and that the slowest part is reviewing changes in the SBOM. Lena suggests showing only the differences by default, which halves review time in the next release.

Worked example

Grace asks how long the full check took: 12 minutes, mostly automated. She suggests making the report generation automatic too; Lena adds a script so every release produces its report.

Synthetic case. The release and results are synthetic.

Errors and limits

A clean report reflects the checks performed; it does not cover threats outside them.

Exercises

EX088 — Check list. List the five checks in the release exercise. Rubric: 3 = SBOM/advisories, hashes, signature, provenance, tests; 2 = four; 1 = two; 0 = none.
EX089 — Advisory result. What advisory issue was found? Rubric: 3 = medium in dev-only tool; not applicable; 2 = partial; 1 = vague; 0 = none.
EX090 — Automation. What did Grace suggest? Rubric: 3 = automate report generation; 2 = partial; 1 = vague; 0 = none.

Synthesis

Combine checks into one release verification with a clear report.

Continue studying — chapter 30 of 40

← Chapter 29 (draft) · Course chapter index · Chapter 31 (draft) →

Chapter 30 — Laboratory II