Software concentration risk is hiding beneath vendor assessments

At a glance

What this is: This is Kusari's analysis of why software supply-chain risk sits below conventional vendor due diligence, and why provenance plus dependency visibility are now governance requirements.

Why it matters: It matters because IAM, PAM, and broader security teams increasingly depend on third-party software whose real blast radius often sits in transitive components, not the supplier relationship alone.

By the numbers:

• 2024 CrowdStrike outage to US Fortune 500 companies
• $1.149 billion of the CrowdStrike outage costs, outage costs, according to Parametrix.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read Kusari's analysis of software concentration risk, provenance, and blast radius

Context

Software supply-chain governance often stops at the supplier level, but that leaves the harder question unanswered: what is actually inside the software, which downstream systems depend on it, and how quickly can the blast radius be identified if something breaks? That gap matters whenever critical business services rely on third-party components, outsourced build pipelines, or transitive dependencies that are invisible in routine reviews.

In identity-heavy environments, the same pattern appears with service accounts, secrets, and other non-human identities. The control problem is not just who the vendor is, but what credentials, access paths, and embedded dependencies their software can reach once it is deployed. Kusari's example set shows that this is not a theoretical governance gap; it is already a practical limitation in resilience, concentration risk, and regulatory reporting.

For banks, insurers, and other regulated operators, the starting position described here is unfortunately typical rather than exceptional.

Key questions

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. A supplier can appear compliant while the delivered software still contains a widely reused vulnerable package or an altered release path. Effective governance needs component-level visibility, not just contract-level assurance.

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. One flaw can therefore propagate across multiple critical services at once. The risk is systemic, not isolated, and it often does not appear in a simple supplier list.

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. If teams can publish or install high-risk dependencies without verification, provenance exists only as metadata and not as an enforceable control.

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.

Technical breakdown

Why vendor assessments miss software blast radius

Vendor questionnaires measure contractual and control posture, but they do not expose the actual software graph. The real risk sits in the artifact, the build system, and the transitive dependency chain below the first layer of visibility. Most scanners read manifests and infer deeper components, which means they can describe what was declared, not what is truly present. That is why a supplier can look well governed while the embedded exposure remains unknown.

Practical implication: treat vendor assessment as one input and pair it with component provenance and dependency analysis.

Transitive dependencies and hidden concentration risk

Transitive dependencies are libraries and components that arrive through other dependencies rather than direct developer selection. They create hidden concentration because many applications can share the same vulnerable component without any obvious relationship at the procurement layer. This is why a single flaw or bad release can affect many institutions at once, even when each institution believes it has diversified its supplier base.

Practical implication: map shared third-party components across critical services before assuming supplier diversification reduces systemic exposure.

Why provenance matters more than artifact inspection alone

Artifact inspection looks at the finished package, while provenance checks where it came from and how it was built. That distinction matters because a signed or audited artifact can still be compromised in the release process, and a source repository may not match the delivered package. Provenance controls make the build chain answerable, which is the only way to distinguish a normal dependency from a manipulated one.

Practical implication: require build provenance and source-to-artifact comparison for software that supports regulated or high-availability services.

Threat narrative

Attacker objective: The objective is to maximise downstream disruption by exploiting trust in the software supply chain rather than attacking each victim directly.

1. Entry occurs when a vulnerable or compromised software component enters the environment through a trusted vendor release or a transitive dependency chain.
2. Escalation happens when the same underlying component is reused across many applications, turning one supplier event into broad operational impact.
3. Impact is the inability to size the blast radius quickly enough to contain service disruption, compliance exposure, or financial loss.

NHI Mgmt Group analysis

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.

Blast-radius governance is now a resilience control. If an organisation cannot answer which systems, counterparties, or customers are exposed within a reasonable window, it cannot claim effective concentration-risk management. That is why this topic sits at the intersection of cyber resilience, operational continuity, and auditability. The control gap is not just visibility, but answerability under pressure, which is what regulators are increasingly testing.

Software provenance is the missing assurance layer. Scanners and inventories are useful, but they are not enough when the compromise sits in the build chain or in transitive code. The named concept here is provenance blindness: the inability to prove where a component came from, how it was assembled, and whether the delivered artifact matches trusted source. Practitioners should treat provenance blindness as a governance defect, not a tooling inconvenience.

Identity and supply-chain governance now overlap in the same failure mode. Once third-party software reaches runtime, it often carries secrets, service accounts, tokens, and privileged integrations with it. That means software concentration risk is also non-human identity concentration risk, because the compromised component may expose access paths far beyond the original application boundary. Practitioners should bring IAM and NHI controls into software supply-chain reviews, not leave them in separate workstreams.

What this signals

Provenance blindness will become a recurring governance failure in regulated software estates, especially where teams can inventory suppliers but not the build chain or transitive dependencies. That gap will force security leaders to connect software supply-chain controls with identity controls, because third-party packages often arrive with service accounts, tokens, and other runtime access paths.

Regulatory pressure is also moving from policy statements to answerable evidence. For financial services teams, that means concentration risk, outsourcing registers, and recovery objectives must be backed by artifact-level traceability, not just vendor attestations. The practical test is whether the programme can name the affected services, data paths, and identity exposures within the response window, not after an investigation closes.

For practitioners

• 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. Use the inventory to answer blast-radius questions quickly instead of relying on procurement records alone.
• Map shared dependencies across critical services Identify components reused across high-value systems, regulated workloads, and customer-facing platforms. Shared components should be treated as concentration points, especially where a single update could affect multiple business units.
• 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. Signed outputs alone do not prove trustworthy provenance.
• Tie software risk to non-human identity controls Review whether third-party software introduces service accounts, API keys, tokens, or privileged connectors that extend the blast radius. Reconcile those identities with ownership, rotation, and offboarding controls before production deployment.

Key takeaways

• Supplier due diligence alone does not reveal the real blast radius of third-party software.
• Transitive dependencies and build provenance are the controls that determine whether an organisation can answer exposure questions quickly.
• Identity governance and software supply-chain governance now overlap wherever third-party software carries runtime secrets or privileged access.

Key terms

• 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.
• 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.
• Concentration risk: The risk that too much operational dependence sits with one ICT provider or one tightly linked provider chain. For AI environments, concentration risk matters when the same model supplier, hosting layer, or API backbone underpins multiple business functions and becomes difficult to replace quickly.

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.

👉 The full Kusari article covers concentration-risk examples, regulatory obligations, and software inventory limitations in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is suitable for practitioners who need to connect identity controls to broader security and resilience programmes.