◇ OpenCyber Academy
Engineering · Chapter 21 · English

Chapter 21 — Application and software supply chain security: requirements

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 21 — Application and software supply chain security: requirements

Lesson map

Lesson 21 published. Map, example, EX061.

flowchart TD
  N0["Learning outcomes"]
  N1["21.1 Sources of requirements"]
  N2["21.2 Writing them well"]
  N3["21.3 Application requirements"]
  N4["21.4 Pipeline requirements"]
  N5["21.5 Prioritising"]
  N6["21.6 Acceptance tests"]
  N7["Traceability to tests"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX061"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["21.1 Sources of requirements"]
  N2["21.2 Writing them well"]
  N3["21.3 Application requirements"]
  N4["21.4 Pipeline requirements"]
  N5["21.5 Prioritising"]
  N6["21.6 Acceptance tests"]
  N7["Traceability to tests"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX061"]

[Learning outcomes]
    |
    v
[21.1 Sources of requirements]
    |
    v
[21.2 Writing them well]
    |
    v
[21.3 Application requirements]
    |
    v
[21.4 Pipeline requirements]
    |
    v
[21.5 Prioritising]
    |
    v
[21.6 Acceptance tests]
    |
    v
[Traceability to tests]
    |
    v
[Worked example] --> [Exercise EX061]

Learning outcomes

You will (1) write verifiable security requirements for an application and its pipeline; (2) derive requirements from standards and threats; (3) prioritise requirements; (4) define acceptance tests.

21.1 Sources of requirements

Requirements come from threats (what could go wrong), standards (ASVS, SSDF, SLSA), law and contracts (payment card rules) and incidents (the mirror mismatch, the tmpl advisory).

Each source catches things the others miss. Threats reflect Coastline's own situation, standards bring lessons from many organisations, contracts set obligations the company cannot ignore, and incidents show where its own controls already failed. A requirement records its source, which helps when deciding later whether it is still needed. The tmpl advisory, for instance, is the source of the requirement that advisory checks cover transitive components.

21.2 Writing them well

A good requirement is specific and testable: "Deployment shall refuse any artifact whose SHA-256 digest does not match the signed build record" rather than "artifacts shall be secure".

The good example names the actor, the action, the condition and the outcome, so a tester can design a check and anyone can tell whether it is met. Words such as 'secure', 'appropriate' or 'robust' give no test and invite argument. Kwame rewrites each vague requirement until he can describe the acceptance test that would prove it.

21.3 Application requirements

Using ASVS as a base, Coastline selects requirements for authentication, access control, validation, output encoding and logging. ASVS 4.0.3 offers three levels; Coastline targets Level 2 for ticket-web because it handles payments. ASVS 5.0.0 keeps the level idea with reorganised chapters, so Kwame records both identifiers.

Level 2 is meant for applications handling sensitive data such as payments, while Level 1 covers basic checks and Level 3 suits the most critical systems. Recording both versions protects the work as the standard evolves: auditors using either edition can find each requirement, and moving to the new edition later becomes a mapping exercise rather than a rewrite.

21.4 Pipeline requirements

From SLSA v1.0: builds on a hosted platform, provenance generated by the platform, provenance verified before deployment. From SSDF: PO.3 secure toolchains, PS.1 protect code from unauthorised changes, PS.2 provide verification mechanisms, RV.1 identify vulnerabilities continuously.

Each pipeline item answers a specific risk. Hosted builds remove developers' laptops from the release path. Platform-generated provenance cannot be forged by the build script itself. Verification at deployment ensures the evidence is actually checked. Without that last step, the other two produce records nobody reads.

21.5 Prioritising

Requirements are ranked by risk reduction and effort; must-haves cover the two incidents.

The two incidents rank first because they showed real gaps at Coastline, not hypothetical ones. Among the rest, items that close several threats at once, such as deployment verification, rank above those that close one. Effort matters too: a cheap requirement with moderate benefit may be done before an expensive one with slightly more. The ranking is written down with its reasoning, so deferred items are not mistaken for forgotten ones, and the list is revisited when a new incident or standard changes the picture. Must-haves are not traded away for convenience.

21.6 Acceptance tests

Each requirement has a test: e.g., deploy a deliberately mismatched synthetic artifact in staging and confirm refusal.

The staging test uses a synthetic artifact, so it proves the check works without risking production. Tests run automatically wherever possible and are repeated after changes to the deployment tool, because a later change could disable the check silently. A requirement whose test cannot be automated gets a manual procedure and a scheduled date for running it. The result of every test run is kept, so auditors and the team can see that the requirement held throughout the year, not only on the day it was first accepted.

Traceability to tests

Each requirement is linked to the tests that prove it and the component that enforces it. When a test fails, the team knows which requirement is at risk. When a requirement changes, the team knows which tests to update. Kwame keeps this link in a simple table in the repository, reviewed with every architecture change.

Worked example

Kwame's requirement set has 42 items: 30 application (from ASVS), 12 pipeline (SLSA and SSDF). Ingrid approves 35 for this year and schedules 7 for next.

Synthetic case. Requirement counts are synthetic.

Errors and limits

Requirements lists grow; review yearly and remove ones that no longer apply.

Exercises

Synthesis

Derive testable requirements from threats and standards and give each an acceptance test.

Continue studying — chapter 21 of 50

← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →