Application risk management is shifting toward identity-aware controls

At a glance

What this is: Veracode frames application risk management as a closed-loop approach to finding, prioritising, and reducing exploitable surface across discovery, prevention, detection, and remediation.

Why it matters: For IAM, PAM, and NHI practitioners, the important signal is that application exposure, dependency risk, and identity abuse now converge in the same risk path and need coordinated governance.

By the numbers:

• Veracode EASM discovers 50–100% more internet-facing assets than traditional methods.
• 27 days

👉 Read Veracode's CISO executive briefing on application risk management and cyber threats

Context

Application risk management fails when teams cannot see the full attack surface, cannot prioritise exploitable issues, and cannot connect application exposure to identity abuse. In this article, application risk management is positioned as an operational control problem, not just a scanning problem, because the same access paths that expose applications also expose credentials, dependencies, and data.

The identity angle is real, even though the article is broader than IAM. Perimeter access, third-party compromise, malicious packages, and runtime application exposures all become more dangerous when secrets, service accounts, tokens, or privileged application paths are not governed as part of the same control plane. That is why application risk management increasingly overlaps with NHI governance and privileged access oversight.

Key questions

Q: How should teams reduce identity risk in cloud supply chain attacks?

A: Start by inventorying every developer and automation identity that can reach repositories, build systems, and cloud roles. Then remove unnecessary permissions, segment trust between environments, and monitor for unusual token use or role assumptions. The goal is to make stolen credentials less reusable across the delivery chain and to shrink the blast radius of any one compromise.

Q: Why do exposed internet-facing assets increase the chance of identity abuse in application environments?

A: Because exposed assets often become the first place attackers test for weak trust, stale credentials, or overlooked administration paths. Once an application or edge service is reachable, the attacker only needs one weak identity control, such as an exposed secret or over-privileged service account, to turn visibility into access and access into impact.

Q: What do security teams get wrong about SCA and dependency governance?

A: They often treat SCA as a visibility tool rather than an enforcement mechanism. Knowing what is in use is not the same as stopping bad packages from entering the environment. Strong governance blocks risky dependencies at ingestion, tracks what was prevented, and reserves SBOMs for traceability and audit support rather than relying on them as the primary control.

Q: Who is accountable when application risk leads to data theft or ransomware?

A: Accountability spans application security, identity governance, and platform ownership because the failure is usually cross-functional. If exposure came from unmanaged external assets, dependency intake, or privileged access paths, the programme owner must be able to show who owned discovery, who approved trust, and who controlled remediation before the incident became material.

Technical breakdown

External attack surface discovery and why blind spots persist

External attack surface management, or EASM, identifies internet-facing assets that internal inventories often miss, including domains, APIs, certificates, and shadow infrastructure. The technical issue is not discovery alone, but the gap between what exists and what security tools can continuously validate. Attackers use that gap to find forgotten edge devices, exposed subdomains, and untracked services that sit outside routine control coverage. Once those assets are visible, they can be tied to runtime testing and prioritisation workflows rather than treated as isolated findings.

Practical implication: teams need continuous external discovery tied to validation, not periodic asset reviews.

Why supply-chain controls must intercept packages before build time

Software composition analysis, or SCA, tells teams which dependencies are present and where known risk lives, but that is insufficient when malicious or non-compliant packages are introduced upstream. Package firewalling adds a control point before code reaches the development environment, which matters because dependency risk often enters through trusted workflows rather than overt attack traffic. The architectural point is that prevention must sit in the path of acquisition, not only in the path of detection. SBOM generation helps after the fact, but it does not block first use.

Practical implication: move dependency policy enforcement to the ingestion layer, not only the scanning layer.

How detection, remediation, and prioritisation form one control loop

Static analysis, dynamic analysis, and remediation automation work best when findings are normalised into a single risk workflow. SAST identifies code-level weaknesses, DAST validates whether they are reachable in runtime, and remediation tooling shortens the time from finding to fix. The important architectural pattern is closed-loop operation: discover, validate, prioritise, patch, and measure. Without that loop, teams accumulate findings without reducing exploitability. This is especially relevant where applications expose privileged data or depend on externally reachable interfaces.

Practical implication: build one workflow from detection to fix, with prioritisation based on exploitability and business exposure.

Threat narrative

Attacker objective: The attacker wants to turn application exposure and identity weakness into high-value access for extortion, theft, or operational disruption.

1. Entry occurs through exposed perimeter devices, untracked external assets, or a third-party compromise that gives attackers a reachable path into the environment.
2. Escalation follows when malicious packages, exposed secrets, or weak application controls let the attacker move from initial access to privileged application or data paths.
3. Impact is delivered through ransomware, data exfiltration, or extortion once the attacker reaches applications, credentials, or sensitive records that were not governed as a single risk domain.

Breaches seen in the wild

• New York Times breach — New York Times source code and credentials exposed via GitHub.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Application risk management is now an identity governance problem as much as a code security problem. The article correctly links external exposure, supply-chain abuse, and runtime validation, but the deeper issue is who and what is trusted to reach privileged application paths. Secrets, service accounts, and third-party integrations are the identities that connect those layers. When they are not governed with the same discipline as human access, application risk becomes an identity problem by another name.

External visibility is becoming the first control, not the last report. Security programmes still overestimate what their inventories capture, especially across internet-facing assets, certificates, and shadow services. The named concept here is external blind spot debt: the cumulative risk created when discovery lags infrastructure growth. That debt is what attackers monetise first, so practitioners should treat discovery coverage as a measurable control outcome.

Supply-chain hardening now needs pre-build enforcement, not post-build analysis. SCA and SBOMs are useful, but they do not stop malicious or vulnerable dependencies from entering pipelines in the first place. The control question is whether governance reaches the acquisition point, where package trust is actually decided. In practice, this means policy needs to operate at ingestion, not only at inspection.

Runtime validation matters most when applications protect privileged data or high-leverage workflows. DAST and related testing only change outcomes when they are tied to prioritisation and remediation workflows, not left as isolated assurance steps. This is where application security and PAM intersect: the more sensitive the application path, the more important it is to validate whether access is actually necessary and whether privileges are bounded. Practitioners should align runtime validation with blast-radius reduction.

Closed-loop remediation is the difference between visibility and risk reduction. The market increasingly sells more signals, but teams need fewer unresolved exposures. Application risk management becomes meaningful when discovery, testing, patching, and reporting share one operational loop. That is the governance model practitioners should expect to underpin modern AppSec programmes.

From our research:

• From our research, companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to The State of Secrets in AppSec.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• For a broader identity lens, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the lifecycle controls that reduce exposure windows.

What this signals

Application security teams should expect tighter convergence between EASM, dependency control, and identity governance. The practical signal is that secret exposure, external attack surface, and privileged application paths will be assessed together, not as separate risk domains. That makes lifecycle discipline for service accounts and tokens increasingly important in any programme that also manages externally reachable applications.

External blind spot debt: if discovery does not keep pace with cloud expansion, third-party integrations, and certificate sprawl, risk accumulates faster than remediation capacity. Practitioners should measure how quickly unknown assets become known, then known assets become tested, and finally tested assets become fixed.

This also pushes teams toward more defensible risk reporting. Boards do not need more vulnerability counts. They need evidence that the organisation can reduce exploitable exposure across applications, dependencies, and the identities that connect them.

For practitioners

• Inventory external assets continuously Run continuous discovery across domains, APIs, certificates, and edge services so that internet-facing exposure is measured against reality rather than stale asset records.
• Shift dependency policy left of build time Enforce package acceptance rules before dependencies enter the development environment, and tie them to SBOM review and vulnerability suppression policies.
• Correlate runtime validation with privileged access paths Prioritise DAST and targeted testing on applications that expose sensitive data, privileged workflows, or externally reachable administration surfaces.
• Measure remediation by exposure reduction, not ticket volume Track how many exploitable findings are removed from business-critical applications, and connect that metric to executive risk reporting.

Key takeaways

• Application risk management is becoming a connected problem across discovery, dependencies, runtime exposure, and identity governance.
• The strongest practical signal in the article is that visibility alone is not enough. Controls have to block, validate, and remediate in one loop.
• Practitioners should treat external asset discovery, package enforcement, and privileged path validation as one programme, not separate workstreams.

Key terms

• Attack Surface Management: Attack surface management is the practice of finding and evaluating assets that could be exposed to misuse or compromise. CAASM focuses on internal visibility across the environment, while EASM focuses on externally reachable assets. It is a discovery discipline, not a complete identity control model.
• Package Firewall: A package firewall is a control that blocks or screens software packages before they enter a development or build environment. It is used to prevent vulnerable, malicious, or non-compliant dependencies from reaching downstream pipelines where later detection may be too late to reduce risk.
• Business Application Risk Management: Business Application Risk Management is the discipline of identifying and controlling access risk inside ERP, CRM, and other operational platforms. It looks at the real actions an application allows, then evaluates whether combinations of entitlements, workflow steps, and exceptions create audit or security exposure.
• External Blind Spot Debt: External blind spot debt is the accumulated risk created when new internet-facing assets, certificates, APIs, or shadow services are added faster than security teams can discover and validate them. The longer the gap persists, the more likely attackers are to find a reachable path before defenders do.

What's in the full article

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

• Specific workflow examples for EASM, SCA, SAST, DAST, Fix, and Risk Manager in one operating model
• Implementation guidance for Package Firewall policy enforcement before dependencies reach development environments
• Prioritisation and remediation mechanics for turning exploitability data into executive risk reporting
• Step-by-step actions for operationalising the 30, 60, and ongoing day recommendations

👉 Veracode's full report covers the asset discovery, dependency blocking, and remediation workflow details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is designed for practitioners who need a stronger governance model across access, privilege, and automation.