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

Security Fundamentals for Architecture as Code

The lesson establishes security as code. It covers the four dimensions of security in Architecture as Code, the shift from perimeter protection to Zero Trust Architecture, threat modelling with STRIDE applied to infrastructure and pipelines, continuous risk assessment, Policy as Code with shift-left enforcement, the secrets lifecycle, data classification, the protection of infrastructure state, micro-segmentation and service mesh security, and security maturity models.

Lesson 10 of 31Chapter 990 minutes

Read the chapterThe whitepaperThe slides

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

Learning objectives

After the lesson the participant can:

Key concepts

Zero Trust Architecture
Security thinking guided by the principle never trust, always verify: every user, device and network transaction is validated explicitly regardless of location or prior authentication. Declared in code, it yields what the chapter calls trust as code.
STRIDE for code-based architectures
A structured framework of six threat categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege. In Architecture as Code it must also cover infrastructure definitions, deployment pipelines, secrets management and runtime environments.
Continuous risk assessment
Risk evaluation embedded in the development life cycle through automated tooling and policy engines, so that every infrastructure change is assessed before deployment. Blast radius can be calculated automatically from dependency mapping.
Secrets lifecycle management
Management of secrets from generation through distribution, rotation and retirement, with automated generation, delivery through secure channels or runtime injection, and central storage encrypted in transit and at rest.
Micro-segmentation
Granular, application-aware network control in which traffic policies use application identity, user context and data classification, reducing opportunities for lateral movement compared with traditional VLANs or subnets.

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

STRIDE concerns in a code-based architecture

Sort each concern into the STRIDE category under which the chapter's table lists it.

Interactive exercise 2 · Match

Security building blocks

Match each technology to what the chapter says it contributes to security as code.

Teaching plan

15 minTeacher presents the four security dimensions and the paradigm shift from hard shell, soft centre to Zero Trust.
20 minWalk through the STRIDE table. For each category participants add one concern from their own delivery pipeline, and the teacher adds supply chain and insider threats.
15 minTeacher covers Policy as Code and shift-left enforcement, secrets, data classification, state protection and network segmentation.
30 minExercise in groups: a STRIDE threat model of a delivery pipeline, with countermeasures as code.
10 minGroups compare their highest-ranked threat. Close with the NIST Cybersecurity Framework 2.0 functions and the place of Govern.

Discussion

  1. The chapter argues that manual security reviews as gateways frustrate teams and delay releases. What has to be automated before a security team can credibly act as an enabler?
  2. Why does threat modelling for Architecture as Code have to include the CI/CD pipeline and the automation tooling as attack surfaces?
  3. Where does human judgement remain essential in data classification, according to the chapter, and how would you combine it with automated discovery?

Written exercise

Exercise · 30 minutes

A STRIDE threat model of a delivery pipeline

Take the pipeline that deploys infrastructure for one system in your own organisation. Draw its main elements: repository, pipeline runner, secrets store, state backend and target environment. For each of the six STRIDE categories identify at least one threat against these elements, using the concerns in the chapter's table as prompts, for example malicious commits to infrastructure code or secrets in repositories. Rank the threats and choose the three most serious. For each of the three, write one countermeasure as a declarative assertion that a pipeline or runtime monitor could check, and say what evidence the check would leave. This is a design exercise on your own systems only.

Deliverable: A threat table covering all six STRIDE categories and three countermeasures written as checkable assertions with the evidence each would produce.

Self-test

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

  1. Which guiding principle does the chapter give for Zero Trust Architecture?

    Show the answer

    B. Never trust, always verify
    Zero Trust Architecture is guided by never trust, always verify, requiring explicit validation of every user, device and network transaction regardless of location or prior authentication.

  2. In the chapter's STRIDE table, which concern is listed under Repudiation?

    Show the answer

    D. Missing version control history and untracked deployments
    Repudiation is denying actions without a proper audit trail; the listed concerns are missing version control history, inadequate logging of infrastructure changes and untracked deployments.

  3. Why does the chapter say infrastructure state files must be treated as sensitive artefacts?

    Show the answer

    A. They capture live inventories, secrets and enforced policy decisions
    State files capture live inventories, secrets and the policy decisions enforced across environments, so the baseline is a remote backend, locking during writes and restricted access.