Notifications
Clear all
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.
NHIMG editorial — based on content published by Kusari: software concentration risk, provenance, and the limits of vendor assessments
By the numbers:
- Parametrix put the direct cost of the July 2024 CrowdStrike outage to US Fortune 500 companies, excluding Microsoft, at $5.4 billion.
- Banking took $1.149 billion of the CrowdStrike outage costs, according to Parametrix.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
Questions worth separating out
Q: What breaks when software supply-chain risk is assessed only at the vendor level?
A: You miss the transitive dependencies, build provenance, and shared components that determine real blast radius.
Q: Why do transitive dependencies create concentration risk?
A: Because many organisations can unknowingly rely on the same hidden component through different vendors, applications, or build pipelines.
Q: How do security teams know if provenance controls are actually working?
A: Look for two signals: packages are rejected when provenance is absent or mismatched, and release workflows only succeed from approved source commits and runners.
Practitioner guidance
- Inventory software by provenance, not just supplier Build a component inventory that records source, build path, transitive dependencies, and the business services each artifact supports.
- Map shared dependencies across critical services Identify components reused across high-value systems, regulated workloads, and customer-facing platforms.
- Require source-to-artifact verification Compare delivered artifacts against the source and build system that produced them, especially for software that processes sensitive data or supports availability-critical operations.
What's in the full article
Kusari's full article covers the operational detail this post intentionally leaves for the source:
- A deeper breakdown of how concentration risk is assessed across internal, systemic, geographic, and interdependency dimensions.
- Examples of how scanners miss transitive dependencies and why source-to-artifact comparison changes the answerability of blast radius.
- The regulatory mapping behind DORA, NYDFS Part 500.13, and PCI DSS requirement 6.3.2 for software inventories.
- The practical distinction between vendor questionnaires, component inventories, and provenance verification.
👉 Read Kusari's analysis of software concentration risk, provenance, and blast radius →
Blast radius in third-party software: are your controls enough?
Explore further
19/08/2026 4:09 pm
Vendor trust is not the same as software trust. Third-party risk programmes have historically focused on the supplier as an organisation, but concentration risk is increasingly created by the software object itself. A vendor can pass questionnaires, hold certifications, and still ship software whose internal dependency graph creates a hidden systemic exposure. Practitioners should therefore govern the software path, not only the supplier relationship.
A question worth separating out:
Q: Who is accountable when third-party software causes business disruption?
A: Accountability should sit with the business owner of the service, the security team that approved the risk, and the procurement or vendor management process that recorded the assurance. Under resilience and outsourcing regimes, the organisation remains responsible even when the failure originates in a supplier or sub-supplier.
👉 Read our full editorial: Software concentration risk is hiding beneath vendor assessments
