Chapter 10 — Application and software supply chain security: orientation | Technologist 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.

Lesson map

Lesson 10 published. Map, example, EX028.

flowchart TD
  N0["Learning outcomes"]
  N1["10.1 Definitions"]
  N2["10.2 The stages"]
  N3["10.3 Frameworks"]
  N4["10.4 Brightwave's gaps"]
  N5["10.5 Trust"]
  N6["10.6 The course plan"]
  N7["Where the case fits"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX028"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["10.1 Definitions"]
  N2["10.2 The stages"]
  N3["10.3 Frameworks"]
  N4["10.4 Brightwave's gaps"]
  N5["10.5 Trust"]
  N6["10.6 The course plan"]
  N7["Where the case fits"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX028"]

[Learning outcomes]
    |
    v
[10.1 Definitions]
    |
    v
[10.2 The stages]
    |
    v
[10.3 Frameworks]
    |
    v
[10.4 Brightwave's gaps]
    |
    v
[10.5 Trust]
    |
    v
[10.6 The course plan]
    |
    v
[Where the case fits]
    |
    v
[Worked example] --> [Exercise EX028]

Learning outcomes

You will (1) define application and software supply chain security; (2) map the stages from code to client site; (3) place frameworks on the map; (4) see Brightwave's gaps.

10.1 Definitions

Application security protects the software's design and code. Supply chain security protects everything that goes into it and how it reaches users: source, dependencies, build, artifacts, deployment and updates. The January case needed both views, application security and supply chain security together. Greenleaf's upload feature was application code, while upload-kit arrived through dependencies and was built and deployed without anyone recording it. A team focused only on its own code would have missed the library entirely. Both views use the same evidence about Brightwave's projects, but they ask different questions of it. Application security asks whether the booking form handles uploads safely, while supply chain security asks where upload-kit came from and which clients received it.

10.2 The stages

For Brightwave: developers write code; libraries are fetched; the build service builds images; images go to a registry; deployment puts them on hosting; updates repeat the cycle. upload-kit passed through every stage: a developer added it, the build fetched it, images carried it, and deployments placed it on Greenleaf and museum-tickets. At no stage was the version recorded where anyone could query it across clients. Each stage also needs evidence that can be checked later: lockfiles for libraries, digests for images and deployment records for hosting. Missing evidence at any stage leaves a gap that the January search had to fill by hand.

10.3 Frameworks

NIST SP 800-218 (SSDF) groups practices into Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities. SLSA v1.0 focuses on build integrity and provenance. OWASP SAMM v2 assesses maturity. OWASP ASVS defines application requirements. Each framework answers a different question for Brightwave, so Diego uses them together rather than choosing one. Diego uses the SSDF to find gaps, SLSA to set build goals, SAMM to judge maturity and ASVS to write application checks. Each framework supplies one piece, and none of them alone would cover the whole January case. He keeps a short table linking each placement goal to the framework that informed it.

10.4 Brightwave's gaps

Mapping to the SSDF shows strengths in producing software (reviews, tests) but gaps in responding: no inventory before January, no target times for fixes. The upload-kit search is the clearest evidence of the responding gap: three days to find affected clients, and no agreed deadline for fixing them once found. The strengths in producing software were real, but code reviews and tests had never been asked to question a library's version or its advisories. Mapping also showed which existing strengths, such as reviews and tests, to keep.

10.5 Trust

Thompson (1984) reminded developers that you cannot fully trust code you did not create; evidence such as hashes and provenance is how trust is earned. For Brightwave this means trusting a library because a hash matches what was recorded, and trusting a deployed image because its digest matches a pipeline build, rather than trusting either because it carries a familiar name. Thompson's point applies even to Brightwave's own tools, since the build service and its actions are code the agency did not write. That is why pipeline actions are later pinned and reviewed like libraries.

10.6 The course plan

The next chapters build Brightwave's inventory, checks, controls and monitoring. The order follows the January lesson: an inventory comes first because no audit, fix target or monitor can work without knowing which client runs which version. Checks and pipeline controls follow, then monitoring and automation, and the final chapters test whether the whole arrangement survives a real-style advisory, a handoff and an assessment. Each chapter adds one control and tests it on the same client projects, so later chapters can measure what earlier ones changed. The three placement goals agreed in this chapter are the yardstick used again when the field event and the capstone are assessed.

Where the case fits

The upload-kit incident touches several stages: an outdated library was fetched, built into images and deployed without anyone recording which clients had it. The fix therefore needs work at several stages, not just one patch. That is why the course moves through inventory, checks, build controls and monitoring in order.

Worked example

Diego and Aiko agree three goals for the placement year: an inventory answering "who is affected" in minutes, fixes for high advisories within 7 days across all clients, and verified, recorded builds for every deployment.

Synthetic case. Goals are synthetic.

Errors and limits

Frameworks describe what good looks like; small agencies must choose what is proportionate.

Exercises

EX028 — Stages. List the stages for Brightwave.
Show marking criteria
Rubric: 3 = code, libraries, build, registry, deploy, update; 2 = four; 1 = two; 0 = none.
EX029 — SSDF gap. Where were Brightwave's SSDF gaps?
Show marking criteria
Rubric: 3 = Respond: no inventory, no fix targets; 2 = partial; 1 = vague; 0 = none.
EX030 — Three goals. State the three placement goals.
Show marking criteria
Rubric: 3 = inventory minutes; highs in 7 days; verified builds; 2 = two; 1 = one; 0 = none.

Synthesis

Map the chain and frameworks, then set goals for the gaps.

Continue studying — chapter 10 of 30

← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →