OpenCyber Academy
Postgraduate · Chapter 2 · English
Course code: OCA-152Chapter 02: OCA-152-C002

Chapter 2 — Application and software supply chain security: current practice

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, EX006.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 Third-party code in apps"]
  N2["2.2 The SSDF"]
  N3["2.3 SAMM"]
  N4["2.4 SLSA and provenance"]
  N5["2.5 SBOMs"]
  N6["2.6 Gap assessment"]
  N7["2.7 The gaps that matter"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX006"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 Third-party code in apps"]
  N2["2.2 The SSDF"]
  N3["2.3 SAMM"]
  N4["2.4 SLSA and provenance"]
  N5["2.5 SBOMs"]
  N6["2.6 Gap assessment"]
  N7["2.7 The gaps that matter"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX006"]

[Learning outcomes]
    |
    v
[2.1 Third-party code in apps]
    |
    v
[2.2 The SSDF]
    |
    v
[2.3 SAMM]
    |
    v
[2.4 SLSA and provenance]
    |
    v
[2.5 SBOMs]
    |
    v
[2.6 Gap assessment]
    |
    v
[2.7 The gaps that matter]
    |
    v
[Worked example] --> [Exercise EX006]

Learning outcomes

You will (1) describe current industry practice for third-party code in applications; (2) relate practice to the SSDF, SAMM and SLSA; (3) assess Northbridge against current practice; (4) identify the gaps that matter most.

2.1 Third-party code in apps

Mobile and web apps typically include open-source libraries and commercial SDKs for analytics, crash reporting, payments and identity checks. SDKs run with the app's permissions and can collect data or change behaviour with each update.

Northbridge's mobile app includes SDKs for analytics, crash reporting and identity verification, and the February change came through the analytics one. The bank's own engineers never read the SDK's code, because it arrives as a compiled binary inside an automated dependency refresh. Whatever an SDK does with the app's permissions, the bank answers for it to its customers.

2.2 The SSDF

NIST SP 800-218 (Souppaya et al., 2022) asks organisations to acquire and maintain well-secured software components (PW.4), to protect all forms of code from unauthorised access and tampering (PS.1), and to identify and confirm vulnerabilities on an ongoing basis (RV.1). Third-party SDK governance falls largely under PW.4.

Hannah uses the SSDF as a checklist rather than a score, asking whether Northbridge has a working practice for each relevant task. For PW.4, the answer in February was no for commercial SDKs, even though open-source libraries were already scanned.

2.3 SAMM

OWASP SAMM v2 (2020) assesses maturity across governance, design, implementation, verification and operations. Its implementation function includes secure build and secure deployment practices, while the design function includes security requirements, including requirements for suppliers.

Hannah runs a light SAMM assessment with the mobile and platform leads, scoring each practice from interviews and samples of recent work. The scores show secure build is reasonably mature, while supplier security requirements are close to absent, which matches what the February incident exposed. Hannah repeats the assessment a year later with the same leads to measure change.

2.4 SLSA and provenance

SLSA v1.0 focuses on build integrity: knowing which source and build produced an artifact. For vendor SDKs delivered as binaries, provenance and signatures from the vendor would show the SDK was built as claimed, but most SDK vendors do not yet provide them.

Hannah therefore treats SLSA as the target for Northbridge's own builds and as something to ask vendors about, not as a requirement she can enforce on them yet. Her own release pipeline can produce provenance now; the SDKs inside it remain the weaker link.

2.5 SBOMs

NTIA (2021) minimum elements give a baseline for listing components. Northbridge generates SBOMs for its own builds, but the SDK appears as a single opaque entry.

That opaque entry tells the bank which SDK version is in the app but nothing about the components or data collection inside it. Hannah records this as a gap: the SBOM supports vulnerability matching for open-source code but could not have revealed the February behaviour change. A vendor SBOM would help with components, but behaviour still needs observing.

2.6 Gap assessment

Hannah's assessment finds: no review of SDK updates, no inventory of what data each SDK collects, no contractual SBOM requirement for vendors, and update automation that pulls SDKs along with open-source libraries.

She lists the four gaps in a table with the framework reference beside each, so the CISO can see why each one matters and which standard supports closing it. The fourth gap matters because automation treats a commercial SDK like any open-source library: a weekly dependency refresh can pull a new SDK version into the app without anyone reading its changelog. That is exactly how the February analytics update reached customers without review. Hannah adds the gaps to the bank's risk register so they are tracked like any other risk.

2.7 The gaps that matter

The February incident maps directly to the first two gaps; Hannah prioritises them.

The first gap let the update reach customers unreviewed, and the second meant nobody could say what the SDK was supposed to collect. Fixing these two would have caught February's change before release, so they come first. The contract and automation gaps matter too, but they would not on their own have stopped the location collection, so they follow in the plan. Each gap gets an owner and a target quarter in the plan the CISO approves.

Worked example

Hannah presents a one-page gap table to the CISO: practice, framework reference, Northbridge status, risk, owner. The CISO assigns owners for each of the four gaps and asks for monthly progress.

Synthetic case. Assessments are synthetic.

Errors and limits

Current practice differs by sector; banking regulation may require more than general frameworks.

Exercises

Synthesis

Compare practice with frameworks and focus on the gaps your incidents expose.

Continue studying — chapter 02 of 12

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

Worked answers

EX006. They run with the app's permissions and each update can change behaviour or data collection.

EX007. PW.4: acquire and maintain well-secured software components.

EX008. The SDK appears as a single opaque entry.

EX009. No update review, no data inventory, no vendor SBOM requirement and automation that pulls SDKs.

EX010. Practice, framework reference, Northbridge status, risk and owner.