ADLC is breaking SDLC-era appsec assumptions

At a glance

What this is: This analysis argues that the Agentic Development Lifecycle is making SDLC-era application security controls less effective because code now changes continuously rather than in discrete phases.

Why it matters: It matters to IAM and security teams because continuous software change creates the same governance problem seen in NHI and agentic AI programmes: controls built for human review cycles fail when production happens at machine pace.

👉 Read Checkmarx's analysis of ADLC and continuous appsec controls

Context

The core issue is not that application security has become less important, but that the operating model it was built around is fading. Traditional AppSec assumes code moves through recognizable stages where review, scanning, and approval can be inserted. In an Agentic Development Lifecycle, those pauses shrink or disappear, and security teams lose the timing they relied on to govern change. That creates a governance gap that is familiar to NHI and agentic AI practitioners: when systems operate continuously, point-in-time control models stop matching reality.

In that sense, ADLC is part of a broader shift toward machine-paced production across software and AI engineering. The security question is no longer whether a release passed a gate, but whether policy can follow changes as they are made. Where the article intersects with identity is in the control plane around access, authorization, and accountability for AI-assisted development, which increasingly behaves like a non-human actor in the delivery chain.

Key questions

Q: Where does traditional AppSec fail in an AI-assisted development lifecycle?

A: Traditional AppSec fails when it depends on pauses that no longer exist. If code is continuously generated and rewritten, pull-request review, release gating, and after-the-fact scanning happen too late to control risk. The control failure is timing, not intent. Teams need enforcement that operates during creation, not only after code has already moved downstream.

Q: When does AI-assisted development create more risk than it reduces?

A: It becomes net risk when code volume grows faster than ownership, review, and fix capacity. That is especially true when secrets, dependencies, and business logic are handled in separate tools. If teams cannot prioritise by reachability and impact, speed turns into hidden debt.

Q: What do security teams get wrong about AI-generated code risk?

A: They often focus on catching insecure output after code is written, which is too late for AI-native workflows. The more important control point is the moment the agent is allowed to initiate the action. If that step is not governed, testing becomes a detection layer rather than a prevention layer.

Q: How should security teams govern AI-generated code in production environments?

A: Security teams should treat AI-generated code as normal production code with extra provenance risk. Require architectural review, test coverage, static analysis, and approval before merge. Then bind the agent and the build pipeline to least privilege, short-lived credentials, and complete audit logging so implementation speed does not outrun control.

Technical breakdown

Why SDLC gates fail in continuous code generation

The Software Development Lifecycle assumes work can be paused for review at predictable checkpoints such as pull requests, builds, and releases. That model depends on human cadence. When AI systems continuously generate, rewrite, and refactor code, the volume and speed of change outstrip any gate that depends on interruption. The failure is not just scale, but timing. By the time a centralized review queue sees the code, the code may already have been rewritten several times. Security controls that assume stable snapshots lose relevance in a looped lifecycle.

Practical implication: move from checkpoint-based review to controls that evaluate changes continuously as they are created.

Agentic development lifecycle and the new unit of control

The Agentic Development Lifecycle changes the unit of work from release artifacts to a stream of small, fast-moving changes. In that environment, security needs to understand context, not just syntax. A line of code can be syntactically correct and still be dangerous if it introduces insecure trust assumptions, weak input handling, or unsafe dependency use. This is why the article frames agentic security as something that must persist alongside development rather than reacting after the fact. The architecture shifts from after-the-build inspection to in-workflow policy enforcement.

Practical implication: place policy evaluation inside the IDE and pre-commit path so risky changes are stopped before they spread.

Why AI-generated code can look safe while remaining insecure

AI-generated code often appears clean, idiomatic, and plausible, which makes it harder for human reviewers to spot risk quickly. That creates a false confidence problem. Functional correctness and security are separate properties, and a code sample can pass tests while still embedding exploitable logic or inconsistent trust decisions. The issue is especially acute when developers are forced to validate output at speed. In practice, the security model has to account for code that is not obviously broken but still violates organizational policy or introduces hidden exposure.

Practical implication: use security checks that test for exploitability and policy drift, not just compilation or functional success.

Threat narrative

Attacker objective: The attacker objective is to exploit insecure AI-assisted development paths to seed vulnerable code into delivery pipelines and production systems.

1. Entry occurs through AI-assisted code generation and modification, where insecure patterns can be introduced faster than manual review can intervene.
2. Escalation happens when those patterns propagate through repeated rewrites, reuse, and integration across a rapidly changing codebase.
3. Impact emerges when delayed feedback allows vulnerable code to reach pipelines or production before security teams can meaningfully control it.

NHI Mgmt Group analysis

ADLC creates appsec debt because control points were designed for pause, not flow. The article is right to frame SDLC-era security as increasingly mismatched to machine-paced development. When review, scanning, and approval are all positioned after work has already moved on, governance becomes retrospective rather than preventive. That is a structural failure mode, not a tooling gap. Practitioners should treat continuous code production as a control-design problem, not a developer discipline problem.

Agentic development is turning code review into an identity and authority problem. Once AI systems are generating and modifying code at runtime, security has to ask who or what is making the change, under what policy, and with what authority. That intersects directly with NHI and agentic AI governance because the system producing change behaves like a non-human actor in the software supply chain. The practical conclusion is that software delivery now needs accountable machine identity as much as it needs scanning.

Security controls that only judge artefacts will miss the real risk surface. The article shows why clean-looking code can still be insecure if the trust model is wrong. That matters because many programmes still optimize for code quality signals, not policy compliance or exploit resistance. A better frame is to govern the change event itself, including context, source, and allowed action. Practitioners should shift from artefact inspection to policy-bound change control.

Inline enforcement is becoming the only viable response to continuous development. If code is produced continuously, security guidance has to arrive continuously and close to the developer decision point. This does not remove governance, it changes the mechanism from episodic review to embedded policy. The broader market signal is that AppSec is converging with platform engineering and AI engineering, and programmes that do not adapt will end up with slower control and weaker outcomes.

What this signals

ADLC-style development increases the cost of delayed control. When code changes continuously, remediation windows matter as much as detection windows, and our research shows leaked secrets can take 27 days on average to remediate even when confidence is high. That is a warning sign for any programme that still treats security as a downstream review function rather than an embedded control layer.

The governance lesson extends beyond AppSec. As AI-assisted delivery matures, organisations will need stronger accountability for machine-generated change, clearer policy boundaries inside development tooling, and better visibility into where sensitive credentials or unsafe patterns are introduced. The practical test is whether control follows the change or only the ticket.

Continuous development is also a secrets governance problem. AI-assisted workflows increase the chance that credentials, tokens, or other secrets are copied, propagated, or validated outside normal review paths. Teams should align code security with the NHI Lifecycle Management Guide and with external guidance such as the OWASP Non-Human Identity Top 10 so identity controls and development controls do not drift apart.

For practitioners

• Embed policy checks in the IDE Move risk evaluation into the developer workflow so insecure patterns are flagged before commit, not after pipeline execution. Prioritise controls that can interpret surrounding context rather than only scanning text for known signatures.
• Treat AI-generated code as untrusted until validated Require exploit-focused validation for generated or heavily modified code, including tests that look for unsafe trust assumptions and policy violations. Do not rely on code readability or passing functional tests as a security signal.
• Redesign review gates for continuous change Replace queue-based security checkpoints with continuous policy enforcement that can keep up with repeated rewrites and rapid handoffs. Where review capacity is limited, focus human attention on changes with the highest privilege, data, or execution impact.
• Define authority for AI-assisted changes Document who approves, overrides, or blocks code changes produced with AI assistance, especially where those changes affect authentication flows, secrets handling, or deployment logic. Use accountable machine and human ownership to prevent policy drift.

Key takeaways

• ADLC breaks the SDLC assumption that code can be safely governed at fixed pauses in the delivery process.
• AI-generated code can look correct while still carrying insecure trust decisions, which makes timing and context part of the control problem.
• Security teams need inline, policy-bound enforcement that follows code creation rather than waiting for review queues or release gates.

Key terms

• 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.
• AI-Generated Code Risk: AI-generated code risk is the possibility that model-produced output introduces insecure credential handling, hidden secrets, or repeated patterns that weaken control design. The risk is operational, because the output can be merged quickly and at scale before humans catch the problem.
• Inline Enforcement: Inline enforcement is the technical act of applying access policy in the live session path, not just at approval time. It matters because identity governance without runtime enforcement can authorize access that the session layer never actually constrains, especially in distributed and third-party environments.
• Security-as-code review gap: The security-as-code review gap is the mismatch between fast, automated code production and slower human or queue-based review processes. It appears when controls depend on stable artefacts or scheduled interruptions, but the codebase keeps changing before reviewers can finish their assessment.

What's in the full article

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

• How its agentic security linter fits directly into supported IDEs such as VS Code, Cursor, Windsurf, and AWS Kiro.
• The workflow positioning before commits, pipelines, and handoffs, which is the implementation detail this analysis only frames conceptually.
• The article's own examples of how developer and AI engineering workflows change when security moves into the creation loop.
• The free-trial access path for teams that want to test the IDE-based workflow in practice.

👉 Checkmarx's full article covers the IDE workflow, continuous enforcement model, and developer assist details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to modern development and AI-driven delivery models.