Secure SDLC: reviewing code when AI writes part of it

A secure SDLC is a software development life cycle in which security checks are built into every stage, from design to release, instead of being added after the code ships. When an AI assistant writes part of the code, the review stage carries more of that weight: it is the last point where a person decides whether code nobody typed by hand is fit to merge.

That shift catches many teams halfway. They adopt AI coding tools quickly, and their review practice stays the one they had when every line came from a colleague they knew. The result is more code moving through the same checkpoint, with the same habits, and new kinds of mistakes that those habits weren't built to catch. This article explains why AI-written code needs an explicit review rule, what a secure SDLC looks like when AI is part of the toolchain, what belongs on the review checklist, and who should review and record what. The point: AI doesn't make secure development harder to define, but it makes skipping the definition much more expensive.

Why AI-written code needs a review rule, not more trust

AI-written code needs a review rule because it arrives faster than teams can absorb it and fails in ways human code rarely does. A colleague who invents a library name gets caught in the first build; a model can suggest a package that doesn't exist, and someone may have registered that name since. Trust built on knowing who wrote the code doesn't transfer to a tool.

Two findings show the scale. Google's DORA research program, in its 2025 report on AI-assisted software development, found that AI adoption is associated with higher delivery throughput but continues to have a negative relationship with delivery stability. More change goes out, and without strong controls, more of it breaks.

The second finding is specific to security. Researchers presenting at USENIX Security 2025 analyzed code generated by 16 language models and found that the average share of hallucinated packages was at least 5.2% for commercial models and 21.7% for open-source models, with 205,474 unique invented package names. An attacker who registers one of those names, a tactic that has come to be known as slopsquatting, gets their code installed by anyone who accepts the suggestion without checking.

Neither problem is solved by trusting the tools more or less. Both are solved by a review rule that every change goes through, whoever or whatever wrote it.

What a secure SDLC looks like when AI writes part of the code

A secure SDLC with AI in the toolchain keeps the same stages as any secure development process, and adds a decision at each one about what the AI may do. The reference most teams start from is NIST's Secure Software Development Framework (SP 800-218), which opens by noting that few SDLC models explicitly address software security in detail, so secure practices have to be added to whatever process a team already uses. NIST has since published a companion profile, SP 800-218A, with practices specific to generative AI.

In practice, the stages look like this:

• Plan. Decide which AI tools the team may use, on which repositories, and with access to what data. This is where "what an engineer is allowed to point a model at" gets written down.
• Write. Use only approved tools, keep secrets and customer data out of prompts, and label pull requests in which AI produced a significant part of the change.
• Review. A person who understands the system reviews every change before it merges, with a checklist that covers what AI tends to get wrong.
• Build. Automated checks run on every change: dependency scanning, secret scanning and tests. They catch what a tired reviewer misses.
• Release and record. Merges, approvals and exceptions leave a trail someone can read later.

None of these stages is new. What's new is that the plan stage now includes the tools, and the review stage has to assume that a fluent, confident change can still be wrong.

The review checklist: secrets, dependencies and access

The review checklist for AI-assisted code covers the failure modes that generated code makes more likely. Secrets, dependencies and access come first, because they are where a single missed line can expose a system.

A practical secure code review checklist for AI-assisted changes:

1. Secrets. No keys, tokens or passwords in the code, in configuration files, or in test fixtures the tool generated. Secret scanning in the pipeline backs up the human check.
2. Dependencies. Every new package exists, is the one the team intended, and comes from the expected source. This is the check that stops slopsquatting.
3. Access. The change asks for no more permissions than it needs: no broad database roles, no new network exposure, no service account with rights it doesn't use.
4. Output handling. Code that passes model output to other systems validates it first. The OWASP Top 10 for LLM Applications lists improper output handling as one of its ten risks, alongside sensitive information disclosure and supply chain weaknesses.
5. Agent permissions. If the change gives an AI agent the ability to act, such as running commands, calling APIs or writing to a repository, its scope is limited. OWASP calls the opposite "excessive agency."
6. Tests that test something. Generated tests that only confirm the generated code does what it does are not tests. The reviewer checks that they would fail if the behavior were wrong.

Code review best practices still apply on top: small changes, a clear description, and a reviewer who can explain the change in their own words before approving it.

Who reviews, and what gets logged

The reviewer is a person who understands the part of the system being changed and is accountable for approving it. The tool that wrote the code is never the reviewer of the same code, and an AI review assistant can support the human check but not replace it.

What gets logged is what lets the team answer, months later, how a change got in:

• Who approved the change, and whether the approval followed the checklist.
• Whether AI produced a significant part of the change, so the team can see where generated code concentrates.
• Exceptions, such as a dependency accepted without the usual check, with the reason and the person who accepted it.
• Which tools are approved and who decided, so the plan stage has a record too.

That record is also what makes the practice teachable. A new engineer reads it and learns how the team decides, not just what it decided.

The method an engineer brings to your review process

A secure SDLC is easier to hold when the engineers joining a team already work inside one. DevLatam describes its engineers as arriving with the engineering frameworks and playbooks of its group, ACL and DataArt, covering “how code gets reviewed, how access is granted, how data is handled, and what an engineer is allowed to point a model at.” The page on being backed by ACL & DataArt is explicit about the limit: “they follow your practices, not ours.” The method gives the engineer a starting point; your process still decides.

That matters most in the first weeks, when a new engineer either picks up your review rules or improvises around them. The 30-day developer onboarding playbook covers how to bring someone into your process, and the guide to running a remote agile development team covers how review fits into the team's rhythm. For the profiles that own this work full time, DevLatam's page on AI, security and data engineering describes what a security engineer takes charge of: access and data governance around AI systems, and review of what each new capability exposes.

Frequently asked questions

How secure is code generated by AI?

AI-generated code is only as secure as the review it goes through. Models write fluent code that can still invent packages, leak secrets into configuration, or request broader access than needed, and Google's DORA research links AI adoption with lower delivery stability. Treat every generated change as untrusted until a person and the automated checks approve it.

What is an example of using the SSDF?

One example is turning NIST's practice PW.7, reviewing and analyzing human-readable code to find vulnerabilities, into a team rule: every pull request gets a human review against a checklist, plus automated code analysis in the pipeline. The SSDF groups its practices into four areas: prepare the organization, protect the software, produce well-secured software and respond to vulnerabilities.

Are code reviews worth it?

Yes, code reviews are worth it, and more so when AI writes part of the code. Review is where a person checks secrets, dependencies, access and tests before a change merges. The cost is senior time; the alternative is finding the same problems later, in production, where fixing them also means handling the incident.

‍

Making review the control that matters

AI moves effort from writing code to checking it. A secure SDLC makes that move deliberate: the tools are decided in planning, the checklist covers what generated code gets wrong, a person approves every change, and the record shows how each one got in. The teams that adopt AI without losing control are not the ones that trust the tools least. They are the ones that wrote the review rule down.

The next step is to compare your current review practice with the checklist above and mark what's missing. If the gap is a person, an engineer who already works inside a security discipline, talk to us about the profile.