SSDF must evolve for AI-generated code and active attack surfaces

At a glance

What this is: This analysis argues that the SSDF must be updated for AI-generated code because probabilistic output, larger patch volumes, and agentic attack surfaces break its current assumptions.

Why it matters: It matters because security and identity teams increasingly rely on automated code and AI agents that can influence software supply chains, making deterministic verification and governed access part of secure development.

By the numbers:

• Sonar analyzes more than 750 billion lines of code every day across 7 million software developers.
• LLM patches modify an average of 14x more code than traditional tools, and agentic workflows correlate with a 3 to 5x increase in lines added per project.
• Sonar's research found that coding models, left unverified, produce roughly 1,200 security issues per million lines of code analyzed.

👉 Read Sonar's analysis of how AI-generated code changes SSDF controls

Context

The Secure Software Development Framework was written for software delivery models that assume deterministic tools, bounded review load, and humans as the primary authors of code. AI-assisted development weakens all three assumptions at once, which is why the SSDF discussion now sits squarely in software supply chain governance and identity-bound workflow control.

For identity and access teams, the intersection is not abstract. AI code generation depends on credentials, repository access, CI/CD permissions, and often delegated tool access through service accounts or agents. That makes AI-assisted development part of the same control problem as privileged automation, except the output can change from one run to the next.

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 do AI coding tools complicate governance and auditability?

A: AI coding tools complicate governance because teams can adopt them informally, outside central visibility and approval. That makes it hard to prove who used what tool, what policy applied, and whether generated code followed security rules. The audit problem is not just code provenance. It is control provenance.

Q: How can security teams tell whether AI-generated code is actually safe?

A: They should look for security regression evidence, not just test pass rates. A codebase is safer only when the agent’s output survives threat-informed checks, review of privileged paths, and validation against the vulnerability classes most likely to recur in that repository.

Q: Who is accountable when an AI agent makes an unauthorised change?

A: Accountability should be assigned to the governance model that authorised the delegation, the owner of the workflow, and the team that set the policy boundary. In practice, organisations need clear responsibility for agent configuration, monitoring, and incident response because the machine’s speed does not remove human accountability for the delegated identity.

Technical breakdown

Why non-deterministic code generation changes the verification model

Traditional SDLC controls assume the same input produces the same output, which makes code review, testing, and policy enforcement repeatable. AI code generation is probabilistic, so the same prompt can yield different results across runs. That means the model cannot self-certify compliance, because its output is not stable enough to trust on its own. Deterministic verification layers such as static analysis, SCA, and CI checks become the control plane that compensates for that uncertainty. In governance terms, the question shifts from whether the model is helpful to whether its output can be independently proven safe.

Practical implication: make deterministic verification mandatory for AI-authored code before merge or release.

How agentic code volume breaks human review thresholds

Agentic workflows change the scale of change, not just the speed. When AI produces large pull requests, review quality drops because reviewers have limited attention and cannot inspect every path in very large diffs. That creates a structural mismatch between a human review process and machine-generated output volume. The issue is not reviewer skill, but review capacity relative to patch size and dependency churn. In practice, AI-assisted development increases the burden on CI, automated policy checks, and code quality gates, because those controls are the only ones that can keep pace with output volume.

Practical implication: shift large AI-authored changes into automated gates that block risky diffs before human approval.

Why AI is also an active attack surface in CI/CD and repositories

AI systems that read tickets, repositories, or build artifacts can be manipulated through prompt injection, malicious context, or adversarial inputs embedded in ordinary development content. If an agent has access to source control or pipeline credentials, those inputs can redirect its actions, escalate its privileges across sessions, or persist unsafe behavior. That is a control problem, not just a model-quality issue. The security model must treat AI agents as governed software entities with scoped access, monitored actions, and revocable permissions, especially when they can trigger code changes or deployment steps.

Practical implication: scope AI agents like privileged automation and restrict their access to the minimum development permissions needed.

Threat narrative

Attacker objective: The attacker wants to weaponise trusted development automation so that software changes, credentials, or deployment paths are altered without normal human review.

1. Entry occurs when malicious instructions are embedded in files, tickets, or build inputs that an AI coding agent ingests during routine development workflows.
2. Escalation happens when the agent follows those instructions inside repositories, CI/CD systems, or deployment paths that expose higher-value permissions than the original task required.
3. Impact follows when the manipulated workflow introduces unsafe code, persistent backdoors, or unauthorized changes into production software and its supply chain.

NHI Mgmt Group analysis

SSDF now needs outcome verification, not tool trust. The core problem is not whether AI can generate code, but whether the resulting code can be independently validated before release. A framework built around human authorship has to shift toward verifiable outputs, because probabilistic systems cannot certify themselves. That makes deterministic analysis, CI enforcement, and layered review central to governance rather than optional quality extras. Practitioners should treat verified outcomes as the new control objective.

AI code generation creates a review-capacity problem, not just a productivity problem. The volume and size of AI-authored changes overwhelm review processes designed for human-paced development. This is where supply chain governance meets operational reality, because dependency churn and patch size directly affect the attack surface. The practical consequence is that review needs machine assistance and policy gating to stay meaningful at all. Teams should re-baseline review thresholds around patch complexity, not developer intent.

AI-assisted development is now part of the NHI problem space. When coding agents, CI bots, and pipeline automations hold credentials or act on delegated permissions, they become governed non-human identities in practice. That means identity lifecycle controls, scope limitation, and revocation discipline matter just as much in software factories as they do in runtime workloads. The governance question is no longer only who can commit code, but what machine principal can do in the delivery chain. Practitioners should map AI development tools into NHI inventory and access review.

Active adversarial behaviour should be treated as a control design requirement. Prompt injection, memory manipulation, and workflow hijack are not edge cases once AI agents can touch build systems and source code. The SSDF update should explicitly reflect that the development pipeline itself can be attacked through the same delegated access paths used for automation. That aligns with NIST Cybersecurity Framework ideas around protecting integrity and validating change, and with OWASP NHI Top 10 concerns about machine principal abuse. Practitioners should harden the pipeline as if an attacker will target the agent, not only the code.

What this signals

AI-assisted development is now a governance problem as much as a software engineering problem. Once coding agents sit inside repositories and CI pipelines, their permissions, audit trails, and revocation paths must be managed like any other privileged non-human identity, with particular attention to credential scope and task boundaries.

Verification debt: this is the growing gap between the speed of AI-generated change and the organisation’s ability to prove that change is safe. Teams that keep treating automated code review as optional will accumulate release risk faster than their control stack can absorb it. Independent analysis and machine-enforced gates will matter more than developer confidence, especially where source control and deployment systems are already tightly integrated.

The next planning cycle should assume that AI-authored code will keep increasing in volume and complexity. That means security leaders need to align engineering policy, identity governance, and software supply chain controls now, rather than trying to retrofit them after the first large-scale failure.

For practitioners

• Mandate deterministic verification for AI-authored code Require static analysis, SCA, and CI validation on every AI-generated change before merge or release, especially where output is non-deterministic or large enough to evade human inspection. Use the verification result as the release gate, not developer confidence.
• Set review thresholds by patch complexity Define maximum AI-authored diff sizes, dependency-change limits, and escalation rules that push oversized changes into deeper automated inspection. This keeps review tractable when agentic workflows generate far more code than a human reviewer can safely read.
• Treat coding agents as governed NHI principals Inventory AI coding tools, CI bots, and build automations as non-human identities with scoped permissions, short-lived credentials where possible, and explicit offboarding when the task ends. Revoke access the same way you would for other privileged service accounts.
• Harden against prompt injection in development workflows Scan tickets, repositories, build artifacts, and documentation for adversarial instructions that could influence an AI agent. Separate untrusted context from privileged actions so a model can read development inputs without inheriting authority to execute them.

Key takeaways

• The SSDF’s human-author, human-review assumptions no longer hold in AI-assisted development.
• AI-generated code creates both scale problems and identity problems because the tools act inside privileged delivery workflows.
• Deterministic verification, scoped automation, and explicit ownership are the controls that turn AI output into something safe enough to release.

Key terms

• Deterministic Verification: A verification method that produces the same enforced result every time when the required proof is present, instead of relying on human judgement or probabilistic signals. It is useful for high-blast-radius access changes because it removes discretion from the decision point.
• Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.
• Security Debt: Accumulated risk that builds when vulnerabilities, unsafe dependencies, and policy gaps are left unresolved across the software lifecycle. In AI-assisted development, security debt grows quickly because more code is produced, more decisions are made automatically, and remediation often lags behind delivery.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full article

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

• Benchmark data on AI-authored pull request size, review effort, and verification gaps across production codebases
• Specific examples of how Sonar's Guide-Verify-Solve framework maps to pre-generation context, post-generation analysis, and targeted remediation
• The article's discussion of SSDF control changes, including how PW.5, PW.7, and PW.8 should adapt to AI-generated code
• The alignment Sonar suggests between SSDF updates and EU Cyber Resilience Act documentation and vulnerability-handling requirements

👉 Sonar's full post covers the SSDF control mapping, verification model, and EU CRA alignment in more operational detail.

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 in practical terms. It helps security and identity practitioners apply governed access principles to modern automation and AI-driven workflows.