Topic starter
02/08/2026 11:42 am
TL;DR: Traditional secure SDLC controls assume humans deliberately author, review, and gate changes, but AI-driven development is now generating code, dependencies, CI workflows, and infrastructure that bypass those checkpoints, according to OXSecurity. Security governance has to move from static phase gates to provenance, reachability, and runtime exposure because the old review model no longer matches how software is created.
Editorial analysis by NHI Mgmt Group, based on content published by OXSecurity: “Secure SDLC in the Age of AI: From Static Checks to Active Risk Control”.
By the numbers:
- A 2025 analysis by the Cloud Security Alliance found that 62% of AI-generated code contains design flaws or known vulnerabilities.
Key questions
Q: What breaks when secure SDLC assumes humans authored the change?
A: Human-authorship assumptions break down when AI generates code, dependencies, pipelines, and infrastructure together.
Q: Why do AI-generated changes increase runtime exposure even when scans pass?
A: Scans can show that a generated artefact is syntactically clean while missing the permissions, APIs, and service paths that make it dangerous in production.
Q: How do security teams know if AI-driven delivery is creating hidden risk?
A: Look for changes that move through review quickly but arrive with unclear authorship, excessive permissions, or bundled code and infrastructure updates.
Practitioner guidance
- Trace AI-generated changes to source provenance Require every AI-assisted change to retain lineage from prompt or assistant output through commit, build, and deployment so reviewers can see where the change came from.
- Validate runtime reachability before release Use runtime context to decide whether a finding is actually exploitable, including API exposure, service permissions, and the identities that can reach it.
- Separate generation, approval, and deployment authority Review whether the same human or automation identity can generate code, approve it, and push it toward production, then remove unnecessary overlap.
Bottom line: AI-driven development is weakening secure SDLC because code, dependencies, CI workflows, and infrastructure can now be generated faster than human review can reliably govern them.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:54 pm
AI-generated development has turned secure SDLC into a provenance problem. The old model assumes that deliberate human authorship creates a reviewable trail from design to deployment. AI-assisted pipelines break that assumption because the same system can generate code, configuration, dependencies, and workflow logic in one pass. Practitioners should now treat provenance and change lineage as first-class governance controls.
A few things that frame the scale:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams govern AI-assisted development across the SDLC?
A: Treat AI as part of the delivery control plane, not as a point tool. Set explicit human approval boundaries for planning, architecture, code review, testing, deployment, and exception handling, then require traceability for every AI-generated handoff so accountability survives the workflow.
👉 Read our full editorial: AI-driven development is breaking secure SDLC assumptions