Architecture as Code · Module 3 · Security, Governance & Assurance

Risk as Code and Threat Handling as Code

The lesson extends the repository to risk registers and threat playbooks. It covers why risk and threat handling belong in the codebase, risk definitions as declarative documents validated in CI, metrics as code, exceptions with expiry dates, threat intelligence ingestion, threat models generated from the codebase, response playbooks as state machines with four duties, continuous exercising through security chaos engineering, and the operating model with risk stewards.

Lesson 12 of 31Chapter 9C60 minutes

Read the chapterThe whitepaperThe slides

All courses / Architecture as Code / Module 3 / Chapter 9C

Learning objectives

After the lesson the participant can:

Key concepts

Risk as code
Risk definitions structured as declarative YAML or JSON documents that capture context, probability, impact and ownership. The schema is a contract that tooling validates in pull requests, rejecting missing data, outdated review dates or invalid owners.
Time-bound exception
An exception that is itself a code artefact with an explicit expiry date and approval chain. Deployments may proceed only when every high or critical risk is mitigated by automated controls or covered by such an exception.
Playbook as a state machine
Incident response expressed as a workflow in which each state is a containment or eradication step with guard conditions, rollback logic and evidence capture. A playbook should subscribe to signals, assess risk ratings, act and document.
Security chaos engineering
Automated scenarios that inject simulated breaches or infrastructure failures on a schedule or after configuration changes, validating that playbooks execute correctly. Findings become backlog items captured as code changes.
Risk steward
A product-aligned owner who approves updates to risk artefacts through code reviews, so that accountability remains close to the delivery teams.

Interactive exercises

Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.

Interactive exercise 1 · Sort

Risk and threat handling in the delivery pipeline

Sort each activity into the part of the delivery pipeline where the chapter integrates it.

Interactive exercise 2 · Scenario

A critical risk and a release date

Read the situation and choose what the chapter's reasoning leads to. Each choice gives feedback.

Teaching plan

10 minTeacher presents why risk management as paperwork fails and the four benefits of the codebase: traceability, consistency, speed and learning loops.
15 minRead the example risk document and discuss which fields a CI check should reject. Teacher explains metrics as code and exceptions.
10 minTeacher explains threat handling: structured intelligence ingestion, generated threat models, playbooks and chaos drills.
20 minExercise in pairs: write a risk definition and the playbook that responds to it.
5 minClose on culture: celebrate the remediation pull request, not only the discovery.

Discussion

  1. The chapter says automated pipelines remove subjective scoring from risk evaluation. What judgement remains with the people who write the risk definitions?
  2. What would change in your organisation if a failing control metric failed the pipeline and forced remediation before release?
  3. How would you keep exceptions from becoming permanent once they are written as code with expiry dates?

Written exercise

Exercise · 20 minutes

A risk definition and its response playbook

Choose one real resilience or security risk for a system in your own organisation. Write it as a structured risk definition with an identifier, category, context, probability, impact, owner, the controls that mitigate it, the metric that shows the control is healthy and a review date. State which missing or stale fields should make a CI check reject the document. Then describe the response playbook for this risk as a state machine: the signal it subscribes to, how it assesses the rating from the risk catalogue, the action it takes (for example revoking credentials or isolating a workload), its rollback logic, and what it documents. Name one chaos drill that would exercise the playbook.

Deliverable: One risk definition in structured form with validation rules, a four-state playbook description, and one drill scenario.

Self-test

Choose an answer to see whether it is right, or open the answer below each question.

  1. Under the governance logic the chapter gives as an example, when may a deployment proceed?

    Show the answer

    C. When every high or critical risk is mitigated automatically or has a time-bound exception
    The example policy allows deployments only when every high or critical risk is either mitigated by automated controls or accompanied by a time-bound exception with expiry and approval chain.

  2. Which four duties should a response playbook fulfil, in the chapter's order?

    Show the answer

    A. Subscribe, assess, act, document
    Playbooks should subscribe to signals, assess risk ratings by referencing the risk-as-code repository, act by triggering infrastructure changes, and document activities in immutable logs and tickets.

  3. In what structured formats does the chapter say threat intelligence feeds should be ingested?

    Show the answer

    B. STIX and TAXII
    Threat handling begins by ingesting intelligence in STIX and TAXII, the OASIS standards for describing and exchanging cyber threat intelligence.