Application risk intelligence now hinges on identity and supply chain

At a glance

What this is: This is a board-level application risk briefing that says exploitation is accelerating, supply chain attacks are evolving, and identity abuse is now central to successful intrusion paths.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern developer tooling, service accounts, tokens, and AI-related credentials as part of the application attack surface.

By the numbers:

• The top 10 ransomware groups account for approximately 71% of claimed victims.
• North Korean-linked actors published more than 100 malicious packages and extensions across npm, Packagist, Go, and Chrome ecosystems.

👉 Read Veracode's July 2026 application risk intelligence briefing

Context

Application risk intelligence is becoming an identity problem as much as a code problem. The briefing describes a world where attackers reach production through stolen CI/CD credentials, compromised maintainer accounts, session theft, and AI-assisted chaining of vulnerabilities faster than most programmes can triage them.

For IAM and NHI teams, the operational boundary has moved. Service accounts, tokens, package-manager credentials, AI agent credentials, and developer workflow access now sit inside the same risk envelope as human access because they can all become initial-access pathways, persistence mechanisms, or supply-chain amplifiers.

Key questions

Q: What breaks when identity is embedded into CI/CD without governance?

A: Configuration changes can propagate quickly, but so can mistakes, stale privileges, and inconsistent exceptions. Without pipeline-based approval, testing, and review, identity-as-code becomes a fast path for replicating weak controls at scale. The main failure is not automation itself, but unmanaged automation.

Q: Why do service accounts and vendor access increase ransomware risk?

A: Service accounts and vendor identities often have broad, persistent, and poorly reviewed access, which makes them ideal for lateral movement after initial compromise. If those accounts are not tightly scoped, monitored, and offboarded, attackers can use trusted paths to reach critical systems and amplify disruption far beyond the first infected machine.

Q: How do security teams know whether contextual prioritisation is working?

A: Look for shorter remediation times on externally exposed and credential-bearing systems, fewer high-risk findings waiting across multiple cycles, and a clear drop in unowned critical items. If the programme still treats all critical issues similarly, the prioritisation model is not reflecting real attacker behaviour.

Q: Who is accountable when an AI agent uses delegated access incorrectly?

A: Accountability should follow the delegated authority chain, not stop at the agent label. The relevant owners are the teams responsible for the human identity, the service identity, the workflow, and the policy that allowed the action path. If those responsibilities are not explicit, incident review will be incomplete and remediation will focus on the wrong layer.

Technical breakdown

Why exploitation velocity now outpaces weekly patch cycles

The briefing shows a material change in attacker timing. Maximum-severity flaws are being weaponised within hours, which compresses the available response window and reduces the value of traditional batch patching. Contextual risk scoring becomes essential because not every critical-severity issue carries the same exposure, especially when internet-facing assets, known exploitation, and privileged pathways line up. For identity programmes, that same timing pressure applies to exposed credentials and session tokens: once they are live, adversaries do not wait for the next review cycle.

Practical implication: tie prioritisation to exposure, privilege, and exploitability rather than severity alone.

How supply-chain compromise shifts from packages to identities

The article describes a move from opportunistic package poisoning toward compromise of registries, CI/CD credentials, maintainer accounts, and developer tooling. That matters because the trust anchor is no longer only the code artifact. It is the identity that publishes, signs, pulls, and promotes that artifact through the pipeline. When attacker access lands in GitHub, package registries, or build runners, the resulting blast radius can extend across multiple applications before a malicious change is even visible in source control.

Practical implication: treat pipeline credentials and maintainer identities as production-grade assets with lifecycle control.

Why AI-driven attack chains change the control model

The briefing points to AI-assisted vulnerability research and the first confirmed end-to-end agentic ransomware as evidence that automation is now part of the attack chain, not just the defense chain. In practice, this means discovery, credential correction, lateral movement, and payload execution can happen with far less human delay. The governance question is no longer whether an AI system can write code or call tools, but whether its identities, permissions, and delegation paths are bounded tightly enough to prevent autonomous misuse.

Practical implication: inventory AI agent credentials and enforce least privilege before autonomous workflows scale.

Threat narrative

Attacker objective: The attacker aims to convert trusted identities in software delivery and operational tooling into broad, repeatable access for theft, extortion, or downstream compromise.

1. Entry begins with exposed or stolen credentials in CI/CD systems, package ecosystems, VPN appliances, or phishing kits that bypass ordinary perimeter controls.
2. Escalation follows when those identities carry standing privilege, maintainer trust, or session persistence that lets attackers move from one toolchain component to another.
3. Impact is achieved through supply-chain propagation, ransomware deployment, data theft, or AI-assisted chaining that compresses the intrusion into minutes.

NHI Mgmt Group analysis

Identity is now the primary control plane of application risk. The briefing’s strongest signal is not the number of vulnerabilities but the way attackers keep winning through trusted identities embedded in build, release, and runtime workflows. Service accounts, tokens, and maintainer credentials are no longer supporting controls, they are attack objectives. That aligns with OWASP NHI thinking and NIST CSF access governance, and it means application security and identity governance can no longer operate as separate programmes.

Supply-chain risk is becoming a governance problem about provenance and delegation, not just malware scanning. Package blocking matters, but the deeper issue is who can publish, sign, promote, and execute code across environments. The article points to a pipeline trust gap: identities in CI/CD now carry production-like authority without production-like oversight. Practitioners should read that as a warning that provenance controls must extend to the human and non-human identities behind every artifact.

Agentic AI expands the attack surface by creating new identities that can act faster than review cycles. The briefing’s agentic ransomware references show why AI security and identity governance are converging. An AI agent is not risky simply because it uses tools. It becomes risky when its credentials, delegation chain, and runtime permissions allow unattended action across systems. That creates a control problem for IAM, PAM, and NHI teams, not just for MLOps.

Contextual remediation will outperform blanket remediation as exploit windows shrink. When exploitation happens in hours, the programme that wins is the one that can correlate exposure, identity privilege, and business criticality in near real time. Traditional vulnerability management still matters, but it is no longer sufficient on its own. The practical conclusion is that prioritisation, not just detection, is now the differentiator in residual risk reduction.

Ransomware concentration reflects control concentration failure. When a small number of groups account for a large share of victims, it usually means the same weak points keep surviving across enterprises. Session/token theft, device-code abuse, and over-privileged service identities are recurring enablers. The governance lesson is that reducing attack concentration requires shrinking the number of identities that can be abused at high speed.

What this signals

Pipeline trust gap: many AppSec programmes still assume the build system is a control boundary, when in practice it is now an identity boundary. That means the next wave of control improvements will come from governance of CI/CD accounts, signing identities, and AI-agent credentials, not from scanning alone. The practical shift is to align AppSec telemetry with IAM and PAM decisioning, using the NIST Cybersecurity Framework 2.0 as the organising model for exposure, protection, detection, and recovery.

The operational signal is that remediation strategy must become more identity-aware. When an issue touches a secret, token, or delegated workflow, the team should assume attacker dwell time is measured in minutes or hours, not review cycles. That is where controls from OWASP Non-Human Identity Top 10 become directly relevant to application security governance.

Programmes that can correlate vulnerability data with identity events will be better positioned to reduce residual risk. The most useful next step is to treat application risk, machine identity, and secrets exposure as one operating picture rather than three separate queues. That is the difference between seeing a weakness and actually shrinking the blast radius.

For practitioners

• Inventory pipeline and registry identities Map every CI/CD account, maintainer account, signing identity, token, and package-manager credential used to build or promote software. Classify which ones can publish, approve, or deploy, then remove any standing access that is not strictly necessary. Use the inventory to identify where a single compromised identity could affect multiple applications.
• Enforce contextual prioritisation for exploitable flaws Rank remediation by internet exposure, exploit activity, privilege path, and whether an affected component is reachable from identity-rich workflows such as build runners or package mirrors. Set faster SLAs for externally exposed assets and for systems that hold credentials, keys, or signing material.
• Treat AI agent credentials as governed identities Assign owners, scopes, expiration rules, and logging to any AI system that can call tools, read secrets, or move data between systems. Block broad delegation chains, review tool permissions explicitly, and separate experimental agents from production-connected workflows until their access model is proven.
• Harden secrets and session controls around developer workflows Rotate exposed secrets, shorten token lifetimes, and detect anomalous use of browser sessions, device-code authentication, and API keys in development environments. Focus on the places where attackers can turn a stolen session into persistent access before build or release controls notice.
• Unify AppSec and identity telemetry Correlate vulnerability findings with identity events from SSO, CI/CD, cloud IAM, and secrets stores so that teams can see when a flaw and a high-value credential intersect. This is especially useful for package ingestion, external attack surface, and runtime environments that depend on service accounts.

Key takeaways

• Application risk is now tightly coupled to identity governance because attackers increasingly enter through credentials, tokens, and delegated tool access.
• The evidence points to a shrinking exploitation window, with malicious activity often beginning within hours and sometimes within minutes of exposure.
• The most effective response is contextual remediation backed by secrets control, pipeline identity governance, and AI-agent access boundaries.

Key terms

• Pipeline Trust Gap: The mismatch between the trust a build or release system is given and the level of identity governance it actually receives. It appears when CI/CD accounts, signing identities, and automation tokens can change production outcomes without the monitoring, scope limits, or lifecycle controls usually reserved for privileged access.
• Contextual prioritisation: Contextual prioritisation ranks findings by exploitability, reachability, and business impact rather than by severity alone. This approach reduces alert fatigue and helps practitioners focus on the risks most likely to be used in a real attack path.
• Agentic Ransomware: Agentic ransomware is malware or a ransomware operation directed by an autonomous system that can plan, adapt, and change attack steps at runtime. The key difference is behavioural flexibility, which shortens response windows and makes rigid playbooks less effective.
• Supply-Chain Ingress: The entry point through which malicious code, altered dependencies, or compromised identities enter software delivery. It covers package repositories, developer tooling, CI/CD runners, and signing or publishing accounts, all of which can be abused before a defect becomes visible in production.

What's in the full report

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

• Specific package firewall policies for npm, PyPI, Maven, RubyGems, NuGet, Cargo, and Golang ecosystems
• Risk Manager and Fix workflow details for prioritising and remediating high-risk findings
• Pipeline integration guidance for GitHub, Azure DevOps, Jenkins, and CLI-based policy gates
• Action-oriented recommendations for board reporting, SLAs, and AI-related code controls

👉 Veracode's full briefing covers the incident signals, control recommendations, and response priorities in 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. It helps practitioners connect identity controls to the broader security programme they already run.