Chapter 18 — Security architecture
Lesson map
Lesson 18 published. Map, example, EX052.
flowchart TD
N0["Learning outcomes"]
N1["18.1 Layers"]
N2["18.2 Trust boundaries"]
N3["18.3 Pipeline architecture"]
N4["18.4 Signing"]
N5["18.5 Decisions"]
N6["18.6 Threat of the builder"]
N7["Network segmentation"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX052"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["18.1 Layers"]
N2["18.2 Trust boundaries"]
N3["18.3 Pipeline architecture"]
N4["18.4 Signing"]
N5["18.5 Decisions"]
N6["18.6 Threat of the builder"]
N7["Network segmentation"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX052"]
[Learning outcomes]
|
v
[18.1 Layers]
|
v
[18.2 Trust boundaries]
|
v
[18.3 Pipeline architecture]
|
v
[18.4 Signing]
|
v
[18.5 Decisions]
|
v
[18.6 Threat of the builder]
|
v
[Network segmentation]
|
v
[Worked example] --> [Exercise EX052]
Learning outcomes
You will (1) design layered security for a web application and pipeline; (2) apply trust boundaries and least privilege; (3) choose architectural controls for supply-chain integrity; (4) document architecture decisions.
18.1 Layers
Coastline's architecture has edge protection (a web application firewall and rate limits), the application (validation, authorisation, escaping), data (encryption, least privilege) and pipeline (reviewed source, isolated builds, signed artifacts, verified deployment).
Each layer stops a different kind of attack. The firewall and rate limits slow automated probing; the application layer handles malicious input; the data layer limits what a successful attack can read; the pipeline layer protects against attackers who try to change the code itself. An attacker who passes one layer still faces the others.
18.2 Trust boundaries
Boundaries separate zones of different trust: internet to web tier, web tier to database, CI to production. Every boundary has checks. Secrets for production are never available to pull-request builds from untrusted branches.
Pull requests from untrusted branches may contain code written by anyone, and CI runs that code during tests. If production secrets were available, a single malicious pull request could steal them. Separating the build that tests contributions from the build that produces releases keeps secrets out of reach, at the cost of maintaining two pipeline configurations.
18.3 Pipeline architecture
Source changes are reviewed; builds run on hosted, isolated runners; outputs are signed; provenance records who built what from which source; deployment verifies signature and provenance. This follows the SLSA v1.0 model of build provenance and in-toto's idea (Torres-Arias et al., 2019) of recording and checking each step.
Each step produces evidence that the next step checks, so trust is not assumed at any handover. If someone bypasses review, the provenance shows source that did not pass branch protection, and deployment refuses it.
18.4 Signing
Signing proves who published an artifact. Sigstore (Newman et al., 2022) offers signing with short-lived certificates tied to identities, avoiding long-lived keys that can leak.
A signature also proves the artifact has not changed since signing. Long-lived signing keys are attractive targets: if one leaks, an attacker can sign malware that looks legitimate until the key is revoked. Short-lived certificates tied to the CI identity limit that window, and a public transparency log records each signing so unexpected signatures can be spotted.
18.5 Decisions
Each choice has a decision record: options, trade-offs, chosen design.
A decision record captures the context at the time: what problem was being solved, which options were considered, what each would cost, and why one was chosen. Coastline's record for signing compares long-lived keys with short-lived certificates and notes that the second was chosen to remove key-storage risk. When the context changes, for example a new regulation, the team reads the record before reopening the debate, which avoids repeating old arguments. Records are short, often one page, and are stored next to the code they affect.
18.6 Threat of the builder
Thompson (1984) reminds architects that build tools themselves must be trusted; Coastline pins its build tools by digest and rebuilds them from known sources where possible.
Thompson showed that a compiler could be altered to insert a backdoor into programs it compiled, including new copies of itself, so the source would look clean. Pinning tools by digest means a changed tool is noticed. Reproducible builds help further, because independent rebuilds that produce the same output make a hidden insertion in one toolchain visible.
Network segmentation
Servers are placed in separate network segments for web, application, database and build. Firewall rules between segments allow only the flows in the data model. If one segment is compromised, the attacker cannot freely reach the others, and unexpected connections are logged.
Worked example
Kwame's architecture review shows that the staging environment shares a database account with production for reporting. The team splits the accounts, so a staging compromise cannot read production data.
Synthetic case. The architecture is synthetic.
Errors and limits
Architecture on paper may differ from reality; verify with configuration reviews.
Exercises
- EX052 — Pipeline steps. List the pipeline integrity steps. Rubric: 3 = review, isolated builds, signing, provenance, verified deployment; 2 = four; 1 = two; 0 = none.
- EX053 — Sigstore benefit. What does Sigstore avoid? Rubric: 3 = long-lived keys that can leak; 2 = partial; 1 = vague; 0 = none.
- EX054 — Staging finding. What did the review find and fix? Rubric: 3 = shared DB account; split; 2 = partial; 1 = vague; 0 = none.
Synthesis
Layer controls across application, data and pipeline, with checked trust boundaries.
Continue studying — chapter 18 of 50
← Chapter 17 (draft) · Course chapter index · Chapter 19 (draft) →