Policy, Pipeline and Evidence Tools

This chapter serves one activity: turning a rule into a check that runs on every change, and turning the result of that check into evidence that someone else can verify. It treats four kinds of tool. The artefacts are the policies, workflows, manifests and records that the earlier volumes define. The own tools are a handful of workflows in the repositories of the series. The third-party tools are the policy engines, scanners, pipeline platforms, signing and attestation systems and bill-of-materials formats that the volumes name. The methods are the named procedures for testing policies, for gating a change and for managing evidence over its life. The tools come mainly from Architecture as Code (Chapters 5, 10, 11, 13 and 15A) (1, Nordqvist, 2025), which built the pipeline and evidence pattern; from AI Governance, Chapters 9 and 11, and AI Platform and Security, Chapters 7, 8, 16, 17 and 20, which carry it to models, prompts and agents (2, Nordqvist, 2026) (3, Nordqvist, 2026); from AI Red Team, Chapter 16, and The Transformed Security Architect, Chapters 5 and 6, which write policy for security AI and for architecture (4, Nordqvist, 2026) (6, Nordqvist, 2026); from AI Purple, Chapter 11, which makes evidence expire (9, Nordqvist, 2026); and from AI Operations, Chapters 8 and 18, which puts a policy decision point in the path of a change and a policy around the engine that applies it (10, Nordqvist, 2026).

The chapter is a reference. It does not repeat the arguments of the volumes; it says what each tool is for, what it needs and produces, and which chapter holds the reasoning. Where a template is quoted, it is quoted from the volume named, with whole fields removed and nothing else changed. Third-party software is described only as the series uses it and from the documentation cited in the bibliography of this book; the earlier volumes are the source for what the series does with a tool, never for what the software does.

The chain in one view

The tools in this chapter form one chain, drawn in Figure 5.1. Policies, tests and records sit in version control. An artefact or a change enters the pipeline, tests and scanners produce results, and a policy decision point evaluates the results against the policy bundle and returns allow or deny with reasons. In parallel the build produces a bill of materials and a provenance attestation, and a signing step binds the artefact to an identity. A named human approves only the classes that the policy names. Every stage leaves an artefact, and an evidence manifest binds the artefacts to the obligations and controls they satisfy. The manifest goes to an append-only store, and an evidence pack is generated from the store by query, for an auditor, a supervisor or a customer.

Figure 5.1: The policy, pipeline and evidence chain. The policy decision point sits outside the author of the change, and the evidence store is written by the pipeline, not by the people whose work it records.

Two properties recur in every family below, and they are the series' conclusions rather than features of any one product. The policy decision point is not controlled by the author of the change: AI Operations, Chapter 8, evaluates the diff and the plan with a rule the author cannot edit, because a check that depends on the author's good faith is a convention (10, Nordqvist, 2026). And the signature belongs to the pipeline run: AI Governance, Chapter 11, signs inside the pipeline with an identity bound to the run, not with a key an engineer holds (2, Nordqvist, 2026).

Policy engines and the policy language

Policy as code means that a rule is written once, tested like software and evaluated wherever a decision is needed: in a pull request, in a pipeline, at a gateway, in a cluster. The series standardises on one engine and one language, and treats the Kubernetes-native engines and the vendor engines as alternatives for particular places. The family has five parts: the engine and language, the tools that apply them to configuration files, the admission controllers that apply them in a cluster, the scanners that ship with their own rules, and the methods for testing policy.

Open Policy Agent and Rego

Kind	Third-party tool (open-source policy engine and its policy language)
Origin	Architecture as Code (Chapters 2, 5, 7 to 11, 13, 15A, 22, 26B and Appendix A); AI Governance, Chapters 8 and 9; AI Platform and Security, Chapters 4, 8, 11 and 17; AI Red Team, Chapters 3 and 16; The Transformed Security Architect, Chapters 3, 5, 6, 9, 13, 17 and 21; AI Operations, Chapters 8 and 18
Purpose	Evaluates structured input against policies written in Rego and returns a decision, for infrastructure, Kubernetes, governance, gateways, pipelines and agent authorisation
Inputs	A policy bundle (Rego modules and data) and a JSON document: a configuration file, a Terraform plan, a model card, an architecture export, a change record
Outputs	A decision (allow, or a set of deny reasons) that the caller enforces and records
Identifier family	Rego package names, for example ai.governance.model_approval, architecture.zones, threatmodel.gate, change.gate

Open Policy Agent (OPA) is documented by its project (51, Open Policy Agent, n.d.), and Rego is its declarative language for rules over structured data (101, Open Policy Agent, n.d.). Architecture as Code (Chapter 10) gives the operating pattern that the later volumes inherit: decoupled evaluation, so that the engine runs as a sidecar, an admission controller or a command-line verifier apart from the application; distribution of signed policy bundles; and packaging of policies, data, metadata and signatures together so that a change in requirements rolls out and back atomically (1, Nordqvist, 2025). The same engine then serves AI Governance for risk classification, approval and deployment policies, AI Platform and Security for gateways, pipelines and agent authorisation, and AI Operations for policy decision points outside the agent platform and for checks on infrastructure plans (2, Nordqvist, 2026) (3, Nordqvist, 2026) (10, Nordqvist, 2026).

The infrastructure pattern is the one the OPA documentation describes for Terraform: produce a plan, convert it to JSON and evaluate it against Rego to give an allow or deny decision (182, Open Policy Agent, n.d.). Two limits matter. A policy that evaluates a plan cannot see what the plan does not contain, so AI Operations, Chapter 8, adds a check of the resulting state after release by something other than the pipeline (10, Nordqvist, 2026). And a Rego policy is code: Architecture as Code (Chapter 11) tests it, as the methods below show. The inventory records the engine under four spellings across the volumes ("Open Policy Agent (OPA) and Rego", "Open Policy Agent / Rego", "Open Policy Agent and Rego", "Rego"); they are one tool, and this entry treats them together.

Conftest

Kind	Third-party tool
Origin	Architecture as Code (Chapters 2, 5, 8 and 21); The Transformed Security Architect, Chapter 5
Purpose	Runs OPA policies against structured configuration files in a pipeline
Inputs	Configuration files and a directory of Rego policies
Outputs	A pass or fail result for the pipeline step

The Conftest documentation describes a utility for writing tests against structured configuration data such as Kubernetes configurations or Terraform code (259, Conftest Authors, n.d.). Architecture as Code (Chapter 5) installs Conftest in its pipeline and runs conftest test separately against application, data and security definitions, each with its own policy file, and then conftest verify to run the Rego unit tests that accompany the policy bundle (1, Nordqvist, 2025). The Transformed Security Architect (Chapter 5) uses it to test the structured export of an architecture workspace (6, Nordqvist, 2026). Both volumes mention it in passing; nothing further is claimed about it beyond what the project documentation cited above states.

OPA Gatekeeper constraint blocking privileged containers

Kind	Artefact (a Kubernetes constraint)
Origin	Architecture as Code, Chapter 7
Purpose	Instantiates the Gatekeeper K8sPSPPrivilegedContainer constraint template so that the cluster refuses privileged containers
Inputs	The constraint template from the Gatekeeper policy library, which must be installed first
Outputs	An admission decision at the cluster
Full template	Architecture as Code, Chapter 7, "Guard rails that keep manifests trustworthy"

The Gatekeeper documentation describes a validating and mutating admission webhook that enforces policies defined as custom resources and executed by Open Policy Agent (265, Gatekeeper Authors, n.d.). The constraint is a few lines of YAML that match Pod objects and set parameters; the logic lives in the template. It appears beside an Argo CD application manifest to show the "as Code" framing: the cluster's refusal is a file reviewed in a pull request (1, Nordqvist, 2025). OPA Gatekeeper itself is the Kubernetes admission control built on OPA constraints (Chapters 7, 10 and 13 of that volume).

Testing policies with opa test

Kind	Method
Origin	Architecture as Code, Chapters 11 and 13
Purpose	Unit-tests Rego policies in CI so that a change to a policy is itself governed
Inputs	The policy and Rego test rules with example inputs, one per failure reason
Outputs	A pass or fail result per test; a failing test stops the pipeline
Full template	Architecture as Code, Chapter 11, "Testing policies with OPA's built-in test runner"; Appendix A, 13_CODE_J

The method is to write, for each deny reason, a test that supplies an input that should trigger it, and to run opa test policies/ in CI, which catches policy regressions before they reach production and applies the quality discipline of application code to governance code (1, Nordqvist, 2025). AI Governance, Chapter 9, adds a rule that the later volumes keep: fixtures for each risk tier and each failure reason (2, Nordqvist, 2026). The Appendix A artefact "Policy-as-Code testing with OPA" (13_CODE_J) is the worked version, a security.rego with its unit tests covering storage encryption, security-group requirements and data classification. The wider Policy as Code operating model (Architecture as Code, Chapters 10 and 11) is the method that surrounds it: policies are authored, tested and enforced in pipelines, and share one set of data with threat modelling, risk assessment and compliance automation.

Other engines and scanners

The volumes name further policy tools without giving them a template. The table records what each is said to do.

Tool	Kind	Origin	What the series uses it for
Kyverno	Third-party tool	Architecture as Code, Chapters 7 and 13	Kubernetes policy engine; its documentation calls it a cloud native policy engine (260, Kyverno Authors, n.d.)
Kubernetes Validating Admission Policy	Third-party tool	AI Operations, Chapter 18	In-cluster admission policy used as a gate in front of state engines (158, The Kubernetes Authors, n.d.)
HashiCorp Sentinel	Third-party tool	Architecture as Code, Chapters 9, 9C, 10 and 11	Policy-as-code tool for HashiCorp products; mentioned in passing
Checkov	Third-party tool	Architecture as Code, Chapters 5, 13, 16, 21 and Appendix A	Static analysis of infrastructure as code against policies; its documentation describes a static code analysis tool that scans infrastructure as code files for misconfigurations (261, Checkov, n.d.)
Trivy	Third-party tool	Architecture as Code, Chapters 5, 16, 21 and Appendix A; AI Platform and Security, Chapter 9	Scanner for infrastructure code and images; its project describes a security scanner whose scanners include vulnerabilities, IaC misconfigurations, secrets and licences (262, Aqua Security, n.d.)
tfsec	Third-party tool	Architecture as Code, Chapters 5 and 21	Terraform static analysis, now being consolidated into Trivy; the tfsec project itself asks its community to move to Trivy (267, Aqua Security, n.d.); not a base for a new pipeline
TFLint	Third-party tool	Architecture as Code, Chapter 5	Terraform linter
kubeconform / kubeval	Third-party tool	Architecture as Code, Chapter 7	Schema validation of Kubernetes manifests
jq	Third-party tool	Architecture as Code, Chapters 5, 15A and 16	JSON processing in evidence and migration scripts

One entry in the table carries a warning that is the series' own. AI Platform and Security, Chapter 9, records that Trivy was compromised in a 2026 incident, and the National Vulnerability Database carries an entry for the compromise of one Trivy release (189, NVD, 2026). Architecture as Code lists Trivy as a scanner to rely on. The two statements are compatible, and the conclusion is the book's own: a scanner in a pipeline is itself a supply-chain dependency, so it is pinned, verified and counted in the bill of materials like any other component.

Policies that gate a change

The artefacts below are policies written for a specific decision. They share a shape: an input document, a set of deny reasons, a default of refusal and a record of the decision. Where the volume gives a full template, the entry quotes it.

Model approval policy

Kind	Artefact (Rego policy)
Origin	AI Governance, Chapter 9
Purpose	Approves a model version only if its model card is complete, its evaluation meets the thresholds of its risk tier, its licence is allowed, its provenance attestation verifies and its register entry is within appetite
Inputs	The model card, the evaluation report, the attestation and the register entry
Outputs	allow, or a set of deny reasons; a record of input, decision, reasons, policy version and commit
Identifier family	Package ai.governance.model_approval
Full template	AI Governance, Chapter 9, "Policy as code for approval, data use, and deployment"

The policy is the model for the others in this section. The thresholds are data keyed by risk tier and change through a reviewed commit; the policy has fixtures for each tier and reason; every evaluation leaves a record that Chapter 11 of that volume assembles into evidence (2, Nordqvist, 2026). It is quoted in full.

package ai.governance.model_approval

import rego.v1

default allow := false

thresholds := {
    "high": {"accuracy": 0.90, "max_subgroup_gap": 0.03},
    "limited": {"accuracy": 0.85, "max_subgroup_gap": 0.05},
    "minimal": {"accuracy": 0.80, "max_subgroup_gap": 0.10},
}

card_complete if {
    every field in {"intended_purpose", "training_data", "evaluation", "limitations", "owner", "risk_tier"} {
        input.model_card[field]
    }
}

meets_thresholds if {
    t := thresholds[input.model_card.risk_tier]
    input.evaluation.accuracy >= t.accuracy
    input.evaluation.subgroup_gap <= t.max_subgroup_gap
}

provenance_verified if input.attestation.slsa_level >= 2

register_in_appetite if input.register.status == "accepted_within_appetite"

allow if {
    card_complete
    meets_thresholds
    input.model_card.licence in data.allowed_licences
    provenance_verified
    register_in_appetite
}

deny contains "Model card incomplete" if not card_complete
deny contains "Evaluation below tier thresholds" if not meets_thresholds
deny contains "Provenance attestation missing or weak" if not provenance_verified
deny contains "Risk register entry not within appetite" if not register_in_appetite

Secure-configuration baseline policy (Rego)

Kind	Artefact (Rego policy)
Origin	AI Red Team, Chapter 16
Purpose	Detects drift from a security-AI configuration baseline and decides what reverts automatically
Inputs	A workload description: route, egress default, processing region, models and whether each model's signature was verified
Outputs	A set of deny messages; the same policy blocks a non-compliant deployment in the pipeline and detects drift in the running estate
Identifier family	Package secai_baseline (here hansa.platform.secai_baseline)
Full template	AI Red Team, Chapter 16, "Secure configuration with AI"

AI Red Team names the language Rego without naming OPA in the chapter text. The policy is quoted in the worked example at the end of this chapter, because it contains the gate that rejects an unsigned model artefact.

Rego zone-crossing rule

Kind	Artefact (Rego policy)
Origin	The Transformed Security Architect, Chapter 5
Purpose	Fails a pull request when a relationship in the architecture model crosses a trust zone without a named policy point
Inputs	A flattened export of an architecture workspace: elements with properties and tags, and relationships
Outputs	Deny messages naming the element without a zone, the crossing without a policy point, or the Mode 5 agent without an identity of its own
Identifier family	Package architecture.zones

The rule turns a diagram convention into a merge condition. It is the architecture counterpart of the infrastructure policies above, and it shares their weakness: it can only check what the export contains (6, Nordqvist, 2026). The tools that produce the workspace are Chapter 4 of this book.

Threat-model pipeline gate

Kind	Artefact (Rego policy)
Origin	The Transformed Security Architect, Chapter 6
Purpose	Fails a merge when a threat has no control and no risk acceptance, a control is not defined in the pinned catalogue, a control has no owner, or a candidate has no reviewer decision
Inputs	threat-model.yaml parsed to JSON, the date and the boundaries changed in the pull request
Outputs	Deny messages; the CI job fails when deny is not empty
Identifier family	Package threatmodel.gate

The gate belongs with the threat-modelling tools of Chapter 10 of this book; it is listed here because the mechanism is the same as every gate in this section (6, Nordqvist, 2026).

Change gate policy

Kind	Artefact (Rego policy; marked illustrative in the volume)
Origin	AI Operations, Chapter 8 and Appendix A.4
Purpose	Computes the change class from the plan, requires an independent named approver for agent-authored change and refuses release outside the window
Inputs	The plan (resource changes), the change record (declared class, author, approvers, rollback), the release window
Outputs	allow when no deny reason holds; deny reasons otherwise
Identifier family	Package change.gate; change records CHG-NR-*, CHG-HM-*; change classes such as HM-STD-002
Full template	AI Operations, Appendix A.4

The gate encodes four rules that the volume argues for: the class is computed from the diff and the author's declaration is a claim; an agent-authored change needs a human approver who is neither the requester nor the author; a release outside the authorised window is refused; and a change with no tested rollback is refused. The book states that the artefact must never carry a declared class that overrides the computed class, an agent as its own approver, typed prompts (references only) or a claim of recoverability the change does not evidence (10, Nordqvist, 2026).

package change.gate

import rego.v1

default allow := false

sensitive_types := {"kubernetes_cluster_role_binding", "vault_policy", "backup_target"}

destroys contains rc.address if {
    some rc in input.plan.resource_changes
    "delete" in rc.change.actions
}

sensitive contains rc.address if {
    some rc in input.plan.resource_changes
    rc.type in sensitive_types
}

# The class is computed from the diff; the author's declaration is a claim.
is_standard if {
    count(destroys) == 0
    count(sensitive) == 0
    input.change.catalogue_match
}

human_approvers contains a.id if {
    some a in input.change.approvers
    a.kind == "person"
    a.id != input.change.requested_by
    a.id != input.change.author.id
}

deny contains "declared class is lower than computed class" if {
    input.change.declared_class == "standard"
    not is_standard
}

deny contains "agent-authored change has no independent human approver" if {
    input.change.author.kind == "agent"
    count(human_approvers) == 0
}

deny contains "release is outside the authorised window" if {
    not input.release.window_open
}

deny contains "no tested rollback plan" if {
    not input.change.rollback.tested_on
}

allow if count(deny) == 0

Two methods accompany the gate. Policy as code in the change path (AI Operations, Chapter 8) names five groups of checks: schema, policy on the plan, blast radius computed from the service records, supply chain, and window and freeze. Provenance record for changes (AI Operations, Chapter 8) records for each change the author and whether it is a person or an agent; for an agent the identity, the mandate and level, the model and version, the skills and instructions loaded, the inputs by reference, the tools called and the tests run; and, for every change, what was not tested. The distinction the volume draws is worth keeping: build provenance says what produced an artefact, change provenance says who or what wrote the diff and under what authority, and a mature pipeline holds both (10, Nordqvist, 2026).

Reconciler sync policy and its review checklist

Kind	Artefact (Argo CD project, ApplicationSet and sync policy; Flux design for Nordvik Region)
Origin	AI Operations, Chapter 8, Appendix A.21 and Appendix B.6
Purpose	Confines a state engine (repositories, destinations, roles, sync windows) and sets what it may do on its own
Inputs	The repositories and destinations of one service, the release windows and the freeze calendar
Outputs	An Argo CD AppProject, an ApplicationSet generating one application per cell, and sync options; a stop for a cell is a change to the ApplicationSet or to the project's windows
Full template	AI Operations, Appendix A.21

The project defines roles and sync windows (190, Argo Project, n.d.) (163, Argo Project, n.d.) and the application's automated sync policy sets prune and self-heal (162, Argo Project, n.d.). The annotation keys in the example are the book's convention, and the volume says so. The book states that the artefact must never contain a prune or self-heal setting on a class that is not catalogued, a Tier 1 application without an allow window, an agent identity with the right to sync, or a reconciler credential broader than its project's destinations (10, Nordqvist, 2026).

The Sync-policy review checklist (Appendix B.21) has eleven points and is run by the service owner, the platform owner and a reviewer outside the reconciler's line before automated sync, self-heal or prune is enabled, and again at each change of the engine's major or minor line. Its points cover the change record naming the reconciler; automated sync limited to catalogued standard classes; self-heal and prune; an allow window for every application; owners and expiry for ignore rules; narrowed credentials; a retry limit; verification by a probe the reconciler does not control; a stop path held by named people and drilled within 90 days; and a supported engine line.

Policy records that other chapters treat

The inventory assigns to this chapter a number of declarative policy records that a gateway, a platform or a person evaluates rather than a pipeline. They are named here so that the reader who looks for "the policy for X" in this chapter finds the pointer; the entry, the template and the use are in the chapter cited.

Policy record	Origin	One-line purpose	Treated in
Model-origin policy	AI Governance, Chapter 6	Policy by data class and use case, evaluated by the intake pipeline and the AI gateway	Chapter 9
Principle set with executable verifications	AI Governance, Chapter 4	Principles declared as a PrincipleSet, each with a verification	Chapter 4
Mode baseline as platform policy	AI Platform and Security, Chapter 2	Minimum platform controls per usage mode	Chapter 6
Placement policy	AI Platform and Security, Chapter 14	Intake-time rules placing a workload in cloud, European cloud, hybrid or on premises	Chapter 6
AI gateway route and policy configuration	AI Platform and Security, Chapter 12	Per-system route with model access, guardrails and logging	Chapter 6
Agent routing policy	AI Platform and Security, Chapter 15	Routes coding-agent requests by information class and jurisdiction	Chapter 6
Guardrail policy (two volumes)	AI Platform and Security, Chapter 16; AI Red Team, Chapter 16	Declarative guardrails at the gateway; layered guardrails for a security AI capability	Chapter 20
Human-approval policy	AI Platform and Security, Chapter 11	Which agent actions need which human approval	Chapter 18
Model routing policy	AI Platform and Security, Chapter 22	Tiered model routing with budgets	Chapter 17
Patch-velocity policy (two volumes)	AI Platform and Security, Chapter 18; AI Red Team, Chapter 11	Service levels for patching by exploitability tier or exposure	Chapter 12
Predetermined change envelope	AI Platform and Security, Chapter 7	The range of model changes permitted without new approval	Chapter 16
Closure policy; Analyst AI-use policy	AI Blue, Chapters 7 and 12	Which alert classes AI may close; what the analysts' own AI use may touch	Chapter 12
Decision tier policy; decision-rights RACI	The Transformed Security Architect, Chapters 17 and 16	Which decisions are gated, delegated or taken by the design authority	Chapter 21

Pipelines and testing

A pipeline is the place where the policies above run and where their results are produced as artefacts. The series uses GitHub Actions for most examples and shows the other platforms once. The tests that run in the pipeline fall into three groups: tests of infrastructure code, tests of AI systems, and the pipeline's own monitoring.

GDPR-compliant CI/CD pipeline (GitHub Actions workflow)

Kind	Artefact (workflow)
Origin	Architecture as Code, Chapter 5 and Appendix A (05_CODE_1)
Purpose	Runs a compliance check on every change to infrastructure or module paths before the rest of the pipeline proceeds
Inputs	Repository paths infrastructure/ and modules/; environment settings for data residency and audit logging
Outputs	A pass or a failed job
Identifier family	05_CODE_*
Full template	Architecture as Code, Appendix A, "CI/CD pipelines"

The workflow triggers on pushes and pull requests that touch the infrastructure paths, sets the environment (data residency EU, audit logging enabled) and runs a GDPR data-discovery scan that searches the code for patterns that indicate personal data and fails when it finds one. The volume is explicit about the limit: the pattern scan is not a reliable compliance signal and is meant to be complemented by dedicated policy tools, Checkov, Trivy and Conftest, as required gates (1, Nordqvist, 2025). The sensible reading of the artefact is as the skeleton of a gate, not as the gate. A Jenkins variant (05_CODE_2) exists in the same appendix.

Pipeline platforms

Platform	Origin	What the series uses it for
GitHub Actions	Architecture as Code, Chapters 5, 6, 11, 13, 14, 15A, 19, 20, B and A; AI Platform and Security, Chapter 9 and Appendix A	The workflow engine for most pipeline examples (183, GitHub Docs, n.d.)
GitLab CI	Architecture as Code, Chapters 5 and 6	GitLab pipelines, with a Structurizr example (184, GitLab, n.d.)
Jenkins	Architecture as Code, Chapters 5 and 13 and Appendix A	Pipeline server, with a GDPR example (185, Jenkins, n.d.)
Azure Pipelines / Azure DevOps	Architecture as Code, Chapters 5 and 13	Microsoft's pipeline service with approvals and checks, mentioned in passing (186, Microsoft, n.d.)

The platform is a choice the practitioner makes once; the gates, the policies and the evidence are what the series asks to be portable.

Infrastructure tests

Tool	Kind	Origin	Purpose
Terratest	Third-party tool	Architecture as Code, Chapters 5, 11, 13, 14 and Appendix A	Go library for infrastructure tests (187, Gruntwork, n.d.)
Terratest for VPC implementation (05_CODE_3)	Artefact	Architecture as Code, Appendix A	Go test suite for a VPC module
Vitest	Third-party tool	Architecture as Code, Chapter 13 and Appendix A	Test runner for infrastructure code written in TypeScript
Vitest configuration for IaC projects (13_CODE_A)	Artefact	Architecture as Code, Appendix A	Configuration for testing infrastructure code
GitHub Actions Vitest workflow (13_CODE_F)	Artefact	Architecture as Code, Appendix A	Workflow that runs the Vitest suite in CI
Infrastructure testing pipeline (13_CODE_L)	Artefact	Architecture as Code, Appendix A	GitHub Actions pipeline for infrastructure testing
Comprehensive test framework for Architecture as Code (24_CODE_1)	Artefact	Architecture as Code, Appendix A	Python framework for testing infrastructure code
Pipeline monitoring ConfigMap (monitoring/pipeline-monitoring.yaml)	Artefact	Architecture as Code, Chapter 5	Monitoring configuration for the pipelines, with GDPR and euro cost tracking

These are the series' infrastructure-testing artefacts. They are written for Terraform-style and TypeScript-based infrastructure; the volume gives the full code in Appendix A. They are the first evidence that a change did what it claimed, and they produce artefacts (test reports) that the evidence manifest below references.

Gates for AI systems

AI systems add three things to the pipeline: an evaluation that a model must pass, a readiness rubric, and security regression tests. The series defines each as an artefact or method.

Tool	Kind	Origin	Purpose
Evaluation suite definition (evals/suites/*.yaml)	Artefact	AI Platform and Security, Chapter 20 and Appendix A	Declares datasets, metrics, thresholds and judge settings, turning the evaluation pyramid into a pipeline gate
Evaluation pyramid	Method	AI Platform and Security, Chapter 20	Layers tests from unit through golden set to human evaluation
ML Test Score	Method	AI Platform and Security, Chapters 7, 8, 20 and 23	Rubric for production readiness used as a gate (188, Breck et al., 2017)
CI security test workflow (ai-security-tests)	Artefact	AI Platform and Security, Chapter 17	Runs policy tests, regression suites for injection and leakage, and agent boundary tests, and publishes evidence

The security test workflow names three helper scripts (tools/redteam.py, tools/agent_fuzz.py, tools/evidence.py) that the book does not provide; this is recorded in the findings and means that the workflow is a pattern to adapt, not a runnable package (3, Nordqvist, 2026). The tools that carry out the red-team tests themselves are Chapter 11 of this book. The method that records the result of an evaluation is the evidence manifest below.

Records as files

Four further tools make the records in this chapter machine-checkable. YAML is the format in which the series keeps its artefacts under version control (AI Boss, Appendix A) (7, Nordqvist, 2026). JSON Schema (draft 2020-12) describes the structure that records and profiles are validated against in the pipeline (118, Wright et al., 2022); AI Boss validates its decision records against it (Chapter 25 and Appendix A) and AI Threat validates threat-register entries against a schema in Chapter 32 (5, Nordqvist, 2026). The method version control with pull-request review and pipeline validation (AI Threat, Chapter 32) keeps a register as one file per entry in a governance repository and validates every change. Together they are the cheapest evidence a team can start with, and the form in which every later policy and manifest in this chapter is kept.

Supply-chain tools: provenance, signing and bills of materials

Supply-chain evidence answers three questions about an artefact: what is in it, how it was built and who vouches for it. The series answers them with a bill of materials, a provenance attestation and a signature.

SLSA and in-toto

Kind	Third-party tools (a framework and an attestation format) and one artefact
Origin	Architecture as Code, Chapter 15A; AI Governance, Chapters 11 and 21; AI Platform and Security, Chapters 8, 9, 16 and 17; The Transformed Security Architect, Chapters 11, 14 and 16; AI Operations, Chapters 8 and 18
Purpose	SLSA grades build provenance; in-toto is the statement format used for SLSA attestations
Inputs	A build on a build platform
Outputs	A signed provenance attestation: build platform, external parameters, resolved dependencies and output digests
Full template	Architecture as Code, Chapter 15A, "SLSA provenance" (JSON; the artefact "SLSA provenance attestation (in-toto statement)")

Supply-chain Levels for Software Artifacts (SLSA) specifies build provenance and the requirements on the build platform (36, SLSA, n.d.). The in-toto project describes itself as a framework that makes transparent to the user which steps were performed in a software supply chain, by whom and in what order (264, in-toto Authors, n.d.). AI Operations summarises the levels it relies on: at Build L1 provenance exists and identifies the output by digest; at Build L2 it carries a signature that consumers can verify; at Build L3 it resists forgery by the tenants of the build platform, because the signing secrets are held by the build service and not by user-defined build steps (10, Nordqvist, 2026). Architecture as Code gives the JSON of a v1 provenance attestation as an in-toto statement and notes that the predicate type is written without a minor version (1, Nordqvist, 2025). AI Governance applies the same mechanism to models and datasets (2, Nordqvist, 2026); the model-approval policy above reads attestation.slsa_level. in-toto is mentioned in passing in the volume, and nothing further is claimed about it beyond what the project documentation cited above states.

Sigstore, Cosign, gitsign and OpenSSF Model Signing

Tool	Origin	What it does in the series
Sigstore	AI Governance, Chapters 11 and 21; AI Platform and Security, Chapters 8, 9, 16 and 17; The Transformed Security Architect, Chapters 9, 11 and 14	Keyless signing and verification bound to a workload identity, with a public transparency log (37, Sigstore, n.d.)
Cosign	Architecture as Code, Chapter 15A	Signs container images and stores the signature in the same registry; verification before deployment; admission controllers can enforce that only verified images run (38, Sigstore, n.d.)
gitsign	AI Platform and Security, Chapter 8	Signs Git commits with short-lived Sigstore certificates bound to an identity (39, Sigstore, 2026)
OpenSSF Model Signing (OMS)	AI Platform and Security, Chapters 8 and 9	Signs a manifest listing every model file by hash (40, Maruseac et al., 2025)

Two limits are recorded in AI Platform and Security, Chapter 8. The transparency log is public by default, so a European organisation with confidentiality concerns runs a private one; and GitHub does not show gitsign commits as verified, so SSH or GPG signing is the practical choice where a repository ruleset requires signed commits (3, Nordqvist, 2026). The signing step belongs to the pipeline run, and the verification belongs to the policy decision point: a registry promotion gate verifies signature and provenance, exactly as the pipelines of Architecture as Code verify container images.

Bills of materials

Tool	Kind	Origin	Purpose
Software Bill of Materials (NTIA minimum elements)	Third-party standard	Architecture as Code, Chapter 15A	The minimum elements of an SBOM, a formal record of the components used in building software: data fields, automation support (machine-readable formats) and practices (43, NTIA, 2021)
CycloneDX and SPDX	Third-party standards	Architecture as Code, Chapter 15A	The two SBOM formats the volume produces; SPDX describes itself as an open standard for representing software components as SBOMs, published as ISO/IEC 5962:2021 (266, SPDX Workgroup & Linux Foundation, n.d.)
CycloneDX and SBOM (ECMA-424)	Third-party standard	The Transformed Security Architect, Chapters 16 and 20	The format named in supplier requirements (41, Ecma, 2025)
Syft	Third-party tool	Architecture as Code, Chapter 15A	Generates an SBOM from a container image or directory in CycloneDX or SPDX form; the project describes a command-line tool and Go library that generates an SBOM from container images and filesystems (263, Anchore, n.d.)
SBOM generation steps (Syft, CycloneDX) in CI	Artefact	Architecture as Code, Chapter 15A	A CI step that generates an SBOM from an image, scans it and writes a manifest
CycloneDX ML-BOM (two volumes)	Third-party standard	AI Governance, Chapters 6, 18 and 27; AI Platform and Security, Chapters 8, 16 and 17	Bill of materials for models and datasets (42, OWASP, n.d.)
ML-BOM for a fine-tuned model	Artefact	AI Platform and Security, Chapters 8 and 16	A CycloneDX ML-BOM for a model, comparable against the signed artefacts

The CI step in Architecture as Code uses an SBOM action to generate an SPDX file, a scan action that fails the build at a severity cutoff, and a short script that writes a manifest with a control identifier (SEC-SUPPLY-001), framework mappings and the SHA-256 of the SBOM (1, Nordqvist, 2025). The ML-BOM example of AI Platform and Security records the model, its base model with a hash, the dataset with its classification and hash, and the dependencies between them, with properties that point to the SLSA attestation and the decision record; the promotion gate compares its hashes against the signed artefacts (3, Nordqvist, 2026). That volume also notes that CycloneDX version 1.7, published by Ecma as the second edition of ECMA-424 in December 2025, includes machine learning models in its scope (41, Ecma, 2025).

Provenance for what an organisation publishes

Tool	Kind	Origin	Purpose
Publishing with provenance	Method	AI Threat, Chapter 10	Signed media, a canonical record with a SHA-256 hash, labelling and impersonation monitoring
Content-provenance policy (CPP-*)	Artefact	AI Threat, Chapter 10	Policy for signing, labelling and publishing the canonical record of an authority's own communications (example CPP-NR-2026-01)

The same primitives, signature and hash, protect what an authority says as well as what it ships. The method is the one place in the series where the artefact under signature is a communication, not code (5, Nordqvist, 2026).

Evidence tools

Evidence is what a pipeline leaves behind in a form someone else can verify. Architecture as Code (Chapter 15A) defines the discipline: machine-collected, versioned artefacts stored in immutable storage with signing and metadata that reference the originating control, environment and timestamp, so that auditors browse a catalogue instead of requesting exports (1, Nordqvist, 2025). The later volumes add the manifest, the pack and the expiry.

Evidence manifest

The inventory holds the evidence manifest as six entries from six volumes. They are one idea with different shapes, and the reader who needs the template should choose by the question being asked.

Volume	Shape	What it binds
Architecture as Code, Chapter 15A	Described in the lifecycle table; no schema. The SBOM example writes control_id, generated_at, framework_mappings and artefacts with a SHA-256 per artefact	Artefacts to control identifiers and framework mappings
AI Governance, Chapter 11	EvidenceManifest (evidence.aiarch.example/v1): subjects (model, dataset, prompt bundle), evaluations, controls, approvals, attestation (in-toto) and retention	A release of a system to the obligations it satisfies
AI Platform and Security, Appendix A (07_CODE_EVIDENCE)	EvidenceManifest (ai-architecture.example.eu/v1): classification, controls with obligation, evidence path, hash and producer, evaluation, supply chain, deployment approvals, attestation, retention	A model's promotion, assembled by the final job of the promotion pipeline
The Transformed Security Architect, Chapters 9 and 19	An evidence block inside the control entry (CTRL-*), not a separate template: source and freshness for each control	A control to the evidence collected as a by-product
AI Blue, Chapters 27 and 28	Cited as EVD-NR-2027-* in the end-of-book records; the volume does not define it	Nordvik's records at the end of the book
AI Purple, Chapters 11 and 16	EvidenceManifest (EVD-*): the versions tested, the runs including the failed one, hashes, who reproduced it, who signed it, an expiry and a status	A re-test result to a finding

AI Governance sets the two design decisions that make the chain trustworthy: evidence is written once and never edited, in an append-only store with retention locks, and each manifest references the previous one; and signing happens in the pipeline with an identity bound to the run (2, Nordqvist, 2026). AI Platform and Security gives the fullest template, which lets an auditor start from an AI Act article and arrive at the file that demonstrates compliance. It is quoted below, abbreviated by removing two of the three control entries.

# evidence/AIDR-0030/case-handler-assistant/3.2.0/manifest.yaml
apiVersion: ai-architecture.example.eu/v1
kind: EvidenceManifest
metadata:
  system: case-handler-assistant
  version: 3.2.0
  aidr: AIDR-0030
  generatedAt: 2026-03-10T14:22:31Z
  generatedBy: github-actions/model-promotion@run-8831204
  gitCommit: 7c2e1f9a4b3d8e6f0a1c2b3d4e5f6a7b8c9d0e1f
  retention:
    minimumYears: 10            # Article 18: documentation kept for ten years
    logsMinimumMonths: 6        # Article 26(6): deployer log retention
spec:
  classification:
    result: high-risk
    evidence: classification.json
    sha256: 2d8f4a6c1e9b3f7a5c0d2e4b6f8a1c3e5d7f9b0a2c4e6d8f1a3b5c7d9e0f2a4b
  controls:
    - obligation: art26-deployer-obligations
      control: human-oversight-assigned
      evidence:
        - path: oversight-roster.json
          sha256: 1f2e3d4c5b6a79808f9e0d1c2b3a4f5e6d7c8b9a0f1e2d3c4b5a6f7e8d9c0b1a
          producedBy: scripts/export_oversight_roster.py
  evaluation: {results: evaluation.json, gate: gate.json, gateResult: pass}
  supplyChain: {mlbom: mlbom.json, scan: scan.json, provenance: attestation.intoto.jsonl}
  deployment:
    productionApprovals:
      - {approver: "role:head-of-case-handling", at: 2026-03-12T09:04:10Z}
      - {approver: "role:chief-architect", at: 2026-03-12T09:41:55Z}
  attestation: {signedBy: evidence-signer@example.eu, signature: manifest.sig}

Quoted from AI Platform and Security, Appendix A. The obligation identifiers match those of the classification policy of that volume, so a test can check that every derived obligation has evidence.

The reader should note that the three EvidenceManifest templates use three different apiVersion values and that the prefix EVD- is used for the re-test manifest of AI Purple and for the graded evidence record of AI Threat below. These are recorded in the findings and in Chapter 25.

Graded evidence record

AI Threat (Chapter 4 and Appendix A) defines an EvidenceRecord (EVD-*, for example EVD-024-01) that grades one claim about a threat on the evidence ladder, with the outlook label (observable, expected or speculation), the sources, a challenger and the events that would raise the rung or lower the confidence (5, Nordqvist, 2026). It is a different artefact from the manifests above, although it shares the prefix; the tools for weighing evidence about claims are Chapter 23 of this book.

Evidence pack index

Kind	Artefact
Origin	AI Governance, Chapter 11
Purpose	Indexes the evidence pack handed to an auditor: audit questions, the artefacts that answer them and their hashes
Inputs	A system, a period, a store query and the generator's commit
Outputs	A signed index (EP-*) with one section per audit question; an empty section is itself a finding
Identifier family	EP-* (example EP-2026-011)
Full template	AI Governance, Chapter 11, "Worked example: evidence-pack index"

The pack is generated by query, not assembled by hand, and the store_query and the generator commit make it reproducible: a second auditor can regenerate it and compare hashes (2, Nordqvist, 2026). The sections follow the auditor's questions (use per intended purpose, oversight operating as designed, logs complete and retained), each citing the article of the AI Act it answers.

Evidence lifecycle, export pipelines and re-test evidence

Evidence lifecycle management (Architecture as Code, Chapter 15A) is the method and its table of seven stages: capture (an automated pipeline step produces the artefact), packaging (a manifest links artefacts to control identifiers and framework mappings), storage (immutable object storage with versioning), indexing (the manifest is registered in a catalogue for audit queries), retrieval (by control identifier or framework), expiry (archive or delete per policy, by lifecycle rule) and access control (who may write, read and delete evidence, codified and reviewed) (1, Nordqvist, 2025). The table names tooling for each stage; the point for a practitioner is that every stage is a pipeline step or a storage rule, not a person's task.

Two export pipelines apply the lifecycle. The MFA evidence export pipeline (Architecture as Code, Chapter 15A) is a CI job that produces artefacts for one control, multi-factor authentication for human identities, so that downstream reporting can reuse them; it calls scripts/export_mfa_snapshot.py, which the volume does not provide. The evidence export pipeline in the blueprint (Architecture as Code, Appendix C) stamps artefacts with control identifiers and framework mappings for reuse across frameworks; the volume describes it without giving a template.

AI Purple adds the property that the earlier manifests lack: evidence expires. The manifest EVD-NR-2028-0003 records the versions of the detection, the runbook and the provider's AI configuration that were tested, the runs including the failed one (a run in which the alert was closed by the provider's AI), the hashes of the run log and telemetry, who reproduced the result, who signed it and the date at which it expires; the regression case it supports sets evidenceExpiryDays: 180 (9, Nordqvist, 2026). The tools that decide when a finding closes are Chapter 14 of this book.

Worked example: a pipeline gate that rejects an unsigned model artefact

Illustrative example. Hansa Mutual's group platform applies the baseline below to every security AI workload. It is quoted from AI Red Team, Chapter 16, and it contains four rules: model calls must go through the AI gateway, egress must be default-deny, processing must stay in an approved region, and every model must have a verified signature. The fourth rule is the gate.

# Illustrative: Hansa Mutual, baseline for security AI workloads
package hansa.platform.secai_baseline

import rego.v1

allowed_regions := {"hansa-dc-frankfurt"}

deny contains msg if {
    input.workload.securityAi
    not input.workload.route.viaGateway
    msg := sprintf("%s: model calls bypass the AI gateway", [input.workload.id])
}

deny contains msg if {
    input.workload.securityAi
    input.workload.egress.default != "deny"
    msg := sprintf("%s: egress is not default-deny", [input.workload.id])
}

deny contains msg if {
    input.workload.securityAi
    not input.workload.processingRegion in allowed_regions
    msg := sprintf("%s: processing outside approved region", [input.workload.id])
}

deny contains msg if {
    some model in input.workload.models
    not model.signatureVerified
    msg := sprintf("%s: unsigned model artefact %s", [input.workload.id, model.name])
}

Read with the tools of this chapter, the gate works in five steps. The build signs the model, for example by signing a manifest of its file hashes with OpenSSF Model Signing, under an identity bound to the pipeline run. It produces an ML-BOM and a provenance attestation. A verification step, which in the series is the registry's promotion gate (3, Nordqvist, 2026), sets signatureVerified on each model in the workload description; the volume does not say which program does this, so the field is a contract, not a feature. The policy decision point evaluates the baseline and returns the deny messages; an unsigned model produces unsigned model artefact <name> and the deployment does not proceed. The decision, the policy version and the commit go into the evidence manifest, and the manifest is signed. The same policy runs against the running estate and detects drift, such as a model swapped by an engineer, an automation or an intruder outside the pipeline (4, Nordqvist, 2026).

The example also shows what the gate does not do. It checks that a signature was verified, not that the signer was the right party or that the model is safe; those claims belong to the model-approval policy (licence, evaluation, provenance level) and to the evaluation gate.

Across the degrees of delegation

The tools in this chapter do not change between the degrees of delegation, but what they allow does. The degrees are those of AI Operations: Level 0 Advisory, Level 1 Assisted, Level 2 Supervised, Level 3 Bounded and Level 4 Autonomous. Where the originating volumes state a rule it is given; where they do not, the cell says so.

Tool	Level 0 Advisory to Level 2 Supervised	Level 3 Bounded	Level 4 Autonomous
Policy decision point (OPA and Rego)	Evaluates and records; a person acts on the result	Evaluates and releases within the class the policy names	In the series the policy decision point stays outside the agent at every level
Change gate policy	An agent may draft; at any level a human approver independent of the author is required for agent-authored change	A class such as HM-STD-002 sets draft at Level 2 Supervised and release at Level 3 Bounded, with limits on resources, deletes and identity changes	AI Operations does not use Level 4 for an irreversible action on production data, for a release outside an authorised window, or for an action that disables the observer or the stop path
Reconciler sync policy	The ops agent of the example may read state; it cannot sync	Automated sync only for catalogued standard classes that passed the gate	An agent identity with the right to sync is a thing the artefact must never contain
Signing and evidence	The pipeline signs and writes the manifest; a person approves the classes the policy names	Same	Same

Use across the series

Nordvik Region and Hansa Mutual

The two fictional organisations use the tools of this chapter in different places, according to the examples in the volumes. Nordvik Region generated an evidence pack (EP-2026-011) for the first internal audit of its benefits-triage system, and publishes a content-provenance policy (CPP-NR-2026-01) for its own communications. Its change record CHG-NR-2028-0007 shows an agent-authored certificate renewal that passed the change gate with two human approvers, a tested rollback and a verification run by an external probe; for its portal, AI Operations gives a Flux design in which a merge to the release branch is the release, made by a person inside the window. The volumes mark these as illustrative. The evidence manifest quoted above is the example of AI Platform and Security and is not attributed to either organisation.

Hansa Mutual applies the secure-configuration baseline to its security AI workloads, uses the Rego zone-crossing rule against its architecture workspace, runs the claims-core service under an Argo CD project with an allow window and a deny window that mirrors its freeze calendar, and classifies certificate renewal for services outside critical functions as the standard change class HM-STD-002. Nordvik Region's end-of-book records in AI Blue cite evidence manifests (EVD-NR-2027-*) that the volume does not define, so the reader should not assume that the template exists. Both organisations are fictional and the examples are illustrative; the canonical profiles are in EXAMPLE_ORGANISATIONS.md of the earlier volumes.

Coverage

The inventory assigns 169 entries to this chapter. Of them, 88 are treated in an entry, a family table or a section of prose above (the third-party entries that several volumes repeat, such as Open Policy Agent, SLSA, Sigstore, Trivy and the bill-of-materials formats, count once per volume in the inventory); the remaining 81 are policy, requirement, record, decision and publishing entries that the first-pass assignment placed here and that belong to the chapters named in the table of policy records and in the findings file for this chapter (data/findings/chapter_05.md, under "Reassign"). Appendix A lists every inventoried tool, including the entries not treated here.

Summary

The chapter's own conclusions are these. A rule becomes a tool when four things are true of it: it is written in a form that an engine can evaluate, it has tests, a decision point that its author does not control evaluates it, and every decision leaves a record. Open Policy Agent and Rego are the series' common engine and language, and the policies in the volumes differ mainly in their input documents, not in their mechanism. The gates are only as good as the inputs they read, so a check on the resulting state, made by something other than the pipeline, belongs with every gate that reads a plan.

Supply-chain tools answer what is in an artefact (a bill of materials), how it was built (a provenance attestation) and who vouches for it (a signature). A scanner is itself a dependency, and the same controls apply to it. Evidence is useful when it is written once, signed by the pipeline run, bound to an obligation and given an expiry. The six evidence manifests in the volumes are one idea in different shapes, and a team should choose one shape, keep it in version control and index it, rather than mix them.

For the degrees of delegation, the series' rules are consistent: the policy decision point stays outside the agent, an agent-authored change has an independent human approver, and no agent identity holds the right to sync a state engine. These are the points at which the tools of this chapter limit the autonomy of the tools of Chapters 18 and 19.

Sources

1. Nordqvist, G. Architecture as Code. (1, Nordqvist, 2025)
2. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (2, Nordqvist, 2026)
3. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (3, Nordqvist, 2026)
4. Nordqvist, G. AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (4, Nordqvist, 2026)
5. Nordqvist, G. AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. (5, Nordqvist, 2026)
6. Nordqvist, G. The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. (6, Nordqvist, 2026)
7. Nordqvist, G. AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. (7, Nordqvist, 2026)
8. Nordqvist, G. AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. (9, Nordqvist, 2026)
9. Nordqvist, G. AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. (10, Nordqvist, 2026)
10. SLSA. Supply-chain Levels for Software Artifacts (SLSA) specification, version 1.2: Build requirements for producing artifacts, and Build provenance. (36, SLSA, n.d.)
11. Sigstore Project. Sigstore: Signing, verification and provenance for software artefacts. (37, Sigstore, n.d.)
12. Sigstore. Cosign: Signing overview. (38, Sigstore, n.d.)
13. Sigstore Project. gitsign: Keyless Git signing using Sigstore. (39, Sigstore, 2026)
14. Maruseac, M., Wickens, E., Major, D., Sablotny, M. An Introduction to the OpenSSF Model Signing (OMS) Specification: Model Signing for Secure and Trusted AI Supply Chains. (40, Maruseac et al., 2025)
15. Ecma International. ECMA-424: CycloneDX Bill of Materials Specification,. (41, Ecma, 2025)
16. OWASP Foundation. Machine Learning Bill of Materials (AI/ML-BOM). (42, OWASP, n.d.)
17. NTIA. The Minimum Elements For a Software Bill of Materials (SBOM). (43, NTIA, 2021)
18. Open Policy Agent Contributors. Open Policy Agent Documentation. (51, Open Policy Agent, n.d.)
19. Open Policy Agent. Policy Language. (101, Open Policy Agent, n.d.)
20. Wright, A., Andrews, H., Hutton, B. JSON Schema: A Media Type for Describing JSON Documents. (118, Wright et al., 2022)
21. The Kubernetes Authors. Validating Admission Policy. (158, The Kubernetes Authors, n.d.)
22. Argo Project. Automated Sync Policy. (162, Argo Project, n.d.)
23. Argo Project. Sync Windows. (163, Argo Project, n.d.)
24. Open Policy Agent. Terraform. (182, Open Policy Agent, n.d.)
25. GitHub Docs. Understanding GitHub Actions. (183, GitHub Docs, n.d.)
26. GitLab. Get started with GitLab CI/CD. (184, GitLab, n.d.)
27. Jenkins. Pipeline. (185, Jenkins, n.d.)
28. Microsoft Learn. What is Azure Pipelines?. (186, Microsoft, n.d.)
29. Gruntwork. Terratest. (187, Gruntwork, n.d.)
30. Breck, E., Cai, S., Nielsen, E., Salib, M. The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction. (188, Breck et al., 2017)
31. National Vulnerability Database. CVE-2026-33634: Trivy v0.69.4 supply chain compromise. (189, NVD, 2026)
32. Argo Project. Projects. (190, Argo Project, n.d.)
33. Conftest Authors. Conftest: a utility to help you write tests against structured configuration data. (259, Conftest Authors, n.d.)
34. Kyverno Authors. Kyverno documentation: Introduction. (260, Kyverno Authors, n.d.)
35. Checkov. What is Checkov?. (261, Checkov, n.d.)
36. Aqua Security. Trivy: a comprehensive and versatile security scanner. (262, Aqua Security, n.d.)
37. Anchore. Syft: a CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems. (263, Anchore, n.d.)
38. in-toto Authors. in-toto: a framework to secure the integrity of software supply chains. (264, in-toto Authors, n.d.)
39. Gatekeeper Authors. Gatekeeper documentation: Introduction. (265, Gatekeeper Authors, n.d.)
40. SPDX Workgroup, Linux Foundation. SPDX: an open standard for software bills of materials. (266, SPDX Workgroup & Linux Foundation, n.d.)
41. Aqua Security. tfsec: tfsec to Trivy migration. (267, Aqua Security, n.d.)