AI-generated code is widening secure SDLC gaps across every phase

At a glance

What this is: This is an AppSec checklist for building a secure SDLC that places controls across requirements, design, coding, testing, deployment, and maintenance, with a specific focus on AI-generated code and agentic development risks.

Why it matters: It matters because IAM, PAM, and NHI teams increasingly need to govern bot identities, agent permissions, and secrets exposure inside the software delivery chain, not just human developer access.

By the numbers:

• AI coding agents show a 25.7% vulnerability rate across tested samples, which means generation-time controls are now a security requirement rather than a nice-to-have.
• 100 times the cost of the same defect
• Arnica says 82% of findings point to developers who have already left, which shows why ownership routing must be tied to current code owners.

👉 Read Arnica's checklist for secure SDLC controls across AI-generated code and AppSec phases

Context

Secure SDLC programs fail when security is treated as a final review step instead of a design constraint. In AppSec, that gap becomes more visible as AI coding agents generate code faster than human review cycles can absorb, while secrets, authorization, and dependency risks continue to enter the pipeline.

The identity angle is real even in a software delivery article: AI coding tools commit under bot identities, may reproduce secret-shaped strings, and require separate governance from human developer accounts. That makes this topic relevant to IAM, PAM, and NHI teams as well as AppSec leads, because the control problem spans both code and the identities that create it.

Key questions

Q: How should security teams implement AI code generation controls in the SDLC?

A: Start at the point of generation, not at the point of release. Put SAST, dependency checks, and secrets detection directly into the developer workflow, then back them with CI/CD enforcement and runtime testing. That combination lets teams catch insecure suggestions early without trying to audit every generated line after the fact.

Q: Why do AI coding agents make application security harder to govern?

A: AI coding agents increase risk because they can generate large volumes of code quickly, often optimised for function over security. They also replicate insecure patterns, propagate shared thread context, and create a false sense of trust in generated output. Governance must shift toward explicit requirements, runtime validation, and repeatable review gates.

Q: What do AppSec teams get wrong about secure SDLC checklists?

A: The most common mistake is treating the checklist as a final review gate instead of a lifecycle control system. When requirements, design, and coding controls are weak, testing simply confirms that the organization waited too long to intervene. That is especially true with agentic development, where the unsafe choice may be made before code review begins.

Q: How can identity teams support secure SDLC governance?

A: Identity teams can help by governing bot identities, service accounts, and approval paths that sit inside the delivery pipeline. They should ensure code ownership is current, privileged automation is limited, and remediation routing follows the active accountable party. That makes SDLC governance consistent with IAM and NHI lifecycle control.

Technical breakdown

Secure SDLC phase controls and where they fail

A secure SDLC works when each phase has its own explicit control set. Requirements define security acceptance criteria, design establishes trust boundaries and threat models, coding enforces secure patterns, testing validates both static and runtime behaviour, deployment blocks unsafe releases, and maintenance handles drift, patching, and revocation. The failure mode in many programmes is not missing tools but missing sequencing. If security only appears at the end, teams inherit fixed architecture decisions and expensive rework. AI-generated code worsens this because some defects now arrive before a pull request exists, which means traditional merge-time checks are already too late.

Practical implication: move controls upstream so requirements, design, and generation-time rules are gated before code reaches review.

AI-generated code changes the AppSec control plane

AI coding agents compress work into large drafts that can bypass the friction points where human developers would normally self-correct. That changes the control plane for AppSec because the relevant risk is no longer only unsafe code patterns, but also agent scope, prompt influence, and how the agent is configured. Traditional SAST and DAST still matter, but they are now downstream detectors rather than primary preventers. The article’s key point is that security rules need to live inside agent configuration files and generation workflows, where the code is created rather than where it is eventually merged.

Practical implication: enforce rules in the agent layer and treat AI-generated pull requests as a distinct review class.

OWASP Agentic Applications risks map into SDLC phases

The OWASP Top 10 for Agentic Applications maps risks such as Agent Goal Hijack, Identity Abuse, Tool Misuse, and Rogue Agents to different SDLC stages. That mapping matters because behavioural failures are not caught by syntax-only scanners. A design flaw can let an agent exceed its intended scope even when the code is clean, while a deployment flaw can allow unlogged agent actions to persist undetected. AppSec teams need phase-specific controls because agentic risk is architectural, not just code-level.

Practical implication: align each agentic risk to the phase where it can still be constrained, especially design and deployment.

Threat narrative

Attacker objective: The practical objective is to turn fast software delivery into a durable exposure surface by introducing weaknesses that survive into production and are harder to unwind later.

1. Entry occurs when AI coding agents generate or modify code with unsafe defaults, credential-shaped outputs, or mis-scoped behaviour before a human review gate exists.
2. Escalation happens when those outputs reach repositories, configuration files, or pipelines with insufficient generation-layer controls, allowing risky patterns to persist into build and release stages.
3. Impact is vulnerable production code, exposed secrets, and delayed remediation, amplified by stale ownership and review routing that no longer matches the active developer.

NHI Mgmt Group analysis

AI-generated code creates governance debt, not just code risk. The article shows that AppSec cannot rely on post-commit scanning alone when complete drafts are generated in one pass. That shifts the governance burden toward generation-layer controls, code-owner attribution, and policy enforcement inside agent configuration files. For identity teams, the material point is that bot identities are now part of the delivery pipeline and must be governed like any other privileged workload.

Secure SDLC is becoming an identity problem as much as a development problem. When AI agents commit code, route findings, and interact with pipelines, they act as non-human identities inside engineering workflows. That means IAM and NHI governance must extend beyond runtime infrastructure into source control, review routing, and approval boundaries. The control question is no longer only who can deploy, but which identity generated the change and under what policy.

Generation-time controls should now be treated as the primary control for AI coding risk. Traditional SAST and DAST remain necessary, but they operate after the risky artifact exists. The article’s strongest operational insight is that security rules need to be enforced at the moment code is produced, because once AI-generated defects enter the PR queue, the organization has already lost the cheapest intervention point. Practitioners should interpret this as a shift from detection-first to constraint-first governance.

Ownership routing is becoming a security control, not an admin convenience. The reference to findings being routed to developers who have already left highlights a familiar but under-discussed failure mode. If code ownership is stale, remediation stalls and security findings become operational noise. The practitioner lesson is to align code ownership, identity lifecycle, and backlog routing so that AppSec findings reach the current accountable party.

Named concept: generation-layer security. This is the control pattern where agent configuration, rule enforcement, and identity attribution are applied before a pull request exists. It matters because it moves policy into the same layer that produces the risk, which is more effective than trying to clean up after the fact. Teams that formalise this concept will be better positioned to govern agentic development at scale.

What this signals

Generation-layer security is the direction AppSec will keep moving in because merge-time scanning cannot reliably compensate for code that is already wrong at creation. For identity programmes, this means bot identity governance must be tied to source control, agent configuration, and approval routing, not just runtime access.

The practical signal for IAM and PAM teams is that privileged automation will keep spreading into engineering workflows. That increases the value of least privilege, short-lived access, and clean ownership mapping across service accounts, build agents, and code owners.

AppSec and identity teams should expect more overlap between secure SDLC controls and NHI lifecycle controls, especially around offboarding, ownership drift, and secret exposure in CI/CD systems. The governance boundary is moving from deployment to generation.

For practitioners

• Define security acceptance criteria in requirements Put explicit security acceptance criteria in the same backlog as functional requirements so releases have a shared definition of done before design begins.
• Enforce design-time threat modelling Require threat modelling before architecture is finalised and block implementation until high-severity risks have documented mitigations.
• Embed rules in agent configuration files Write mandatory security rules into the agent files that AI coding tools actually read, then audit those rules as part of source control review.
• Scan AI-generated pull requests immediately Trigger SAST, SCA, and secrets scanning when AI-generated code is created, not only when it is about to merge.
• Separate agent identity from developer identity Track bot identities, service accounts, and human developers separately so code actions, approvals, and remediation routing remain attributable.

Key takeaways

• AI coding agents are widening secure SDLC gaps because they create risky code before conventional review controls can intervene.
• Identity governance now extends into delivery pipelines, where bot identities, agent permissions, and code ownership affect remediation and accountability.
• The most effective control shift is upstream: define requirements, enforce policy in agent configuration, and scan at generation time rather than after merge.

Key terms

• Secure SDLC: A Secure SDLC is a software development process that embeds security into each lifecycle phase instead of treating it as a final check. It requires requirements, design, code, testing, deployment, and maintenance to all include controls that reduce vulnerabilities, supply chain exposure, and release-path abuse.
• Agentic Development Lifecycle: The Agentic Development Lifecycle is the control pattern for building, approving, deploying, and reviewing AI agents before they reach production. It extends software change discipline into identity governance by requiring traceability for creation, access grants, business purpose, and ongoing oversight.
• Generation-layer security: Generation-layer security means applying controls at the moment code or content is created, not only after it has been committed or deployed. In AI-assisted development, this includes agent rules, identity attribution, and output restrictions that shape the artefact before review begins.
• Bot Identity: The digital identity assigned to a software robot or RPA agent that interacts with applications and systems. Bot identities often operate with elevated privileges and require careful lifecycle management and regular auditing.

What's in the full article

Arnica's full post covers the operational detail this post intentionally leaves for the source:

• Phase-by-phase SSDLC checklist items for requirements, design, coding, testing, deployment, and maintenance
• Specific controls for AI-generated code, including rule injection into agent configuration files and scan timing
• Examples of how agentic risks map to SDLC phases and where traditional AppSec tools stop being sufficient
• The practical workflow for routing findings to the current code owner instead of a stale account

👉 Arnica's full post covers the phase-by-phase controls, AI agent risks, and developer workflow details

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is useful for practitioners who need to bring identity discipline into automation, pipelines, and AI-driven delivery workflows.