TL;DR: Anthropic’s Mythos tooling surfaced 26,153 candidate vulnerabilities, with 4,576 confirmed, about 2,300 disclosed, and only 421 patched, according to Black Kite, showing that discovery now outpaces remediation in third-party software. The practical risk is not flaw discovery itself, but vendor queue backlog, concentration risk, and the inability to govern what you cannot patch.
At a glance
What this is: Black Kite analyses Mythos disclosure data to show that vulnerability discovery is no longer the bottleneck, patching is.
Why it matters: For security, IAM, and NHI practitioners, the issue is that third-party exposure now depends on vendor remediation speed, dependency concentration, and whether your suppliers can actually fix what is found.
By the numbers:
- Black Kite says roughly 2,300 vulnerabilities were formally disclosed across 392 open-source projects, but only 421 have been patched.
- Black Kite reports that Anthropic’s dashboard showed a 91.4% true positive rate on external review.
Context
Mythos disclosure data is really a third-party governance story. The article shows that finding vulnerabilities at scale is now easier than closing them, and that the operational weak point sits in vendor remediation, dependency visibility, and prioritisation. For identity teams, the same logic applies wherever third-party access, shared libraries, or delegated credentials create exposure that sits outside direct control.
The article also reframes risk for NHI and supply chain governance: a vulnerability is not the same thing as exposure, and exposure is not the same thing as exploitable priority. The practical problem is deciding which suppliers, libraries, and downstream dependencies matter most before disclosure reaches the inbox. That is a typical problem in modern supply chains, not an edge case.
Key questions
Q: What breaks when a third-party vulnerability is disclosed faster than suppliers can patch it?
A: The control that breaks is remediation-led governance. Discovery becomes useful only if the supplier can accept, prioritise, and fix the issue before attackers exploit it. When patch queues are slow, organisations inherit exposure they do not control and must shift to prioritisation, compensating controls, and dependency-aware risk decisions.
Q: Why does slow third-party patching increase supply chain risk?
A: Because disclosure turns a hidden flaw into a known weakness while leaving the fix outside your control. If the vulnerable component is reused across many vendors, one delayed patch can affect multiple services at once. That is why remediation speed and concentration risk matter more than raw vulnerability count.
Q: What are the signs that third-party vulnerability governance is failing?
A: The main signals are long vendor response times, repeated exposure in shared components, and a growing gap between confirmed findings and actual patches. If your programme tracks disclosures but cannot show remediation dates, ownership, or compensating controls, it is measuring noise rather than risk.
Q: Should security teams prioritise shared dependencies over isolated vendor findings?
A: Yes, when the same library or integration sits inside multiple suppliers and supports business-critical flows. Shared dependencies create concentration risk, so one unresolved flaw can affect several services at once. That makes them higher value than isolated issues with little downstream reach.
Technical breakdown
Why discovery no longer limits third-party risk
Large-scale AI-assisted vulnerability discovery can surface far more candidate flaws than human teams can triage. The mechanism changes the bottleneck from finding bugs to validating them, assigning ownership, and getting fixes accepted downstream. In open-source and mid-tier vendor ecosystems, those steps often depend on a small maintainer group, limited release cycles, and incomplete security response processes. That means security teams can no longer assume that a confirmed issue will move quickly into patch status, even when the defect is real and well understood.
Practical implication: Treat remediation capacity as a supply chain attribute and score vendors by patch throughput, not just disclosure volume.
Why disclosure creates governance, not just engineering, pressure
Once a vulnerability is verified and disclosed, it enters a governance state change. The risk is no longer hypothetical, but many organisations still manage that state as if the issue were waiting in a queue for someone else to resolve. In practice, this creates a mismatch between discovery speed and control ownership. For IAM and NHI programmes, the same pattern appears when third-party services, service accounts, or API integrations depend on software you do not control but still trust operationally.
Practical implication: Map who owns remediation for each exposed dependency before the finding becomes a business impact event.
How concentration risk turns patching gaps into systemic exposure
Concentration risk arises when the same vulnerable library, component, or integration sits inside many suppliers at once. That means one unresolved issue can propagate across a vendor ecosystem even if each supplier looks individually manageable. The article’s point is that scale matters less than distribution: a few high-priority flaws can matter more than thousands of low-value findings if they sit in payment flows, operational platforms, or other load-bearing dependencies. This is where supply chain security and third-party access governance meet.
Practical implication: Prioritise shared dependencies and load-bearing vendors first, because systemic exposure is what turns a vulnerability into an incident.
Threat narrative
Attacker objective: Exploit the most widely deployed and least rapidly remediated third-party software flaw to gain scalable access or disruption across downstream environments.
- Entry occurs when AI-assisted discovery identifies large numbers of candidate flaws across open-source and third-party software.
- Credential or code access is not the only concern here, because the real abuse path is exposure through trusted software supply chains and downstream dependency reuse.
- Escalation happens when a confirmed flaw remains unpatched across multiple vendors, allowing attackers to target the easiest downstream implementation.
- Impact is achieved when a single unresolved library or integration weakness propagates into many organisations at once.
Breaches seen in the wild
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
- Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.
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
Third-party security has become a remediation problem, not a discovery problem. The article’s core finding is that tooling can now surface more flaws than the ecosystem can absorb. That shifts governance from finding weaknesses to proving that suppliers can actually remediate them at useful speed. For identity programmes, the same lesson applies to delegated access and third-party credentials: discovery without lifecycle control does not reduce exposure.
Concentration risk is the named concept security teams should be measuring. The article shows that the danger is not raw CVE volume but how many suppliers share the same vulnerable dependency underneath. That creates a single point of failure across many relationships, which makes third-party risk intelligence more useful than questionnaire-driven assurance. Practitioners should treat shared software dependencies as a governance boundary, not just a technical detail.
Patch latency is now a business continuity variable. When median remediation windows extend while exploit timing compresses, the control issue becomes operational exposure, not vulnerability management in the abstract. That matters to identity, access, and supplier governance because the organisation often inherits risk faster than a vendor can close it. The practical conclusion is that queue position, not vulnerability count, is what determines whether a third-party issue is actionable.
Open-source maintainership is part of the security control plane whether procurement acknowledges it or not. The article correctly points to the long tail of vendors and maintainers that lack staff, process, or incentives to move quickly. That is a structural control gap, not a temporary inefficiency. Security teams should assume that some third-party weaknesses will remain unresolved long enough to require compensating controls at the consumer side.
Identity and supply chain governance intersect when trust is inherited, not earned. Third-party software, delegated access, and machine credentials all create trust that outlives the original decision to connect. The article’s warning about load-bearing vendors applies just as strongly to NHIs and service integrations: if you cannot observe, rank, and retire inherited trust, you cannot govern the blast radius. Practitioners need dependency-aware risk decisions, not generic vendor scores.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: Third-Party, B2B and Contractor Access Guide
What this signals
Concentration risk is now the practical unit of third-party exposure. Security teams should stop treating each supplier as an isolated assurance problem and start tracing where the same dependency, library, or integration appears across multiple vendors. That is where a single vulnerability becomes a multi-party event, and it is where remediation priorities should begin.
Patch speed is becoming part of identity and access governance. If a vendor cannot close a weakness in time, the organisation inherits that risk through trust relationships, delegated access, or software reuse. The control question is no longer whether the flaw exists, but whether your programme can see, rank, and contain it before exploitation closes the window.
The 92% exposure rate cited in the NHI research library shows how often third-party relationships extend beyond direct control, which is exactly why supplier concentration deserves more attention than raw vulnerability counts.
For practitioners
- Build a remediation-first vendor scoring model Rank suppliers by patch latency, confirmed disclosure handling, and the number of load-bearing dependencies they operate in your environment.
- Map shared software dependencies across third parties Identify libraries, services, and integrations that appear in multiple vendors so one flaw does not become a multi-vendor exposure event.
- Separate discovery volume from actionable exposure Create a triage process that filters candidate findings by exploitability, business path, and whether the affected vendor can realistically patch.
- Escalate third-party issues through evidence, not questionnaires Send structured technical evidence to vendors and ask for remediation dates, compensating controls, and customer impact rather than broad assurance responses.
Key takeaways
- AI-assisted vulnerability discovery has shifted the bottleneck from finding flaws to getting third parties to fix them.
- The hardest part of third-party risk is no longer awareness, but deciding which suppliers and shared dependencies matter first.
- Programmes that cannot measure remediation speed and dependency concentration will keep seeing exposure before they can reduce it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address 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; TA0010 — Credential Access; Exfiltration | Third-party flaws become attack paths that enable access and data theft across supplier chains. |
| Recommendation — Map exposed supplier flaws to TA0006 and TA0010, then hunt for downstream access paths and exfiltration exposure. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Third-party integrations depend on permissions that can widen blast radius when suppliers lag on remediation. |
| Recommendation — Apply PR.AA-05 to review supplier entitlements and remove trust paths that exceed business need. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | The article is fundamentally about managing the security performance of external providers. |
| Recommendation — Use CIS-15 to classify suppliers by remediation speed, shared dependencies, and business criticality. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party access and reused components create the exact exposure pattern this article describes. |
| Recommendation — Apply NHI-03 to inventory external dependencies and revoke trust where suppliers cannot remediate quickly. | ||
| NIST SP 800-53 Rev 5 | SR-6 — Supply Chain, Component, and Service Acquisition | Supply chain acquisition controls are directly relevant to third-party vulnerability and dependency governance. |
| Recommendation — Use SR-6 to require suppliers to disclose dependency risk and remediation capability before renewal. | ||
Key terms
- 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.
- Remediation Latency: The time between identifying a security issue and fully removing or reducing the risk. For NHIs and SaaS access, this metric matters because stale credentials, over-shared files, and dormant integrations stay usable until the control finally acts.
- Third-Party Cyber Risk: Security exposure introduced by an external vendor, supplier, or service provider that has access to systems, data, or infrastructure. It is not limited to contract risk. In practice, it is the combination of access, trust, and dependency that can be abused if identity and lifecycle controls are weak.
- Exploitability-first prioritisation: A vulnerability triage approach that ranks findings by the likelihood of real-world abuse rather than by severity score alone. It uses signals such as active exploitation, exposure, asset criticality and privilege context to decide what should be fixed first when analysis capacity is constrained.
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 helps practitioners connect identity controls to third-party and supply chain risk.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org