Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

ADLC and appsec: what changes when code never really stops?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 15051
Topic starter  

TL;DR: AI-assisted development is collapsing the SDLC’s old pause points, and Checkmarx argues that AppSec controls built for pull requests and release gates no longer keep pace with continuous code generation and refactoring. The practical shift is toward in-line, policy-driven security that operates inside the development loop rather than after it.

NHIMG editorial — based on content published by Checkmarx: ADLC is breaking SDLC-era appsec assumptions

Questions worth separating out

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.

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.

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.

Practitioner guidance

  • Embed policy checks in the IDE Move risk evaluation into the developer workflow so insecure patterns are flagged before commit, not after pipeline execution.
  • 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.
  • 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.

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.

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

ADLC and appsec: what changes when code never really stops?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 14635
 

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.

A question worth separating out:

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.

👉 Read our full editorial: ADLC is breaking SDLC-era appsec assumptions



   
ReplyQuote
Share: