Chapter 14 — Software engineering
Lesson map
Lesson 14 published. Map, example, EX040.
flowchart TD
N0["Learning outcomes"]
N1["14.1 Security in the life cycle"]
N2["14.2 Lightweight design review"]
N3["14.3 Reviews and automation"]
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 Security in the life cycle"]
N2["14.2 Lightweight design review"]
N3["14.3 Reviews and automation"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX040"]
[Learning outcomes]
|
v
[14.1 Security in the life cycle]
|
v
[14.2 Lightweight design review]
|
v
[14.3 Reviews and automation]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX040]
Learning outcomes
You will (1) integrate security activities into a development life cycle; (2) run a lightweight design review; (3) use code review and automated checks effectively.
14.1 Security in the life cycle
Sofia joins a Corvia team building a new fare-refund service for a semester. Their life cycle has requirements, design, implementation, testing, release and maintenance. Daniel shows her where security fits: abuse cases alongside requirements, threat modelling at design, secure coding and review during implementation, security tests before release and vulnerability response afterwards. NIST SP 800-218 organises such practices into groups for preparing the organisation, protecting software, producing well-secured software and responding to vulnerabilities. Integrating security into each phase costs less than trying to add it at the end.
14.2 Lightweight design review
Before coding starts, the team holds a one-hour design review. They draw a data-flow diagram of the refund service, mark trust boundaries and walk each element through STRIDE categories as Shostack (2014) describes. They find that refund requests could be replayed to obtain double refunds, and that support staff could approve their own refund requests. Mitigations are recorded: unique request identifiers checked server-side, and a rule that approvers must differ from requesters. Sofia notes that one hour found two serious issues that would have been costly to fix after release.
14.3 Reviews and automation
During implementation, every change is reviewed by another engineer using a short checklist: input validation, authorisation checks, error handling and logging. Automated checks run static analysis and dependency scanning on each commit. Sofia learns that tools catch common patterns but miss design flaws such as the self-approval issue, while humans tire of repetitive checks that tools do well. Combining them is efficient. The team tracks findings to closure and reviews any finding the tools missed to improve the checklist, a feedback loop that improves the process itself.
Worked example
Sofia maps SP 800-218 practice groups to the refund project, takes part in a STRIDE review finding replay and self-approval issues and helps refine the review checklist.
Synthetic case. The refund service and findings are synthetic; SP 800-218 and Shostack (2014) are real.
Errors and limits
Lightweight reviews miss issues outside the diagram. Tools produce false positives that teams learn to ignore if not tuned.
Exercises
- EX040 — SP 800-218 groups. Name the four practice groups of SP 800-218. Rubric: 3 = prepare the organisation, protect software, produce well-secured software, respond to vulnerabilities;; 2 = three;; 1 = one;; 0 = none.
- EX041 — Refund findings. Which two issues did the design review find? Rubric: 3 = replayed refund requests and self-approval by support staff;; 2 = both;; 1 = one;; 0 = none.
- EX042 — Tools versus humans. What kind of flaw do tools typically miss? Rubric: 3 = design flaws such as self-approval logic;; 2 = design flaws;; 1 = syntax;; 0 = none.
Synthesis
Security fits every life-cycle phase, with short design reviews and combined human and automated checks catching different flaws.
Continue studying — chapter 14 of 50
← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →