◇ OpenCyber Academy
Engineering · Chapter 14 · English

Chapter 14 — Software engineering

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 14 — Software engineering

Lesson map

Lesson 14 published. Map, example, EX027.

flowchart TD
  N0["Learning outcomes"]
  N1["14.1 Lifecycle"]
  N2["14.2 Review"]
  N3["14.3 SBOM and CBOM"]
  N4["14.4 Staged releases"]
  N5["Engineering note"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX027"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["14.1 Lifecycle"]
  N2["14.2 Review"]
  N3["14.3 SBOM and CBOM"]
  N4["14.4 Staged releases"]
  N5["Engineering note"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX027"]

[Learning outcomes]
    |
    v
[14.1 Lifecycle]
    |
    v
[14.2 Review]
    |
    v
[14.3 SBOM and CBOM]
    |
    v
[14.4 Staged releases]
    |
    v
[Engineering note]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX027]

Learning outcomes

You will (1) manage requirements, design, implementation and testing in a migration project; (2) use version control and code review for cryptographic changes; (3) build a software bill of materials (SBOM) and a cryptographic bill of materials (CBOM); and (4) plan staged releases. It builds on Chapters 4 and 9 and prepares implementation (Chapter 28).

14.1 Lifecycle

A migration is a software project: requirements (which functions must become quantum-resistant, by when), design (hybrid or pure PQC, which libraries), implementation, testing, staged release and maintenance. Cryptographic changes are high-impact and low-visibility: if wrong, they fail silently or catastrophically.

Silent failure is the more dangerous of the two: a service that quietly falls back to classical key exchange looks healthy while recording continues to expose its traffic. For that reason BPA's requirements state measurable outcomes, such as the negotiated group logged per session, so testing can show the change actually took effect.

14.2 Review

Every cryptographic change gets review by someone with cryptographic knowledge, plus tests for interoperability. Checklists ask: are algorithm identifiers from policy? Are lengths validated? Are comparisons constant-time? Is the library version pinned and supported?

BPA keeps a small pool of reviewers who have completed cryptographic training, and every change touching the Signer or KEM interfaces requires one of them. The checklist is stored with the code, and each item maps to an automated test where possible, for example a test that fails when a key length is accepted without validation. Reviewers then spend their time on design questions that tests cannot answer.

14.3 SBOM and CBOM

An SBOM lists components and versions. A CBOM extends this to cryptographic assets: algorithms, parameter sets, key lengths, protocols, certificates and where keys live. Formats such as CycloneDX support CBOM fields. A CBOM is the basis for answering "where do we use RSA?" in minutes rather than months.

BPA generates the CBOM in the build pipeline, so every release carries a fresh inventory. A query for RSA across all CBOMs, filtered to keys with lifetimes over ten years, produced the first work items for signature migration.

14.4 Staged releases

Use feature flags for algorithm choices, canary deployments with measured failure rates (Chapter 37) and rollback plans. Keep both old and new algorithms available during transition.

A flag lets the team turn the hybrid group off for one path in minutes, as in the shipping-line portal case, without redeploying code. The canary step size starts small, such as 1% of traffic, and grows only after the failure bound from the rule of three falls under the agreed budget. Each step's data is kept, so a later incident can be compared against the baseline from the rollout.

14.5 Worked example

BPA's portal team adds hybrid TLS behind a flag, runs interoperability tests against the top 50 partner clients, deploys to 1% of traffic, monitors failures and promotes in steps. The CBOM is updated automatically from build metadata so the inventory stays current.

Choosing the top 50 partner clients covers most of the portal's traffic, so a fault there would show up quickly in the canary. Each promotion step needs a minimum number of connections without failure, which the team computes before rollout. The automated CBOM update meant the security office could report the change to the board the same week it reached full traffic.

14.6 Common errors and limits

Merges without review have shipped draft-era Kyber code into production in other organizations; BPA's rule that interface changes need a trained reviewer prevents that. Hand-made CBOMs are out of date within a release cycle, so the build generates them. Big-bang releases remove the chance to catch the middlebox faults that canaries find at 1% of traffic, and they make rollback an all-or-nothing choice.

Engineering note

Treat the CBOM as a living artefact owned by a named team, generated from build pipelines, configuration management and telemetry rather than spreadsheets. Each release should diff its CBOM against the previous one: a new RSA dependency introduced by a library upgrade is a regression to catch in review, exactly like a failing test. Teams that wire this diff into continuous integration discover quantum-vulnerable additions within days instead of during the next annual audit, and they also gain an accurate list for vendor questionnaires and regulators.

Exercises

Synthesis

Treat migration as software engineering: reviewed changes, flags, canaries, rollback and an automatically maintained CBOM.

Continue studying — chapter 14 of 50

← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →