Topic starter
19/08/2026 3:25 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Kusari: “What CrowdStrike, Travelex and Synapse tell us about blast radius in financial services.”.
By the numbers:
- Parametrix put the direct cost of the July 2024 CrowdStrike outage to US Fortune 500 companies at $5.4 billion.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Traditional vendor assessments are not enough when multiple critical services depend on the same software path.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:09 pm
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.
A few things that frame the scale:
- 40 percent of financial and software companies have already deployed agentic AI systems, and deployments are expected to double by 2028.
A question worth separating out:
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.
👉 Read our full editorial: Software concentration risk is hiding beneath vendor assessments