TL;DR: Concentration risk, transitive dependencies, and software provenance matter more than vendor questionnaires because a single update, failure, or backdoor can expose thousands of downstream systems, according to Kusari. The core issue is that most programmes can describe the supplier, but cannot answer blast-radius questions fast enough to govern the software they rely on.
At a glance
What this is: This is an analysis of why third-party software concentration risk is hidden by traditional vendor assessments, with the key finding that blast radius often sits in transitive dependencies and shared build artefacts rather than supplier questionnaires.
Why it matters: It matters because IAM, PAM, NHI, and broader cyber governance teams need to know which software exposures can cascade across many services, counterparties, or customers before an incident forces that answer.
By the numbers:
- Parametrix put the direct cost of the July 2024 CrowdStrike outage to US Fortune 500 companies at $5.4 billion.
Context
Third-party software risk is not limited to the supplier contract, the security questionnaire, or the audit badge. The operational problem is that many programmes can describe who supplied the software, but cannot rapidly determine what that software contains, where it is embedded, or how widely a failure would spread across dependent systems.
That gap matters most when software is concentrated across critical functions, shared infrastructure, and regulated service chains. In financial services, the governance question is increasingly about provenance, transitive dependencies, and recovery scope, not just vendor due diligence or assurances about controls.
Key questions
Q: What breaks when third-party software concentration risk is not in place?
A: Teams lose the ability to answer which services, customers, or counterparties are exposed when a shared component fails or is compromised. The practical failure is not only outage severity, but delayed triage because the organisation cannot trace dependency depth, provenance, or interdependent services fast enough to contain the blast radius.
Q: Why does software provenance matter more than vendor questionnaires for concentration risk?
A: Questionnaires describe supplier posture, but provenance shows what actually ships and where shared dependencies live. If two organisations buy from the same trusted vendor, but one has deeper transitive exposure or a more concentrated build path, the real risk profile is different. Provenance turns governance from trust into evidence.
Q: How do security teams know whether blast-radius controls are working?
A: Blast-radius controls are working when a compromised identity can no longer reach systems outside its normal operational purpose. Look for blocked anomalous sources, denied protocol use, and reduced lateral movement options. If a stolen credential still behaves like a universal pass key, the control model is not actually containing risk.
Q: What is the difference between supplier risk and software concentration risk?
A: Supplier risk asks whether a vendor is trustworthy and resilient. Software concentration risk asks whether many critical services depend on the same underlying software path, dependency chain, or update mechanism, creating correlated exposure even when each individual supplier appears acceptable on paper.
Technical breakdown
Why vendor assessments miss concentration risk
Vendor questionnaires answer procurement questions, not software dependency questions. A supplier can be financially stable, attest to controls, and still distribute software whose downstream blast radius is far larger than its contract surface suggests. Concentration risk emerges when many organisations depend on the same product, update channel, build pipeline, or managed service, so a single defect or compromise creates correlated impact. The core technical blind spot is that most reviews stop at the supplier boundary and never inspect the artefact, dependency tree, or provenance chain that actually delivers the code. Practical implication: assess the software substrate, not just the vendor relationship.
Practical implication: build controls that inventory artefacts, dependencies, and provenance, not just suppliers.
Transitive dependencies and hidden software provenance
Transitive dependencies are components brought in by other components, often several layers below the package a developer chose directly. They are difficult to see because standard scanners usually read manifests and resolve only the shallowest layers of the tree, leaving deeper dependencies implicit or invisible. That means the highest-risk components can sit outside the obvious inventory even when a team believes it has coverage. Provenance matters because the artefact that runs in production may not be identical to the source repository that reviewers inspected. Practical implication: verify the build chain and component lineage, not only the final package list.
Practical implication: verify build provenance and deep dependency lineage before treating an inventory as complete.
Blast radius is the operational question regulators now expect answered
The governance shift is toward impact analysis: which services, customers, counterparties, or regulated functions are exposed if a component fails tonight. That requires a live mapping between software assets, their owners, their recovery expectations, and the interdependencies that connect them. In financial services, this is where concentration risk, recovery time objectives, and sub-outsourcing obligations intersect. A static register is not enough if teams cannot tell what breaks, what depends on what, and how quickly restoration can happen. Practical implication: tie asset inventory to recovery planning and supplier interdependency mapping.
Practical implication: connect asset inventory to recovery objectives and dependency mapping so blast radius is answerable quickly.
Threat narrative
Attacker objective: The objective is not always a deliberate attacker outcome, but the practical effect is the same: a single software failure or compromise creates outsized, correlated disruption across many downstream systems.
- Entry occurs when a trusted software update, dependency, or build artefact introduces the failure path into downstream environments.
- Credential or privilege abuse is not required in this pattern because the trust relationship itself provides the propagation route.
- Impact follows when many dependent organisations inherit the same defect, outage, or backdoor and cannot quickly determine their own exposure.
Breaches seen in the wild
- Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.
- JumpCloud breach 2023: North Korean hackers breached JumpCloud and abused its device commands framework against a few customers; all admin API keys were reset.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Software concentration risk is the real control gap, not supplier trust. Most third-party reviews still measure whether a vendor looks acceptable, but the operational failure mode is correlated exposure across many customers through the same software path. Once the same dependency, update channel, or service layer sits under multiple critical functions, the question becomes blast radius, not procurement comfort. Practitioners should treat concentration as a governance property of the software estate, not a vendor rating exercise.
Provenance is now a governance control, not a build-team detail. If teams cannot distinguish source, build output, and shipped artefact, they cannot explain why signed software still caused broad harm in cases like CrowdStrike or SolarWinds. That is why artifact lineage, dependency depth, and reproducible build evidence belong in third-party oversight. Security leaders should require provenance evidence as part of operational assurance.
Blast-radius visibility is the named concept that matters here. The industry needs a disciplined way to answer, in minutes rather than days, which regulated services, customers, and counterparties inherit risk from a shared component. That concept bridges supply chain governance, resilience planning, and identity-aware access to software systems, because the same dependency graph often governs both runtime trust and administrative reach. Practitioners should make blast-radius visibility a first-class control objective.
Financial services is where concentration risk becomes measurable governance debt. DORA, NYDFS, and similar regimes force firms to move beyond annual questionnaires and toward executable inventories, recovery objectives, and sub-outsourcing mapping. The challenge is not just compliance wording but whether the organisation can evidence what it would be forced to fix under stress. Security and compliance teams should use regulation as a forcing function to eliminate blind spots in dependency governance.
Identity teams cannot stay at the edge of this problem. Where software concentration risk governs who can update, deploy, or recover a critical component, privileged access becomes part of the blast-radius story. That makes PAM, service account control, and operational ownership part of software provenance governance. Practitioners should join software concentration reviews with identity and privilege governance rather than running them separately.
From our research library:
- 40 percent of financial and software companies have already deployed agentic AI systems, and deployments are expected to double by 2028.
What this signals
Blast-radius visibility: this is becoming the practical control objective behind third-party software governance. The teams that can answer exposure questions quickly will handle outages, vulnerabilities, and supplier incidents with far less organisational drag than those still relying on static questionnaires.
Financial services programmes should expect concentration risk reviews to move closer to operational resilience and privileged access governance. If a software component can affect many regulated services at once, then dependency mapping, ownership, and recovery planning become a single control problem rather than three separate reviews.
For practitioners
- Map software concentration across critical services Identify where the same vendor, component, package, or managed service appears across multiple regulated or business-critical functions, then rank those shared dependencies by potential correlated impact.
- Extend inventories beneath the vendor boundary Capture transitive dependencies, build artefacts, and sub-outsourcing chains so the inventory reflects what is actually deployed, not just what procurement approved.
- Require provenance evidence for shipped artefacts Ask for source-to-build-to-release traceability so you can distinguish the code that was reviewed from the package that was delivered into production.
- Tie recovery objectives to dependency maps Link each critical asset to an owner, an RTO, and the upstream software relationships that would determine whether restoration is realistic under stress.
- Bring privileged access into third-party governance Review who can modify, deploy, or recover shared software components, because administrative control over a concentrated dependency can enlarge the blast radius as much as the code itself.
Key takeaways
- Traditional vendor assessments are not enough when multiple critical services depend on the same software path.
- The most important exposure often sits in transitive dependencies and build artefacts rather than the supplier questionnaire.
- Practitioners need a blast-radius view that links software lineage, ownership, and recovery planning.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006 — Credential Access | Software concentration incidents often begin by abusing trusted update or software delivery paths. |
| Recommendation — Map trusted software delivery paths to TA0006 and hunt for compromise in update and build channels. | ||
| NIST CSF 2.0 | GV.SC-01 — Supply Chain Risk Management | The article is fundamentally about supply chain governance and correlated third-party exposure. |
| PR.DS-04 — Information is managed consistent with the risk strategy and organizational roles and responsibilities | The article stresses provenance, inventory, and ownership of software assets. | |
| Recommendation — Apply supply-chain governance to inventory upstream dependencies and concentration points across critical services. Align software inventory and provenance controls to risk ownership so exposure can be traced and assigned. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Third-party software concentration risk sits squarely in provider oversight and dependency governance. |
| Recommendation — Use service-provider management to record upstream dependencies, sub-outsourcing, and recovery obligations. | ||
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | This control directly addresses provenance, acquisition, and integrity of external software components. |
| Recommendation — Apply supply-chain protection controls to verify software provenance and reduce hidden dependency exposure. | ||
Key terms
- Software Concentration Risk: The risk that many systems, customers, or business functions depend on the same software component, supplier, or update path. A failure, defect, or compromise then creates correlated impact across the estate rather than a single isolated incident.
- Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
- Software provenance: Software provenance is the evidence that shows where an artifact came from, who created it, and whether it was altered before use. For security teams, it means signed releases, controlled build paths, and verification steps that reduce the chance of trusted software carrying hidden malicious changes.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
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 identity and security practitioners connect access control with the broader governance problems that software concentration risk exposes.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org