OpenCyber Academy
Bachelor's · Chapter 32 · English
Course code: OCA-106Chapter 32: OCA-106-C032

Chapter 32 — Application and software supply chain security: interdisciplinary interfaces

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 32 published. Map, example, EX094.

flowchart TD
  N0["Learning outcomes"]
  N1["32.1 Legal and licences"]
  N2["32.2 Procurement"]
  N3["32.3 Privacy"]
  N4["32.4 Accessibility"]
  N5["32.5 Usability"]
  N6["32.6 Communication"]
  N7["Shared language"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX094"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["32.1 Legal and licences"]
  N2["32.2 Procurement"]
  N3["32.3 Privacy"]
  N4["32.4 Accessibility"]
  N5["32.5 Usability"]
  N6["32.6 Communication"]
  N7["Shared language"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX094"]

[Learning outcomes]
    |
    v
[32.1 Legal and licences]
    |
    v
[32.2 Procurement]
    |
    v
[32.3 Privacy]
    |
    v
[32.4 Accessibility]
    |
    v
[32.5 Usability]
    |
    v
[32.6 Communication]
    |
    v
[Shared language]
    |
    v
[Worked example] --> [Exercise EX094]

Learning outcomes

You will (1) work with legal, procurement and privacy teams on software risks; (2) understand licences and contracts; (3) consider accessibility and usability alongside security; (4) communicate across disciplines.

32.1 Legal and licences

Open-source licences set conditions for use. A dependency with a licence incompatible with the university's rules must be replaced. CampusEats checks licences automatically and sends unusual ones to the university's legal team.

The licence check runs in CI alongside the advisory check and fails the build for a licence on the university's blocked list. Lena explains to members that licences matter for the same reason as security: the society must be able to keep using what it ships. Any exception is recorded with the legal team's advice.

32.2 Procurement

When cafés asked for a till integration, the university's procurement team needed security questions for the till vendor: Does it follow secure development practices like the SSDF? Does it provide SBOMs and timely fixes? Lena drafts the questions with Grace.

The questions are short and ask for evidence, such as a sample SBOM or the vendor's advisory process, rather than a yes or no. Procurement scores the answers alongside price and features, and Lena's questions are later added to the university's standard list for software purchases that handle student data.

32.3 Privacy

The data protection officer reviews new features that use personal data, such as loyalty points.

The officer asks what data the feature needs, how long it will be kept and whether students can opt out. For loyalty points, the society proposes counting orders without storing new personal data, and the officer approves it with a retention limit. Lena records the review in the feature's decision record, so the reasons are available if the feature changes later or is extended to other cafés.

32.4 Accessibility

Security features must be usable by everyone: multi-factor prompts and error messages must work with screen readers.

Lena tests the staff sign-in and error pages with a screen reader and finds that one error message is shown only as a red border with no text. The fix adds a clear message. A security step that some users cannot complete pushes them towards workarounds, such as sharing accounts, which undoes the protection it was meant to give. Lena adds a screen-reader check to the release verification report.

32.5 Usability

Johnson et al. (2013) showed developers avoid tools that are hard to use; the same applies to students facing awkward security steps. Good design reduces workarounds.

When members complained that the secret scanner's alerts were confusing, Lena rewrote them to say what was found, why it matters and how to fix it. Bypasses of the hook dropped the next term. She now asks of every new control how long it takes to use and what a confused member would do. Usability is a security property.

32.6 Communication

Each discipline uses different words; Lena keeps a glossary and explains technical terms in one sentence.

The glossary includes terms that mean different things to different groups, such as "incident", which the legal team uses more narrowly than developers do. When Lena writes for procurement or the data protection officer, she checks the glossary first. Misunderstandings between disciplines caused more delay in her early work than technical problems did, and the glossary has reduced them noticeably. New members receive a copy when they join, and anyone may add a term.

Shared language

Lena writes a one-page explainer on SBOMs for the legal and procurement teams, avoiding jargon. It explains what an SBOM shows, why it helps when a flaw is announced, and what to ask vendors for. Procurement now includes the SBOM question in every software purchase checklist.

Planning reviews

Reviews by other teams are booked at the start of a feature, not the end.

Worked example

The loyalty-points feature initially stored students' full order history indefinitely. The privacy review asks for points totals only, with history deleted after two years like other orders. The design changes before any code is written.

Synthetic case. Teams and features are synthetic.

Errors and limits

Interdisciplinary work takes time; plan reviews early in the design.

Exercises

Synthesis

Security works best alongside legal, procurement, privacy and usability expertise.

Continue studying — chapter 32 of 40

← Chapter 31 (draft) · Course chapter index · Chapter 33 (draft) →

Worked answers

EX094. They are flagged automatically and sent to the legal team.

EX095. Does it follow the SSDF, and does it provide SBOMs and timely fixes?

EX096. Store points totals only, with history deleted after two years.