OpenCyber Academy
Postgraduate · Chapter 5 · English
Course code: OCA-152Chapter 05: OCA-152-C005

Chapter 5 — Application and software supply chain security: design alternatives

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 05 published. Map, example, EX021.

flowchart TD
  N0["Learning outcomes"]
  N1["5.1 The need"]
  N2["5.2 Design A: manual review"]
  N3["5.3 Design B: automated diff plus targeted review"]
  N4["5.4 Design C: isolation"]
  N5["5.5 Delivery speed"]
  N6["5.6 Stakeholders"]
  N7["5.7 Choice"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX021"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["5.1 The need"]
  N2["5.2 Design A: manual review"]
  N3["5.3 Design B: automated diff plus targeted review"]
  N4["5.4 Design C: isolation"]
  N5["5.5 Delivery speed"]
  N6["5.6 Stakeholders"]
  N7["5.7 Choice"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX021"]

[Learning outcomes]
    |
    v
[5.1 The need]
    |
    v
[5.2 Design A: manual review]
    |
    v
[5.3 Design B: automated diff plus targeted review]
    |
    v
[5.4 Design C: isolation]
    |
    v
[5.5 Delivery speed]
    |
    v
[5.6 Stakeholders]
    |
    v
[5.7 Choice]
    |
    v
[Worked example] --> [Exercise EX021]

Learning outcomes

You will (1) design alternative processes for governing third-party code; (2) compare isolation, review and contractual approaches; (3) evaluate effects on delivery speed; (4) select a design with stakeholders.

5.1 The need

The board chose "review on update". Hannah must design how. Three designs are considered.

Each design must have been able to catch a change like February's location collection before release, and Hannah writes that down as the first requirement. The others are a cost the two-person security team can carry, an acceptable delay to releases, and evidence that audit can check later. She scores each design against these four requirements with the mobile and privacy leads, so the comparison is shared rather than hers alone.

5.2 Design A: manual review

Every SDK update is reviewed by the security team before merging: changelog, permissions requested, network destinations observed in a test run. Strong but slow; the security team has two people.

With more than twenty SDKs across the apps and frequent updates, two reviewers would soon become a queue that teams try to bypass. Design A would have caught February's change, but only if the reviewer happened to run the right test. Hannah keeps Design A as the fallback for SDKs the harness cannot exercise, such as those that only activate on specific devices or account types.

5.3 Design B: automated diff plus targeted review

A CI job runs the app in a test harness with synthetic data, records network destinations, permissions and data fields sent by each SDK, and compares with the previous version. Only changes trigger human review.

The harness uses fixed synthetic accounts and scripted journeys, so differences between runs come from the SDK rather than from the test data. A reviewer sees only what changed, such as a new destination or a new field, which keeps reviews short. Design B depends on the harness covering the journeys where SDKs actually run.

5.4 Design C: isolation

Run SDKs in a restricted wrapper that limits the data they can access, for example passing only anonymised events rather than giving SDKs direct access to device APIs. Strong but requires engineering work per SDK.

For the analytics SDK, isolation would mean the app passes it a fixed list of events with no location or device identifiers. Some SDKs, such as fraud detection, need direct device signals to work, so isolation cannot be applied everywhere. Isolation also needs maintenance whenever the SDK's interface changes between versions.

5.5 Delivery speed

Hannah models effects: Design A adds a median of 5 days per SDK update; B adds 1 day; C adds no delay after initial work but takes three months to build.

She takes these figures from a small dry run with one mobile team and from the platform team's estimate for building the wrapper. A five-day delay matters because security fixes also arrive as SDK updates, and slowing them adds risk of another kind. Hannah shows the mobile leads the assumptions, and they agree to measure the real delay during the pilot.

5.6 Stakeholders

Mobile engineers prefer B; privacy prefers C; the CISO wants something in place within a month.

Hannah sets out what each group gains and gives up in a short table. Engineers want speed, privacy wants the strongest limit on data, and the CISO needs a control that exists before the next SDK update arrives. She also records which concerns the chosen design does not answer, so they stay visible after the decision. Each concern on that list has an owner and a date when it will be looked at again.

5.7 Choice

B now, with C for the two SDKs that handle the most sensitive events over the next six months.

The diff can run within the CISO's one-month window, and the two SDKs chosen for isolation process the most sensitive events. The choice is recorded with the scores and the stakeholders' positions, and the CISO signs it. Hannah agrees to revisit the choice after the evaluation, in case the diff misses changes the pilot was designed to test. Design A remains as the fallback for SDKs the harness cannot reach in its scripted journeys.

Review records

Each review records the SDK, versions, changes found and decision.

Worked example

The February change would have been caught by Design B: a new network destination and a new data field (location) would appear in the diff. Hannah demonstrates this by replaying the February update in the harness with synthetic data.

Synthetic case. Designs and estimates are synthetic.

Errors and limits

Test harnesses may not trigger all SDK behaviours; some changes appear only with real usage patterns.

Exercises

Synthesis

Compare designs on protection, speed and stakeholder needs, then stage the solution.

Continue studying — chapter 05 of 12

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

Worked answers

EX021. A CI harness records SDK network destinations, permissions and data fields and flags changes for human review.

EX022. A adds 5 days, B adds 1 day, C adds none after three months of building.

EX023. Engineers preferred B, privacy preferred C, and the CISO wanted something within a month.

EX024. Design B now, plus isolation for the two most sensitive SDKs.

EX025. Yes; the new destination and location field would appear in the diff.