SDLC · IaC · DevSecOps

Zero touch needs zero doubt.

Two things get said in the same conversation. We want a pipeline with no hands in it. And nothing audits our DevSecOps. They are not two problems — they are one. Today the reviewer glancing at a green check is the control. Take that person out and you get zero touch and zero assurance at the same moment. So the work is not automating more of the pipeline. It is making the pipeline prove itself, after which taking the hands out becomes safe.

The gates exist. What they did is unrecorded.

and nothing anywhere says which one

None of the following throws an error. That is precisely what makes them audit problems rather than engineering problems — engineering problems announce themselves.

Bypass is invisible

Forced merges, administrative overrides, a step configured to continue on error, a scanner that "passed" because the job swallowed its own failure.

The safety net shrinks

Tests deleted or quarantined to turn a build green. Coverage falls, and the build goes from red to green — which reads as progress.

Findings raised, never closed

Waivers with no owner and no expiry date. The finding is technically tracked and practically permanent.

Declared is not executed

The pipeline definition says the scan runs. Whether it ran on this release, against this commit, is a different question and usually an unanswerable one.

Shipped is not reviewed

A passing gate proves the source was clean at scan time. It does not prove the artefact in production came out of that pipeline.

Infrastructure drifts

Somebody clicked in the console. The code still describes an environment that no longer exists.

Why agents are worse at infrastructure code than at ordinary code

This is measured, published, and not a matter of model quality. On a 458-task infrastructure-as-code benchmark, a frontier model that solves the large majority of ordinary programming tasks solves fewer than a fifth.

86.6%
pass@1 on conventional Python function tasks
19.4%
pass@1 on Terraform tasks, same model, published benchmark
46 pts
of that gap opens between "generated something" and "it validates" — almost entirely invented argument names

The cause is structural rather than mysterious. A correct configuration has to satisfy four constraints simultaneously, and ordinary code generation only ever faces the first.

Constraint 4

Policy

Compliant with organisational rules — which are usually not written anywhere the generator can read.

Constraint 3

Graph

Dependencies coherent across every referenced resource, not just locally well-formed.

Constraint 2 — where the gap lives

Schema

Conformant to the pinned provider version. This is an API surface nobody memorises and it changes per version. A model asked to recall it invents plausible names, and plausible names are exactly what a reviewer fails to catch.

Constraint 1

Syntax

Valid against the provider plugin. The only one ordinary code generation has to satisfy.

Which is good news, because it makes this a retrieval problem rather than a reasoning ceiling. Published results put hallucination at roughly half of generations unaided, and under one in ten once the provider schema is actually retrieved instead of remembered. That is an engineering fix, not a wait-for-the-next-model fix.

Four stages, in cost order, each naming its own repair

Retrieval and repair fix different failure classes. A loop that only knows "it failed" re-rolls the dice on a cause its retry cannot address — which is why the stage that failed matters more than the number of attempts.

01 · free, local

Schema

no credentials needed
Ground

Read the pinned provider schema and correct against it. Never retry from memory.

02 · needs an init

Validate

no credentials needed
Repair

The vocabulary is right and the structure is wrong. Fix the diagnostics as given.

03 · needs credentials

Plan

touches the real backend
Investigate

Usually not the code at all: credentials, a held state lock, a provider version mismatch.

04 · needs the plan

Policy

evaluated against the plan
Redesign

Valid and forbidden are different verdicts. Retrying never turns a denial into an approval.

The plan is a machine-checkable oracle. Most domains have none.

Whether an agent's work is acceptable is usually a judgement call, which is why so much agentic work cannot be gated or priced on outcome. Infrastructure code is the exception: the plan is a deterministic statement of what will happen, produced before anything happens.

SAFE

Creates and updates only. Nothing is lost if it proceeds.

REVIEW

Something is destroyed or replaced. A person decides.

BLOCKED

A stateful resource would be destroyed. It does not proceed.

Replacement does not appear in the code diff. The configuration shows an attribute being edited; the provider decides that this particular attribute forces a destroy-and-recreate. An agent reading its own diff cannot see it, and neither can a reviewer reading the pull request. An agent reading the plan can — and a database recreated by a change everybody approved is exactly the incident this prevents.

At scale, do not let the agent write free-form configuration

Free-form generation means the search space is the entire provider surface — thousands of resource types, each with dozens of version-specific arguments. Composing from an approved module catalogue collapses that to your own forty modules, and bounds the hallucination surface by construction rather than by supervision.

You wanted the catalogue anyway — for consistency, for compliance, and so a platform team owns the patterns instead of every project reinventing them. The constraint that makes agents reliable here and the governance goal you already had turn out to be the same piece of work.

Auditable by construction, not by inspection

Every hop — specification, plan, generated configuration, validation, policy decision, apply — emits a signed verification certificate: hash-bound to the artefact it describes, verifiable against a published key, and expiring. The evidence is produced as the work happens, rather than reconstructed afterwards from logs that were never designed to answer the question.

Signed posture exports into the service-management, compliance or GRC system you already run. We are not asking you to adopt another pane of glass — we feed the one you have.

And there is now a date on it

The EU Cyber Resilience Act turns pipeline hygiene from good practice into a dated legal obligation for products with digital elements placed on the EU market.

11 September 2026

Reporting obligations apply: actively exploited vulnerabilities and severe incidents must be notified to ENISA and the relevant national CSIRT within 24 hours — including for products already on the market.

11 December 2027

The full regime applies: secure development requirements, technical documentation, conformity assessment and CE marking. Penalties reach €15 million or 2.5% of worldwide annual turnover.

A 24-hour clock is itself an agentic use case: detect, assess severity, assemble the notification and file it, on a deadline, with the evidence attached. Doing that by hand, out of hours, is how deadlines get missed.

Start with a DevSecOps assurance scan

Point it at your pipelines and it reports what the gates actually did over the last N runs: bypasses taken, findings waived and never closed, steps that failed silently, and artefacts that cannot be traced back to a reviewed commit. It reads your own records — so it needs no trust from you, and no change to your pipeline.