Chapter 2 — Application and software supply chain security: advanced seminar | Master'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.

Lesson map

Lesson 02 published. Map, example, EX008.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 Frameworks"]
  N2["2.2 ASVS versions"]
  N3["2.3 Threat modelling"]
  N4["2.4 Supply chain links"]
  N5["2.5 Seminar argument"]
  N6["2.6 Critique"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX008"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 Frameworks"]
  N2["2.2 ASVS versions"]
  N3["2.3 Threat modelling"]
  N4["2.4 Supply chain links"]
  N5["2.5 Seminar argument"]
  N6["2.6 Critique"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX008"]

[Learning outcomes]
    |
    v
[2.1 Frameworks]
    |
    v
[2.2 ASVS versions]
    |
    v
[2.3 Threat modelling]
    |
    v
[2.4 Supply chain links]
    |
    v
[2.5 Seminar argument]
    |
    v
[2.6 Critique]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX008]

Learning outcomes

You will (1) critically discuss secure development frameworks; (2) compare verification standards across versions; (3) relate application flaws to supply-chain practices; (4) present a seminar argument.

2.1 Frameworks

NIST SP 800-218, the SSDF (Souppaya et al., 2022), groups practices into preparing the organisation, protecting software, producing well-secured software and responding to vulnerabilities. OWASP SAMM v2 (2020) measures maturity in governance, design, implementation, verification and operations. Sofia's intervention sits in SSDF PW.8 (test executable code) and SAMM's verification function.

Placing the intervention in both frameworks lets Tallyline report it in the language its auditors and customers already use. PW.8 asks for executable code to be tested, and the role-matrix tests do exactly that for authorisation; SAMM's verification function gives Tallyline a way to describe how far its testing practice has matured.

2.2 ASVS versions

ASVS 4.0.3 (2021) and 5.0.0 (2025) both require that access control is enforced on a trusted service layer and that users cannot access records by manipulating identifiers. Version 5.0.0 reorganised chapters and requirement numbering, so Sofia records both identifiers for each test.

Recording both identifiers keeps the tests traceable whichever version a customer or auditor uses. Sofia's seminar slide maps each Tallyline test to its 4.0.3 requirement, its 5.0.0 equivalent, an SSDF practice and a SAMM activity; Dr Lee suggested adding the CWE entry as well, so findings link to weakness data.

2.3 Threat modelling

Shostack (2014) describes threat modelling around four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good job. Tallyline's role matrix is a product of the first two questions applied to authorisation.

The matrix answers "what are we working on" by listing roles and endpoints, and "what can go wrong" by stating, for each pair, what must be refused. The March invoice flaw and the later refunds flaw are both cases where the answer to the second question had never been written down.

2.4 Supply chain links

Access checks often live in shared libraries or frameworks. If a team upgrades an authorisation library and its defaults change, flaws can return. Sofia notes the SLSA v1.0 idea that build inputs should be known and traceable; knowing which library version ran in each release helps explain regressions.

For Tallyline, this idea has a direct example: the framework upgrade in release 8 added a default deny for unmapped routes. A change in a dependency's defaults can remove flaws as well as add them, so Sofia records which framework version ran in each release. Without that record, the fall in findings after release 8 could not be split between the tests and the upgrade.

2.5 Seminar argument

Sofia argues that tests encoding the intended access model are a verification practice that also documents design intent, linking SSDF PW.8, SAMM verification and ASVS requirements.

Her slide made the link concrete for each test: the test that a customer cannot read another business's invoice maps to an ASVS requirement on manipulated identifiers, to PW.8 and to SAMM verification. A test that documents intended behaviour also helps when roles change, because the matrix shows what the old decision was before anyone edits it.

2.6 Critique

A classmate argues that tests only check the cases someone wrote down; missing roles or endpoints stay untested. Sofia accepts this and plans to measure matrix completeness.

The pilot later proved the classmate right: the matrix initially missed the "export" endpoint, and a completeness check found three more unmapped routes, internal health checks. Sofia's answer was a check that lists all routes from the framework and flags any missing from the matrix, which turns the critique into a measured quantity.

Worked example

Sofia's seminar slide maps each Tallyline authorisation test to an ASVS 4.0.3 requirement, its 5.0.0 equivalent, an SSDF practice and a SAMM activity. Dr Lee suggests adding the CWE entry for each test so findings link to weakness data.

Synthetic case. Seminar content about Tallyline is synthetic.

Errors and limits

Mapping to frameworks shows alignment, not effectiveness.

Exercises

EX008 — SSDF groups. Name the four SSDF practice groups.
Show marking criteria
Rubric: 3 = prepare, protect, produce, respond; 2 = three; 1 = one; 0 = none.
EX009 — Intervention placement. Where does the intervention sit in SSDF and SAMM?
Show marking criteria
Rubric: 3 = PW.8; SAMM verification; 2 = partial; 1 = vague; 0 = none.
EX010 — Version care. Why record both ASVS identifiers?
Show marking criteria
Rubric: 3 = 5.0.0 renumbered chapters; 2 = partial; 1 = vague; 0 = none.
EX011 — Four questions. State Shostack's four questions.
Show marking criteria
Rubric: 3 = working on; go wrong; do about it; good job; 2 = three; 1 = one; 0 = none.
EX012 — Library link. How can libraries cause regressions?
Show marking criteria
Rubric: 3 = upgrade changes defaults; traceable inputs help; 2 = partial; 1 = vague; 0 = none.
EX013 — Classmate critique. What was the critique and response?
Show marking criteria
Rubric: 3 = tests check only listed cases; measure matrix completeness; 2 = partial; 1 = vague; 0 = none.
EX014 — Mapping addition. What did Dr Lee add to the mapping?
Show marking criteria
Rubric: 3 = CWE entry per test; 2 = partial; 1 = vague; 0 = none.

Synthesis

Frameworks give vocabulary and placement; critique reveals what tests cannot see.

Continue studying — chapter 02 of 08

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →