Chapter 7 — Application and software supply chain security: organizational integration | Postgraduate 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 07 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes"]
  N1["7.1 Existing processes"]
  N2["7.2 Responsibilities"]
  N3["7.3 Procurement"]
  N4["7.4 Inventory"]
  N5["7.5 Training"]
  N6["7.6 Adoption measures"]
  N7["7.7 SAMM progress"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["7.1 Existing processes"]
  N2["7.2 Responsibilities"]
  N3["7.3 Procurement"]
  N4["7.4 Inventory"]
  N5["7.5 Training"]
  N6["7.6 Adoption measures"]
  N7["7.7 SAMM progress"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]

[Learning outcomes]
    |
    v
[7.1 Existing processes]
    |
    v
[7.2 Responsibilities]
    |
    v
[7.3 Procurement]
    |
    v
[7.4 Inventory]
    |
    v
[7.5 Training]
    |
    v
[7.6 Adoption measures]
    |
    v
[7.7 SAMM progress]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes

You will (1) embed third-party code governance into existing processes; (2) assign responsibilities across teams; (3) align procurement, privacy and engineering; (4) measure adoption.

7.1 Existing processes

Rather than adding a separate approval board, Hannah connects SDK governance to processes teams already use: the dependency update pull request triggers the diff; the privacy impact assessment covers new SDKs; procurement contracts include SDK clauses.

Each existing process gains one small step rather than a new meeting. Teams see the diff result in the pull request they already review, and procurement uses a revised template instead of a separate security questionnaire. Fitting into existing work also means the controls survive when the people who designed them move on to other roles.

7.2 Responsibilities

Mobile teams own SDK updates and first review of diffs; the security team reviews flagged changes involving new destinations or permissions; privacy reviews new data fields; procurement manages vendor terms. A RACI table makes this clear.

The table is published on the engineering wiki and linked from the pull request template, so anyone reviewing a diff can see who to call. Where two teams share an SDK, the RACI names one owner, so neither team can assume the other has already checked. Hannah reviews the table each quarter as teams and SDKs change.

7.3 Procurement

Standard contract terms now require: notice of data-collection changes, a security contact, timely fixes, and SBOMs where available. These align with SSDF PW.4.

Procurement applies the terms at renewal, so existing contracts move over during the year rather than all at once. Where a vendor refuses a clause, the refusal goes to Hannah's team for a risk decision, as happened with the fraud-detection vendor in chapter 8. The legal team keeps a short list of acceptable alternatives to each clause. Vendors receive the revised terms well in advance of renewal talks, so objections surface early.

7.4 Inventory

A register lists every SDK in every app, its owner, purpose, data processed and contract. It is generated partly from SBOMs and partly from the harness results.

The harness supplies what each SDK actually sends, while SBOMs supply names and versions, so the register can show where stated purpose and observed behaviour differ. Each entry has an owner who confirms it every quarter. The register is the starting point for the SDK reduction review in the applied project. Missing entries are chased by the register's owner each month.

7.5 Training

Short sessions for mobile engineers explain why SDK changes matter, using the February incident.

Each session lasts about forty-five minutes and walks through the February change as it would appear in the diff today. Engineers practise reading a diff result and deciding whether to approve it, send it to privacy, or ask the vendor. The sessions are repeated for new joiners, and the material is updated whenever a new difficult case is written up. Attendance is recorded for each team, but the sessions are not assessed or graded.

7.6 Adoption measures

Share of apps with the diff enabled, share of SDK updates with completed reviews, and register completeness.

Each measure has a definition and a data source, so the numbers can be checked rather than reported from memory. The diff measure comes from the CI configuration, review completion from pull requests, and register completeness from comparing the register against SBOMs. Hannah reports all three monthly to the CISO, with the apps that are behind named alongside their owners and expected dates. Trends across several months matter more to the CISO than any single month's figure.

7.7 SAMM progress

Using SAMM v2, Northbridge's maturity for supplier security in design and for secure build in implementation rises one level over a year.

The rise rests on evidence an assessor can check, such as contract terms, the register and pull request records, rather than on new policy documents. Hannah reports the change cautiously, because SAMM levels summarise practice and a one-level rise does not prove fewer incidents. She records the evidence behind each scored practice, so the next assessment can check whether the rise held. The assessment is repeated each year with the same leads.

Feedback loop

Teams can propose changes to the process through a shared channel. In the first quarter, engineers asked for the diff report to show SDK changes in plain language; the security team rewrote the report format, and review time per flag fell.

Worked example

Six months in, 11 of 12 apps have the diff enabled; the twelfth, a legacy app due for retirement, is given an exception with an expiry date. Register completeness is 96%; the missing entries are internal test SDKs.

Synthetic case. Teams and figures are synthetic.

Errors and limits

Integration depends on people; turnover can erode it, so keep processes documented and simple.

Exercises

EX031 — Integration principle. How did Hannah avoid a separate board?
Show marking criteria
Rubric: 3 = connect to existing PR, PIA, procurement processes; 2 = partial; 1 = vague; 0 = none.
EX032 — Responsibilities. Who reviews new data fields?
Show marking criteria
Rubric: 3 = privacy team; 2 = partial; 1 = vague; 0 = none.
EX033 — Contract terms. List three standard contract terms.
Show marking criteria
Rubric: 3 = notice of changes, security contact, timely fixes, SBOMs (three); 2 = two; 1 = one; 0 = none.
EX034 — Adoption status. What was the six-month adoption status?
Show marking criteria
Rubric: 3 = 11/12 apps; legacy exception; 96% register; 2 = partial; 1 = one; 0 = none.
EX035 — Exception rule. How was the legacy app handled?
Show marking criteria
Rubric: 3 = exception with expiry; 2 = partial; 1 = vague; 0 = none.

Synthesis

Embed governance into existing processes with clear owners and measured adoption.

Continue studying — chapter 07 of 12

← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →