Evidence as Code and Continuous Assurance · Architecture as Code: the course

All courses / Architecture as Code / Module 3 / Chapter 15A

Learning objectives

After the lesson the participant can:

Describe the four characteristics of machine-generated evidence and why deterministic capture is preferable to manual attestation.
Design a pipeline job that produces, packages and publishes an evidence bundle with framework metadata.
Explain what a software bill of materials and a provenance attestation each prove.
Plan the lifecycle of an evidence artefact from capture to expiry.

Key concepts

Evidence as Code: The artefacts that prove compliance are generated automatically, stored alongside the controls they verify and versioned so that their provenance is unquestionable. The chapter calls evidence the currency that lets Architecture as Code demonstrate trustworthiness at scale.
Deterministic capture: Evidence is generated from automated checks, not manual screenshots. Together with traceability to commits and pull requests, reusability through framework metadata and version control, it is one of the four key characteristics.
Evidence manifest: A file produced by the pipeline job that links evidence artefacts to control identifiers and framework mappings. Governance and compliance teams consume it instead of requesting bespoke proof.
Software Bill of Materials: A machine-readable inventory of every component, library and dependency in a software artefact, produced for example in CycloneDX or SPDX format. The chapter notes that the EU Cyber Resilience Act, Regulation (EU) 2024/2847, increasingly requires producers to generate one.
SLSA provenance attestation: A signed record of the build platform, the external parameters that defined the build, the resolved dependencies and the output digests, letting consumers verify an artefact's build chain without trusting the producer's word alone.

Interactive exercises

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

Interactive exercise 1 · Match

Tools and steps in the evidence pipeline

Match each tool or pipeline step to what it does in the chapter.

Interactive exercise 2 · Put in order

The life of an evidence artefact

Put the stages of the evidence lifecycle in order, from the pipeline step to the end of retention.

Teaching plan

10 min	Teacher introduces evidence as currency and the four characteristics, contrasting them with screenshots collected at audit season.
15 min	Walk through the MFA pipeline example: the test step that gates the job, the evaluation step that produces the evidence, and the manifest with its mappings.
15 min	Teacher explains the bill of materials, vulnerability reports as evidence, provenance, image signing and admission control that admits only signed images.
30 min	Exercise: design an evidence bundle and its lifecycle for one control.
5 min	Close on the structural shift: compliance as a continuous by-product of delivery.

Discussion

The pipeline example separates the step that tests the policy from the step that produces the evidence. Why does that separation matter to an auditor?
Evidence value erodes if consumers cannot verify how it was produced. Who are the consumers of your evidence, and what would each need to verify?
What are the risks of keeping evidence too briefly and of keeping it without limit, and who should decide the retention period?

Written exercise

Exercise · 30 minutes

An evidence bundle and its lifecycle

Choose one control in your own organisation that a pipeline could verify, for example multi-factor authentication for human identities or image signing. Design the pipeline job that proves it: the inputs it reads, the check that gates the job, the evaluation that produces the evidence, and the files it writes. Draft the evidence manifest in outline: control identifier, artefact paths, commit reference, environment, timestamp and the frameworks the evidence supports. Then complete a lifecycle table for the bundle with the chapter's stages: capture, packaging, storage, indexing, retrieval, expiry and access control. For each stage state the activity and who may write, read and delete.

Deliverable: A job design, a manifest outline with the listed fields, and a seven-row lifecycle table with access rules for the evidence store.

Your work

Self-test

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

Which of these is one of the four key characteristics of Evidence as Code in the chapter?
Show the answer
C. Deterministic capture from automated checks
The characteristics are deterministic capture, traceability, reusability and version control. Evidence is generated from automated checks, not manual screenshots, and kept alongside policies and blueprints.
What does a SLSA provenance attestation record?
Show the answer
D. Build platform, external parameters, resolved dependencies and output digests
A SLSA provenance attestation records the build platform, the external parameters that defined the build, the resolved dependencies and the output digests, signed by the build platform's identity.
In the evidence lifecycle table, what happens at the indexing stage?
Show the answer
B. The manifest is registered in an evidence catalogue for audit queries
At indexing, the manifest is registered in an evidence catalogue so that auditors or tools can later query by control identifier or framework. Capture and expiry are separate stages.