Black Hat 2025 exposed a widening AI, supply chain, and cloud risk gap

At a glance

What this is: Black Hat USA 2025 surfaced three linked pressures: AI-driven code risk, software supply chain exposure, and cloud governance blind spots.

Why it matters: For IAM and security practitioners, the lesson is that identity, secrets, and access controls now sit inside a broader pipeline risk problem that spans code, cloud, and third-party dependency governance.

By the numbers:

• 10 security vulnerabilities.
• 83% of organizations are using AI for software development.
• With 61% of apps containing open-source dependencies, the software supply chain remains deeply exposed.

👉 Read Veracode’s Black Hat 2025 analysis of AI, supply chain, and cloud security

Context

Black Hat USA 2025 was less a single-product story than a snapshot of where the security market is headed: AI security, software supply chain assurance, and cloud control gaps are converging. In practical terms, the primary keyword here is AI security, but the governance challenge extends into IAM, secrets, and privilege management because code generation, third-party dependencies, and cloud access all shape the same risk surface.

That matters because security teams often still manage these domains separately, even though attackers do not. When AI systems generate code, when open-source dependencies enter software pipelines, and when cloud environments are monitored through fragmented tools, the result is a control stack that can miss identity exposure, secret leakage, and privilege misuse across the development lifecycle.

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 software supply chains create identity governance risk?

A: Because the identities that sign, build, approve, and deploy software can change the final outcome more than the code itself. Service accounts, CI tokens, and release credentials often have broad privileges and weak lifecycle controls. If those identities are not governed, the supply chain can be compromised without a visible perimeter breach.

Q: What do security teams get wrong about SaaS posture management?

A: They often treat SSPM as a scanning problem instead of a governance problem. Scanners can identify misconfigurations, but they do not decide ownership, revoke stale access, or enforce lifecycle closure. Without those follow-through processes, the programme produces findings without materially reducing exposure.

Q: How should teams respond when AI, code, and cloud controls are managed separately?

A: They should build one operating model that links application security, cloud posture, and identity governance. That means shared ownership for secrets, deployment identities, and remediation workflows, plus a common prioritisation layer so teams can decide whether the real issue is code, configuration, or access.

Technical breakdown

AI-generated code and OWASP Top 10 exposure

Veracode’s report points to a core mechanism problem: large language models can produce syntactically correct code that still fails security tests. That is not just a code-quality issue. It creates downstream risk when insecure patterns, weak input handling, or unsafe authentication logic are copied into production at scale. In security terms, the model output becomes a trust boundary problem because reviewers may assume generated code is safer than it is. The issue is compounded when teams use AI to accelerate delivery without pairing that acceleration with equivalent assurance.

Practical implication: treat AI-generated code as untrusted input until it passes the same security gates as human-written code.

Software supply chain risk in third-party code

Software supply chain risk increases when organisations rely on open-source packages, externally maintained components, and opaque build dependencies. The attack surface is not just malicious packages. It also includes dependency confusion, compromised maintainer accounts, and embedded secrets or tokens inside code and pipelines. Once a dependency enters a trusted build path, it can affect many downstream applications at once. That is why supply chain governance is really a question of provenance, integrity, and runtime trust, not just package selection.

Practical implication: enforce dependency provenance checks, signed artefacts, and secret scanning across the build chain before code reaches production.

Cloud security and application security posture management

The article frames cloud security as a visibility and governance challenge, especially in multi-cloud environments where teams struggle to correlate application risk with cloud exposure. Application Security Posture Management helps by centralising findings, but it only works if the underlying telemetry is consistent and the remediation workflow is operationally owned. The deeper issue is that cloud controls and application controls are often managed separately even though identity, configuration, and workload exposure interact continuously. That leaves blind spots from code to cloud.

Practical implication: connect cloud posture, application risk, and identity controls into one operating model rather than separate reporting streams.

Threat narrative

Attacker objective: The attacker aims to turn trusted software delivery and cloud automation into a scalable path for code compromise, credential abuse, and environment-wide exposure.

1. Entry occurs when vulnerable AI-generated code, compromised dependencies, or exposed cloud services are introduced into trusted development and deployment paths.
2. Escalation follows when those weaknesses expose secrets, insecure logic, or over-privileged access that attackers can use to move deeper into the environment.
3. Impact arrives as code execution, data theft, cloud compromise, or downstream breach spread across applications that inherited the same dependency or access pattern.

NHI Mgmt Group analysis

AI security has moved from model risk to pipeline risk. The Black Hat themes show that organisations can no longer treat AI as a discrete governance issue. When AI writes code, recommends remediation, or assists in pipeline decisions, security assurance must cover the entire software lifecycle, including identity, access, and secrets that govern build systems. The practical conclusion is that AI security and application security are now operationally inseparable.

Software supply chain governance is really identity governance in disguise. Third-party packages, maintainer accounts, CI/CD tokens, and build-time secrets all create trust relationships that attackers can abuse. That is why an NHI lens belongs here: service accounts, API keys, and automation tokens are the identities that keep modern pipelines running. The field should treat dependency integrity and credential integrity as the same control problem, not separate disciplines.

Cloud blind spots persist because security telemetry is fragmented across tools and teams. ASPM can improve prioritisation, but it does not remove the need for ownership across code, workload, and identity layers. The real governance gap is not the lack of alerts. It is the absence of a single operational view of which assets, identities, and pipelines can change production state. Practitioners should therefore judge cloud security by control continuity, not by tool count.

Named concept: code-to-cloud trust gap. This article illustrates the growing gap between where code is created and where it is trusted to operate. AI-generated code, third-party dependencies, and cloud deployment paths all inherit trust faster than they are validated. That gap is now a category-level risk for application security and identity governance alike, so practitioners need shared controls across development and runtime.

What this signals

The operational signal for security teams is that AI code generation and cloud delivery are converging into a single control plane problem. If generated code, dependency ingestion, and deployment identities are not governed together, the organisation will keep discovering issues after they are already live. Code-to-cloud trust gap: the window between code creation and code trust is now large enough for exposure to slip through review and posture management alike.

The strongest programmes will start measuring whether remediation, ownership, and identity governance move together. That means linking secret management, pipeline identity review, and application risk prioritisation to a single set of operational outcomes. Our research shows leaked secret remediation can still take 27 days, which is too slow for modern delivery cycles.

For practitioners, the next step is to stop treating ASPM, cloud posture, and IAM as separate reporting layers. The practical question is whether the team can identify every identity that can change code, build, or deploy state, then verify that those identities are continuously scoped and monitored through NIST SP 800-53 Rev 5 Security and Privacy Controls.

For practitioners

• Harden AI code review gates Require security scanning, secret detection, and policy checks on all AI-generated code before merge. Treat generated code as a separate trust class until it is validated in the same pipeline as human-authored code.
• Inventory pipeline identities and secrets Map every CI/CD token, service account, and API key that can change build or deployment state. Rotate or revoke anything that lacks a clear owner, expiry rule, or least-privilege scope.
• Verify software provenance end to end Use signed artefacts, dependency locking, and package source verification to reduce the chance that a trusted build ingests malicious or tampered components.
• Unify cloud and application risk triage Connect ASPM findings with cloud posture and identity telemetry so the team can see whether a code issue, misconfiguration, or credential problem is the real entry path.

Key takeaways

• Black Hat 2025 showed that AI security, software supply chain risk, and cloud governance are now one connected control problem.
• AI-generated code remains unsafe without security gates, and identity-bearing pipeline secrets and tokens remain central to that risk.
• Practitioners should unify code review, dependency trust, and identity governance before asking for faster AI-assisted delivery.

Key terms

• Code-to-Cloud Gap: The disconnect between what exists in source code and what is reachable or risky in production. Closing that gap means connecting repository findings to runtime exposure, privilege scope, and cloud context before prioritising remediation.
• Identity Security Posture Management: Identity security posture management is the continuous assessment of identity configuration, privilege, and exposure across an environment. It focuses on drift, overprivilege, and control gaps so teams can see where IAM, PAM, and NHI governance are failing before those gaps become incidents.
• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.

What's in the full article

Veracode's full article covers the conference themes and product context this post intentionally leaves for the source:

• Veracode’s conference recap of AI, supply chain, and cloud sessions across Black Hat USA 2025.
• Discussion of the GenAI Code Security Report and the broader findings behind the nearly half failed security tests result.
• Context on the ASPM enhancements and integrations referenced in the article, including how the vendor positions them operationally.
• The specific threat-research example involving malicious packages and developer-machine compromise that was only briefly referenced here.

👉 Veracode’s full post covers the GenAI Code Security Report, ASPM context, and the conference themes in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It is designed for practitioners who need to connect identity controls to broader security operations.