Notifications
Clear all
Topic starter
06/09/2026 6:20 pm
TL;DR: AI coding agents are widening an existing secure SDLC gap by producing vulnerable code, obscuring agent identity, and shifting controls earlier in the lifecycle, according to Arnica’s checklist for AppSec teams. The practical implication is that design-time rules, generation-layer governance, and code-owner routing now matter as much as scans at merge time.
NHIMG editorial — based on content published by Arnica: APPSEC SSDLC Checklist for AppSec Teams (September 2026)
By the numbers:
- 100 times the cost of the same defect, n can reach up to 100 times the cost of the same defect found during design, making early security gates materially cheaper.
- Arnica says 82% of findings point to developers who have already left, which shows why ownership routing must be tied to current code owners.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Arnica's checklist for secure SDLC controls across AI-generated code and AppSec phases →
AI-generated code and SSDLC gaps: what AppSec teams need now?
Explore further
06/09/2026 6:21 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: AI-generated code is widening secure SDLC gaps across every phase
