Security and Compliance Inside the Loop

Security and Compliance Inside the Loop is the decision about where controls sit relative to the work. A finding raised after a pull request opens has already consumed review capacity, and a finding raised at release has consumed a release. The same check placed where the agent iterates costs a few seconds of compute.

Key takeaways

• Veracode's testing, published 24 March 2026, found 45% of generated code contained a known security flaw across 80 coding tasks in four languages, testing four weakness classes.
• The pass rates are lopsided in a way that should shape your checks. Veracode reports 86% for insecure cryptography and 82% for SQL injection, against 15% for cross-site scripting and 13% for log injection.
• NIST SP 800-218 practice PW.7 requires an organisation to determine whether code review, code analysis or both should be used, perform it against its own secure coding standards, and record and triage every discovered issue in the team's workflow or issue tracking system.
• The standard was published in February 2022 and does not mention agentic authorship. That is not an exemption, it is why the organisation has to decide and document its own answer.
• The Cyber Resilience Act's reporting obligations apply from 11 September 2026 and its main obligations from 11 December 2027. These are published dates, not legal advice.

Read this after Chapter 9, because an auditor's first question is who is accountable and the ownership records answer it, and before Chapter 11, which measures whether any of it is working. The threat model for agents holding credentials is the subject of the agent trust boundary in a companion volume.

The security review lands eight days before a release. It returns fourteen findings, of which eleven are the same finding in different files.

Nine of the eleven are cross-site scripting in newly generated templates. One engineer fixes them over two days, one file at a time, and each fix needs a review, which enters the queue from Chapter 5.

Nobody in the chain did anything wrong. The control sits at the point where it is most expensive to satisfy. That placement was a decision, made years ago, for a different kind of codebase.

The four weakness classes that keep appearing

There is first-party vendor testing on this and it is worth naming carefully. Veracode published its Spring 2026 GenAI Code Security Update on 24 March 2026, and its scope is narrow enough that the scope matters as much as the headline.

Veracode tested 80 coding tasks across Java, JavaScript, C# and Python against four weakness classes: SQL injection, cross-site scripting, log injection, and insecure cryptographic algorithms. It reports that 45% of generated code contained a known security flaw.

The distribution is the useful part. Veracode reports pass rates of 86% for insecure cryptography and 82% for SQL injection, against 15% for cross-site scripting and 13% for log injection. By language it reports Python at 62%, C# at 58%, JavaScript at 57% and Java at 29%. Retesting the latest flagship models, it reports pass rates remaining, in its words, stubbornly stuck at approximately 55%.

Two readings follow. The classes with decades of framework-level defences and abundant training material do reasonably well. The classes that depend on context do badly, meaning where output is rendered and what reaches a log. Those are also the classes a general-purpose scanner catches worst. Context is the hard part, for a tool and for a reviewer.

What PW.7 actually requires

Compliance conversations get vague, so it helps to read the actual requirement. NIST's Secure Software Development Framework, SP 800-218 version 1.1, published February 2022 and organised into four practice groups, prepare the organisation, protect the software, produce well-secured software, and respond to vulnerabilities, contains the relevant practice.

Practice PW.7 requires an organisation to determine whether code review, code analysis, or both should be used, then to perform the code review or code analysis based on the organisation's secure coding standards, and to record and triage all discovered issues and recommended remediations in the development team's workflow or issue tracking system.

Read what that does and does not say. It does not prescribe a tool, a threshold, or a coverage level. It requires three things. A decision, a standard to check against, and a record.

Its notional examples are more specific and more useful than the practice text. Peer review of code. Expert reviewers checking for backdoors and malicious content. Static analysis with a human reviewing the reported issues. And automated identification of unsafe software practices on a continuous basis as human-readable code is checked into the code repository. The scope explicitly covers third-party code and reusable code modules written in-house.

Your secure coding standards are the artifact the standard points at

PW.7 checks against the organisation's secure coding standards, which means those standards are a prerequisite rather than a nicety. Most organisations do not have them in a form a machine or an agent can use.

Write them as rules that name the mechanism, not as principles. Not validate all input, which is unactionable, but output is escaped at the template boundary using the framework's escaping function and never by string concatenation. Not use strong cryptography, but this named algorithm and key length, from this named library, with keys from this named store.

Two things then become possible that were not before. The rules go into the standing context from Chapter 3, so the agent is authoring against them rather than being corrected afterwards. And the subset that is mechanically checkable becomes a gate from Chapter 6, with an owner watching its effective false positive rate.

DORA's report of 24 September 2025 found 51% of respondents rely on AI for security analysis. So the standards are increasingly being applied by the same class of tool that writes the code, which is another reason to write them precisely rather than aspirationally.

Move the check to where the loop is fastest

The economics of control placement are simple and they run in one direction. Four positions are available and their costs differ by orders of magnitude.

In the agent's loop, the finding costs seconds and the fix costs nothing, because the code has not been proposed to anybody. At pull request open, it costs a pipeline run and an author's context switch. At review, it costs the scarcest capacity in the organisation. At release or in a penetration test, it costs a schedule.

The first row has a limitation worth stating honestly. A finding prevented inside the loop leaves no artifact, and PW.7 wants a record, so the second row is where your evidence comes from. Push the fixes left and keep the recording at the gate.

Recording and triaging is the clause that gets skipped

Of the three obligations in PW.7, the third is the one I see missed most often. Findings are recorded and triaged in the development team's workflow or issue tracking system.

That means the security tool's own dashboard is not sufficient. The finding has to arrive where work is scheduled, with a disposition attached, and the disposition includes accepted risk as a legitimate outcome provided somebody named accepted it.

Three fields do most of the work. What was found, with the location and the class. What was decided, meaning fixed, mitigated, or accepted with a reason. And who decided, with a date.

That record has a second use beyond compliance. It is the only dataset that tells you which weakness classes your generated code actually produces, which is what lets you tune the standing context rather than guessing from a vendor's aggregate numbers.

The dates, stated as dates

This section states published dates and required artifacts. It is not legal advice, this book does not offer any, and whether a given product falls in scope is a question for people qualified to answer it.

The European Commission records that the Cyber Resilience Act entered into force on 10 December 2024, that reporting obligations apply from 11 September 2026, and that the main obligations apply from 11 December 2027. It sets cybersecurity requirements covering the planning, design, development and maintenance of products with digital elements, obliges manufacturers to handle vulnerabilities across the lifecycle, and requires CE marking.

The engineering consequence is narrow. If your products are in scope, obligations attach to how software is developed and maintained rather than only to what ships, and the artifacts are records that cannot be reconstructed after the fact.

Which is the same argument as the rest of this chapter, arriving from outside the organisation. A finding you never recorded is a finding you cannot show anyone. Records are not backfillable. That is the whole reason the date matters.

A worked example, composited and labelled

The details here are composited from ordinary production shapes rather than one system, and the shape is exact.

A team with the cross-site scripting problem from the opening scene changes three things and none of them is a new tool.

The escaping rule goes into the standing context as a named mechanism, with an example of the correct call and an example of the incorrect one. A pre-open pipeline check blocks any template using raw interpolation, with a named owner watching its false positive rate against the 10% threshold from Chapter 6. And the security review's findings get written into the issue tracker with a disposition and a name, rather than living in a report attached to an email.

The next release ships with two findings of that class instead of nine, both in files the check does not cover, which is useful information about the check rather than about the engineers.

Total effort was about a day and a half. The saving is nine reviews and two days of an engineer's week, repeated every release, and it compounds as volume rises.

The objection: the standard predates agents, so it does not apply

I hear a version of this regularly and it is worth answering precisely, because the argument has a correct premise and a wrong conclusion.

The premise is right. SP 800-218 was published in February 2022, does not mention agentic authorship, and was written for a world where a person typed the code being reviewed. A related NIST document addresses generative AI development, and it governs building models rather than using them to write ordinary software, so citing it here would be a category error.

The conclusion does not follow. PW.7 is written as a requirement to decide, to check against your own standards, and to record, and none of those three clauses depends on who or what typed the code. If anything the practice reads more urgently now, because its scope already extends to third-party and reusable code, which is a reasonable description of what an agent produces from a training corpus.

So the honest position is that the standard is silent. Silence is not permission. The organisation has to decide its own answer, write it down, and be able to show it, which is exactly what an auditor or an enterprise customer will ask for. Nobody accepts the standard's age as your reason.

There is a smaller version of the same objection worth pre-empting. Teams sometimes argue that their scanner covers it, so no decision is required. A tool is an implementation of a decision. It is not the decision, and it is not the record.

Chapter summary

Control placement is the decision this chapter settles, and the economics run one way: a finding inside the agent's loop costs seconds, at pull request open it costs a pipeline run, at review it costs the scarcest capacity you have, and at release it costs schedule. Veracode's first-party testing, published 24 March 2026 across 80 tasks in Java, JavaScript, C# and Python, found 45% of generated code contained a known security flaw, with lopsided pass rates of 86% for insecure cryptography and 82% for SQL injection against 15% for cross-site scripting and 13% for log injection, and pass rates on retested flagship models remaining around 55%, which suggests context-dependent classes are where your own checks have to be strongest. NIST SP 800-218 practice PW.7, published February 2022, requires three things: determining whether code review, code analysis or both should be used, performing it against the organisation's own secure coding standards, and recording and triaging all discovered issues in the development team's workflow or issue tracking system, with notional examples including automated identification of unsafe practices on a continuous basis as code is checked in, and with scope covering third-party and in-house reusable code. Those secure coding standards have to be written as named mechanisms rather than principles so they can live in the standing context from Chapter 3 and become gates from Chapter 6. The recording clause is the one most often skipped, and it needs what was found, what was decided including accepted risk, and who decided with a date. The Cyber Resilience Act entered into force on 10 December 2024, with reporting obligations from 11 September 2026 and main obligations from 11 December 2027, stated as dates rather than as legal advice.

Every chapter so far has changed something about how work flows. Chapter 11 is Measuring Delivery When DORA Stops Working, and it comes here rather than earlier because you cannot judge which metrics survive until you hold the gates, queues and owners that generate them.