Chapter 14 — Software engineering
Lesson map
Lesson 14 published. Map, example, EX027.
flowchart TD
N0["Learning outcomes and connection"]
N1["14.1 Why process matters"]
N2["14.2 A secure development lifecycle"]
N3["14.3 Reviews and inspections"]
N4["14.4 Dependencies and the supply chain"]
N5["14.5 Releases for long-lived systems"]
N6["14.7 Practical activity"]
N7["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX027"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["14.1 Why process matters"]
N2["14.2 A secure development lifecycle"]
N3["14.3 Reviews and inspections"]
N4["14.4 Dependencies and the supply chain"]
N5["14.5 Releases for long-lived systems"]
N6["14.7 Practical activity"]
N7["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX027"]
[Learning outcomes and connection]
|
v
[14.1 Why process matters]
|
v
[14.2 A secure development lifecycle]
|
v
[14.3 Reviews and inspections]
|
v
[14.4 Dependencies and the supply chain]
|
v
[14.5 Releases for long-lived systems]
|
v
[14.7 Practical activity]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX027]
Learning outcomes and connection
After this chapter you can (1) apply a secure software development lifecycle to infrastructure software; (2) manage requirements, design reviews, code review and inspections; (3) manage dependencies and the software supply chain with SBOMs and provenance; and (4) plan releases and updates for long-lived embedded and OT software. It builds on Chapters 5 and 9 and prepares Chapters 28, 31 and 39.
14.1 Why process matters
Brooks (1987) argued that software's essential difficulties — complexity, conformity, changeability, invisibility — admit no single breakthrough. Process does not remove them; it makes errors visible early, when fixing them is cheap, and leaves evidence that the work was done. For critical infrastructure the evidence is part of the product: regulators, insurers and asset owners will ask for it.
For TMRP's gateway, that evidence includes the threat model review, the test results and the signed build, all of which go into the dossier.
14.2 A secure development lifecycle
The NIST Secure Software Development Framework (SP 800-218) groups practices into preparing the organisation, protecting the software, producing well-secured software and responding to vulnerabilities. Concretely: security requirements and threat models with every feature; secure coding standards; peer review; automated static analysis and tests in continuous integration; protected build systems; vulnerability intake and disclosure; and patches with clear advisories. CISA's Secure by Design principles add that manufacturers should take ownership of customer security outcomes — secure defaults, no default passwords, memory-safe languages where feasible.
14.3 Reviews and inspections
Fagan (1976) described formal design and code inspections with defined roles and checklists, reporting that they found defects earlier and more cheaply than testing. Modern code review is lighter but keeps the principles: a second competent person reads every change, with a checklist that includes input validation, authentication, error handling and logging. Complexity metrics such as McCabe's cyclomatic complexity (McCabe, 1976) flag functions that are hard to test.
At LRWA every change to the gateway code is read by a second engineer with a checklist.
14.4 Dependencies and the supply chain
Most software is assembled from third-party components. A software bill of materials (SBOM) lists them so that, when a vulnerability is announced, you can tell whether you are affected (CISA SBOM resources). Provenance — verifiable evidence of how and from what an artifact was built — protects against tampered builds; the SLSA framework defines levels of build integrity, and reproducible builds let independent parties confirm that a binary matches its source.
14.5 Releases for long-lived systems
OT software may be maintained for twenty years. Plan for: signed updates; rollback; staged deployment (test bench, one site, fleet); compatibility windows; end-of-support dates published in advance; and an update process that works when a site is reachable only intermittently. An update mechanism is itself an attack surface and must be authenticated.
For TMRP the plan is concrete: the gateway moves from bench to PS2 to PS1, a rollback image is retained at each stage, and updates must reach stations that are only intermittently reachable over LTE. Because the gateways are recorded as technical debt with a three-year horizon, the end-of-support date is published from the start.
14.6 Worked example: the telemetry gateway project (synthetic)
TMRP must build a small gateway that adds HMAC authentication for legacy RTUs at PS1 and PS2. The plan: requirements R1, R2 and R7 traced to tests; a threat model reviewed by a second engineer; Python standard library only, avoiding third-party dependencies; static analysis and unit tests in CI; builds on a dedicated runner with signed artifacts and an SBOM (trivially short here); deployment to a bench, then PS2, then PS1; and a rollback image retained. Each step leaves a record in the evidence dossier (Chapter 48).
14.7 Practical activity
Write a one-page SSDF-mapped plan for a small tool you have written: for each of the four practice groups, list two concrete practices and the evidence each produces.
Choose something real that you have written, such as your Lab 3 parser, so the practices are concrete. For each practice, name the evidence it leaves: a review record, a test report, a signed build or an advisory template. If a practice would leave no evidence, either change it or admit that it is only an intention. Compare your plan with the TMRP gateway plan and note one practice you would add.
14.8 Common errors and limits
- Process documents without the practices they describe.
- Code review without a checklist or without authority to block.
- Dependencies pulled at build time without pinning or provenance.
- Update mechanisms without authentication or rollback.
- No published end-of-support date.
The TMRP gateway plan was written to avoid each of these. It uses the standard library only, so there are no unpinned dependencies; reviews follow a checklist; builds are signed with an SBOM; deployment keeps a rollback image; and the gateways have a published three-year horizon.
Exercises — chapter 14
EX027 — Review checklist. Objective: create a review checklist for infrastructure code. Inputs: Lab 3 and Lab 8 code. Steps: write a ten-item checklist and apply it to both labs, recording one finding for each. Expected evidence: checklist and two findings. Rubric: 3 = checklist specific (input validation, constant-time comparison, key handling, error paths, logging, limits) and findings real; 2 = generic checklist; 1 = no findings; 0 = none.
EX028 — SBOM response drill. Objective: use an SBOM in a vulnerability response. Inputs: a synthetic SBOM listing libmodbus 3.1.6, openssl 3.0.8, zlib 1.2.13 for the RTU-B firmware, and an advisory for one of these. Steps: describe the triage steps from advisory to decision, including how you determine exploitability in your deployment. Expected evidence: procedure. Rubric: 3 = match, reachability analysis, vendor contact, compensating control, communication; 2 = no reachability; 1 = "update everything"; 0 = none.
Chapter synthesis
Process makes errors visible early and leaves evidence. Use a recognised secure development framework, review with checklists, measure complexity, and treat dependencies and builds as part of your attack surface with SBOMs and provenance. Design releases and updates for decades, with authentication, staging and rollback.
Continue studying — chapter 14 of 50
← Chapter 13 · Course chapter index · Chapter 15 →
Continue to the next authored lesson.