Chapter 14 — Software engineering
Lesson map
Lesson 14 published. Map, example, EX040.
flowchart TD
N0["Learning outcomes"]
N1["14.1 Lifecycle"]
N2["14.2 The SSDF"]
N3["14.3 Code review"]
N4["14.4 Continuous integration"]
N5["14.5 Dependency policy"]
N6["14.6 Release"]
N7["Definition of done"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX040"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["14.1 Lifecycle"]
N2["14.2 The SSDF"]
N3["14.3 Code review"]
N4["14.4 Continuous integration"]
N5["14.5 Dependency policy"]
N6["14.6 Release"]
N7["Definition of done"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX040"]
[Learning outcomes]
|
v
[14.1 Lifecycle]
|
v
[14.2 The SSDF]
|
v
[14.3 Code review]
|
v
[14.4 Continuous integration]
|
v
[14.5 Dependency policy]
|
v
[14.6 Release]
|
v
[Definition of done]
|
v
[Worked example] --> [Exercise EX040]
Learning outcomes
You will (1) use a development lifecycle that builds in security; (2) apply code review and continuous integration; (3) manage dependencies deliberately; (4) map practices to the SSDF.
14.1 Lifecycle
Coastline plans, designs, builds, tests, releases and maintains ticket-web in two-week iterations. Security activities sit in each step rather than at the end.
Spreading security across the steps means problems are caught where they are cheapest to fix. In planning, the team asks who may use a feature; in design, which trust boundaries it crosses; in building, whether review covered input handling; in testing, whether abuse cases were tried. Maintenance includes watching advisories for components already released. Two-week iterations keep each change small enough to review properly, and a flaw found late in one iteration can be fixed early in the next.
14.2 The SSDF
NIST SP 800-218 (Souppaya et al., 2022) organises secure development practices into four groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). Kwame maps Coastline's activities to these groups to find gaps.
The four groups cover more than coding. PO asks whether people, roles and tools are in place; PS whether source and releases are protected from tampering; PW whether design, review and testing produce sound code; RV whether flaws found after release are handled. Coastline's signed releases fall under PS, its review checklist under PW and its advisory check under RV. Activities with no group, or groups with no activity, both prompt questions.
14.3 Code review
Every change is reviewed by another engineer. A checklist prompts reviewers to look at input handling, authorisation and new dependencies.
A second engineer catches mistakes the author cannot see because they know what the code is meant to do. The checklist keeps reviews from focusing only on style. New dependencies are listed explicitly, because a single line in a manifest can bring in dozens of transitive packages, as the graph lab showed. Reviews of security-sensitive files, such as authorisation rules and pipeline configuration, require a reviewer from a named group of experienced engineers.
14.4 Continuous integration
Each change runs tests, static analysis, the dependency name check (chapter 7) and an advisory check. Failures block merging.
Running checks automatically on every change means they cannot be forgotten under deadline pressure. Blocking merges makes the result binding rather than advisory. The cost is occasional false alarms, which slow work if they are frequent, so the team tracks how often a failure turns out to be wrong and tunes the checks. A check that is regularly overridden is either fixed or removed, since ignored alarms train people to ignore real ones.
14.5 Dependency policy
New dependencies need a reason, an owner and a check of maintenance activity. Kula et al. (2018) found that developers often do not update dependencies, so each dependency's owner is responsible for keeping it current.
Maintenance activity is checked because an abandoned package will not receive fixes when flaws are found. The reason is recorded so that, years later, the team can tell whether the dependency is still needed. Owners receive the advisory alerts for their packages and plan upgrades. When an owner leaves Coastline, their packages are reassigned during the handover, so no dependency ends up without anyone responsible for it.
14.6 Release
Releases are built by CI, signed, and recorded with their digests.
Building releases only in CI means no artifact comes from a developer's laptop, where unreviewed changes or local tools could slip in. The signature lets deployment confirm that the artifact came from Coastline's pipeline. The recorded digest ties the release to the exact bytes built, which is what the mirror check compares against. Each release record also lists the source commit and the SBOM, so anyone can trace a running version back to the code and components it contains. A release lacking any of these records is not deployed.
Definition of done
A change is done only when it has tests, has been reviewed, passes CI and has its documentation updated. Security items are part of this definition, not optional extras: a new endpoint needs an authorisation test, and a new dependency needs a recorded owner. Kwame notices that clear rules reduce arguments during review, because everyone knows what is expected before they start.
Retrospectives
Every iteration ends with a short review of what went well and what to improve, including security.
Worked example
The SSDF mapping shows a gap in PO: no training plan for secure coding. Coastline adds a yearly short course and makes the review checklist part of onboarding.
Synthetic case. Practices and mapping are synthetic.
Errors and limits
A mapping shows practices exist, not that they work well.
Exercises
- EX040 — SSDF groups. Name the four SSDF groups. Rubric: 3 = PO, PS, PW, RV; 2 = three; 1 = one; 0 = none.
- EX041 — CI checks. List CI checks on each change. Rubric: 3 = tests, static analysis, name check, advisory check; 2 = three; 1 = one; 0 = none.
- EX042 — Gap found. What gap did the mapping reveal? Rubric: 3 = no secure-coding training (PO); 2 = partial; 1 = vague; 0 = none.
Synthesis
Security belongs in every step of the lifecycle, mapped and checked.
Continue studying — chapter 14 of 50
← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →