Chapter 14 — Software engineering
Lesson map
Lesson 14 published. Map, example, EX040.
flowchart TD
N0["Learning outcomes"]
N1["14.1 Requirements in the lifecycle"]
N2["14.2 Managing dependencies"]
N3["14.3 Reviewing for misuse"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX040"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["14.1 Requirements in the lifecycle"]
N2["14.2 Managing dependencies"]
N3["14.3 Reviewing for misuse"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX040"]
[Learning outcomes]
|
v
[14.1 Requirements in the lifecycle]
|
v
[14.2 Managing dependencies]
|
v
[14.3 Reviewing for misuse]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX040]
Learning outcomes
You will (1) integrate cryptographic requirements into the development lifecycle; (2) manage dependencies on cryptographic libraries; (3) review code for common misuse.
14.1 Requirements in the lifecycle
Aiyana joins Ridgeway's software team and finds that cryptography was added late to previous projects, causing rework. She proposes that security requirements, such as "every reading is authenticated with a per-meter key" and "firmware is accepted only with a valid signature", appear in the backlog from the start, each with an acceptance test. Treating cryptographic properties as testable requirements rather than as a final review makes them visible in planning and estimates, and makes it clear which team owns each property.
14.2 Managing dependencies
Ridgeway depends on a few cryptographic libraries. Aiyana records each library's version, its source and its maintainers, and subscribes to its security advisories. She pins versions so builds are reproducible but schedules regular updates, because cryptographic libraries fix vulnerabilities regularly. She also checks that downloaded packages match published hashes or signatures, to avoid tampered dependencies. The team agrees never to copy cryptographic code from forums into the codebase; if a function is missing, they find a maintained library or raise it in design review.
14.3 Reviewing for misuse
Aiyana writes a short review checklist: no hard-coded keys; secrets from the secrets module; no ECB mode or unauthenticated encryption; nonces never reused under a key; tags compared with hmac.compare_digest; passwords hashed with Argon2id; TLS verification never disabled. Reviewers tick each item for changes touching cryptography. In the first month the checklist catches a test helper that disabled certificate verification and was about to be reused in production code. Checklists do not replace expertise but catch common mistakes reliably.
Worked example
Aiyana adds testable crypto requirements to the backlog, pins and monitors libraries, and introduces a seven-item review checklist that catches disabled TLS verification.
Synthetic case. The team and incident are invented.
Errors and limits
Checklists can become box-ticking; reviewers must understand each item. Pinning without updating leaves known vulnerabilities in place.
Exercises
- EX040 — Testable requirement. Give an example of a cryptographic requirement written as a backlog item. Rubric: 3 = every reading authenticated with a per-meter key (or firmware accepted only with valid signature), with acceptance test;; 2 = example without test;; 1 = vague;; 0 = none.
- EX041 — Dependency rule. What did the team agree about forum code? Rubric: 3 = never copy cryptographic code from forums; use a maintained library or raise in design review;; 2 = avoid;; 1 = allowed;; 0 = none.
- EX042 — Checklist catch. What did the checklist catch in its first month? Rubric: 3 = a test helper disabling certificate verification about to enter production;; 2 = TLS issue;; 1 = vague;; 0 = none.
Synthesis
Cryptography becomes reliable when it is a tested requirement, its libraries are managed actively and reviews check for known misuse.
Continue studying — chapter 14 of 50
← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →