Who is accountable when a third-party product hides a vulnerable component?

Why This Matters for Security Teams

When a third-party product hides a vulnerable component, accountability is not determined by who built the component alone. The vendor is responsible for software provenance, disclosure, and remediation, but the consuming organisation still owns exposure management, approval for continued use, and interim controls. That division is exactly why hidden dependencies become operational risk, not just a procurement issue.

In practice, the problem is visibility. Teams often know the product name but not the embedded library, transitive package, or bundled service account behind it. The result is delayed impact analysis, missed compensating controls, and confusion during incident response. NHIMG’s research shows only 5.7% of organisations have full visibility into their service accounts, which is a strong signal that identity and component inventory gaps tend to travel together.

That is why supply chain accountability has to be explicit before a vulnerability is disclosed. The operating model needs named owners, escalation paths, and a way to decide when a product stays online, gets isolated, or is removed. In practice, many security teams discover hidden component exposure only after a vendor bulletin arrives, rather than through intentional inventory and provenance review.

How It Works in Practice

Operational accountability starts with mapping product ownership across procurement, security, IT, and application teams. The vendor should provide software bill of materials details, dependency disclosure, and a remediation commitment. The consuming organisation should maintain an asset record that ties each deployed product to business owner, environment, data sensitivity, and compensating controls. Without that chain, no one can answer whether the hidden component is reachable, privileged, or already mitigated.

Current guidance suggests treating hidden components as a detection and governance problem, not only a patching problem. A practical response usually includes:

• checking the product against internal inventories, CI/CD records, and package attestations
• confirming whether the vulnerable component is bundled, active, or merely present
• applying isolation, feature disabling, or network restriction while waiting for vendor fix delivery
• documenting who can approve temporary risk acceptance and under what expiry date
• tracking whether the vendor’s remediation changes the component version, exposure path, or configuration state

For identity-heavy systems, this also intersects with NHI governance because hidden components often embed secrets, tokens, or service accounts. NHIMG’s Reviewdog GitHub Action supply chain attack and Shai Hulud npm malware campaign show how a product or dependency can become an identity exposure problem as quickly as a code defect. The control objective is to know what is inside the product before a disclosure lands and to decide, in advance, who can stop or continue its use. These controls tend to break down in SaaS-heavy environments where the vendor will not provide component detail and the customer cannot independently verify runtime exposure.

Common Variations and Edge Cases

Tighter accountability often increases vendor-management overhead, requiring organisations to balance faster adoption against stronger assurance. Not every hidden component creates the same level of responsibility, so the response should scale to the actual exposure rather than the headline severity.

One common edge case is a product that contains a vulnerable component that is never invoked in the deployed configuration. In that case, the vendor still owns disclosure and fix delivery, but the consuming organisation may be able to justify temporary acceptance if it has evidence that the path is unreachable. Another edge case is a cloud service where the customer cannot patch anything directly. Here, the customer still owns risk acceptance, data placement, and exit planning, while the vendor owns the service-side correction.

There is no universal standard for this yet, but best practice is evolving toward shared evidence: attestation from the vendor, internal asset traceability, and documented compensating controls. The OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls both support this direction by pushing organisations toward inventory, least privilege, and controlled response. The practical failure mode is usually not malicious denial by the vendor but an unclear contract plus an incomplete inventory, which leaves the hidden component unowned until the breach report is already public.

Related resources from NHI Mgmt Group

• What breaks when a vulnerable third-party component still has broad network and identity access?
• Who is accountable when a vulnerable Tomcat server remains exposed?
• Who is accountable when a third-party credential is misused?
• Who is accountable when a third-party platform outage disrupts academic operations?