AI is reshaping software risk faster than security teams can adapt

At a glance

What this is: AI-assisted development is changing software risk by increasing code production, exposing more dependency and supply-chain risk, and compressing the time defenders have to find and fix flaws.

Why it matters: For IAM and security practitioners, the shift matters because governance now has to track not only human-written code but also the identity, provenance, and trust boundaries of the systems generating and shipping it.

By the numbers:

• Nearly 45% of AI-generated code contains known security vulnerabilities when no security guidance is provided.
• Only 55% of AI code generation tasks result in secure code.
• 82% of organizations carry security debt, up 11% in a single year.

👉 Read Veracode's analysis of how AI is reshaping software risk

Context

AI changes software risk by removing the human bottleneck from code production while leaving core trust assumptions intact. That means security teams have to govern a much larger stream of code, dependencies, and deployment decisions without assuming that speed improvements also improve assurance. In practice, the problem spans application security, supply chain risk, and the trustworthiness of the systems that generate software.

For identity programmes, the governance lesson is familiar even when the domain is not. When tooling, pipelines, and service identities can introduce code and dependencies at machine speed, security leaders need provenance, access control, and continuous verification. The same lifecycle discipline that matters for NHIs also matters for AI-assisted delivery, which is why the NHI Lifecycle Management Guide is a useful reference point for control thinking.

Key questions

Q: What breaks when AI-generated code is reviewed without security gates?

A: What breaks is the assumption that a clean-looking diff is a safe diff. AI-generated code can hide unsafe defaults, dependency issues, and weak validation that basic review misses. Without CI-enforced tests and security checks, the merge process becomes a distribution channel for defects rather than a control point.

Q: Why does AI make software supply chain risk harder to control?

A: AI increases the amount of code produced, which reduces the time available for review and makes malicious or unauthorized changes harder to spot. It also introduces non-human actors into the development flow, so traditional assumptions about developer identity no longer hold. That combination expands the attack surface at the commit stage.

Q: How can organisations tell whether AI-assisted development is actually working?

A: Use downstream indicators such as escaped defects, rework after merge, security findings, and time spent validating generated code. If the assistant increases review load, secret exposure, or release friction, the apparent speed gain is likely being paid back later in the delivery lifecycle.

Q: Should organisations automate remediation for AI-related cloud findings?

A: Organisations should automate triage and workflow routing before they automate remediation. AI-guided investigation can compress decision time, but final containment still needs accountable owners and verification. Automation works best when it speeds the path to a human decision rather than hiding the evidence behind the decision.

Technical breakdown

Why AI-assisted code creation amplifies application risk

AI-assisted development changes the economics of software delivery by producing more code in less time, but it does not make the generated code trustworthy. Models can generate syntactically correct output that passes basic tests while still embedding insecure patterns, weak validation, or unsafe dependency use. That creates a larger population of issues that security teams must triage, and it does so before many teams have updated their SDLC controls to match the pace of generation. The key technical shift is not just volume. It is the mismatch between generation speed and security assurance speed.

Practical implication: move security checks into the developer workflow and treat AI-generated code as untrusted until validated.

How software supply chain exposure grows when AI assembles dependencies

AI tools do not only generate code. They also suggest, import, or assemble dependencies that may be opaque to the developer. That expands software supply chain risk because transitive libraries, hallucinated package names, and unreviewed components can enter the build path without clear accountability. The architectural issue is provenance. If teams cannot trace what was introduced, by whom, and under what policy, they cannot reliably assess whether the software is safe to ship. This is where supply chain controls and identity governance intersect: every build actor needs a clear trust boundary.

Practical implication: enforce dependency provenance checks and review every AI-influenced package introduction before release.

Why faster vulnerability discovery changes the attacker advantage

AI is accelerating both sides of the equation. Defenders can scan more quickly, but attackers can also find exploitable flaws faster and at greater scale. That shortens the useful life of latent technical debt and turns old vulnerabilities into immediate risk. The result is a compressing time window in which exposed weaknesses move from theoretical to exploitable. For security programmes, the technical challenge is no longer simply finding vulnerabilities. It is identifying which issues are reachable, exploitable, and likely to be targeted before remediation capacity is overwhelmed.

Practical implication: prioritise exploitable and reachable flaws rather than chasing raw vulnerability counts.

Threat narrative

Attacker objective: The attacker aims to exploit faster-discovered software weaknesses before defenders can validate, patch, or govern them, creating a scalable path into production systems.

1. Entry occurs when AI-generated or AI-assisted code introduces vulnerable logic, unsafe dependencies, or unreviewed packages into the software delivery pipeline.
2. Escalation happens when attackers or automated tools discover those flaws faster than teams can remediate them, converting dormant defects into practical footholds.
3. Impact follows when unpatched application weaknesses or supply chain exposures enable code execution, data access, or broader compromise of production systems.

NHI Mgmt Group analysis

AI code generation creates a governance gap, not just a quality problem. The central failure is the assumption that faster code production can be governed with the same review model built for human-paced delivery. That assumption no longer holds when generation, dependency introduction, and deployment all move faster than security validation. For identity and access teams, this also means treating pipeline actors, build services, and AI tools as governed entities with bounded privilege.

AI-assisted delivery increases software trust debt. The article makes clear that organisations are not only accumulating security debt in code, but also in the trust model around that code. Provenance, accountability, and continuous verification are becoming the controls that matter most because point-in-time approval cannot keep pace with machine-assisted assembly. The practical conclusion is that trust has to be demonstrated continuously, not assumed at review time.

Dependency provenance is the new control plane for AI-built software. When tools can import, recommend, or even hallucinate packages, the software supply chain becomes an identity and policy problem as much as a development problem. The named concept here is software trust drift: the widening gap between what teams believe they shipped and what actually entered the build. Organisations need authoritative dependency governance to close that drift.

Attackers now benefit from compressed vulnerability discovery cycles. AI-assisted research reduces the time it takes to turn latent flaws into active exploitation opportunities. That does not replace traditional attack patterns, but it makes them more efficient and more scalable. For security leaders, the conclusion is that remediation programmes must be built around exploitability and reachability, not just compliance completion.

Continuous verification is becoming the minimum acceptable assurance model. The article is right that boards, regulators, and customers will increasingly ask whether what is running is what was approved. In practice, this shifts security from periodic scanning to evidence-based validation across build, dependency, and deployment stages. The field should treat that as an operating requirement, not an aspiration.

What this signals

Software trust drift: as AI increases code velocity, the gap between approved build intent and what reaches production will widen unless teams invest in attestations, dependency governance, and policy enforcement. That is not only an application security issue. It is a programme-level governance issue that should be tracked alongside identity controls, because build actors, service identities, and automation rights now shape what can ship.

The operational signal for practitioners is that vulnerability counts alone will stop being a useful management metric. Teams need evidence of reachability, provenance, and approved artefact parity, supported by continuous control monitoring. Reference models such as the NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls remain relevant because they map governance to measurable control outcomes.

For identity programmes, the lesson is that machine-speed delivery requires machine-speed governance. Where AI tools can introduce software artefacts, the organisations that will cope best are those that already treat access, provenance, and lifecycle control as continuous processes rather than periodic checks. That is exactly the posture the NHI Lifecycle Management Guide is designed to support.

For practitioners

• Move security controls into the development workflow Run SAST at commit time, pair it with SCA for every build, and add DAST into CI/CD so AI-generated defects are caught before they reach release gates.
• Govern AI-influenced dependencies as a supply chain risk Require provenance checks for packages, block unapproved dependency introduction, and flag hallucinated package names before they can be pulled into the build.
• Prioritise exploitable findings over raw volume Use reachability, exposure, and business impact to rank remediation so teams do not spend scarce capacity clearing low-risk noise while exploitable issues remain open.
• Establish continuous verification for shipped software Compare production artefacts against approved build attestations and treat any mismatch as a governance failure, not a routine exception.

Key takeaways

• AI-assisted development increases software risk by multiplying both code volume and the chance that insecure logic reaches production.
• The evidence shows a widening remediation gap, with vulnerability discovery and exploitation moving faster than many teams can clear technical debt.
• Security programmes now need continuous verification, dependency provenance, and risk-based prioritisation to keep pace with machine-assisted delivery.

Key terms

• Software trust drift: The growing mismatch between what teams believe they approved and what actually enters the build and production path. In AI-assisted delivery, this drift emerges when code, dependencies, and artefacts move faster than governance can verify them, weakening assurance even when projects appear to be under control.
• Supply chain provenance: The ability to trace where code, packages, and build artefacts came from and how they were produced. It is essential for software trust because it turns opaque assembly into an auditable chain of custody that security, compliance, and operations teams can verify.
• Continuous Verification: A Zero Trust practice that re-evaluates trust during the session instead of relying on a single successful login. The control is stronger when context signals are available in real time and when the identity programme can act on those signals without creating excessive exceptions.

What's in the full article

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

• Detailed explanation of how AI-assisted development changes vulnerability introduction across the SDLC
• Veracode's remediation guidance on integrating SAST, SCA, and DAST into delivery pipelines
• Specific examples of how AI accelerates dependency introduction and supply chain exposure
• The compliance and governance framing behind software trust, attestations, and audit readiness

👉 Veracode's full post covers the code, supply chain, and governance details behind the risk shift

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners build the control discipline needed to govern identities and access in modern security programmes.