Dependency on Vulnerable Third-Party Component

Opis

The product has a dependency on a third-party component that contains one or more known vulnerabilities.

Many products are large enough or complex enough that part of their functionality uses libraries, modules, or other intellectual property developed by third parties who are not the product creator. For example, even an entire operating system might be from a third-party supplier in some hardware products. Whether open or closed source, these components may contain publicly known vulnerabilities or hidden functionality such as malware that could be exploited by adversaries to compromise the product.

Skutki

• Confidentiality, Integrity, Availability

  Varies by Context

  The consequences vary widely, depending on the vulnerabilities that exist in the component; how those vulnerabilities can be "reached" by adversaries, as the exploitation paths and attack surface will vary depending on how the component is used; and the criticality of the privilege levels and features for which the product relies on the component.

Zapobieganie

• Requirements, Policy

  In some industries such as healthcare [REF-1320] [REF-1322] or technologies such as the cloud [REF-1321], it might be unclear about who is responsible for applying patches for third-party vulnerabilities: the vendor, the operator/customer, or a separate service. Clarifying roles and responsibilities can be important to minimize confusion or unnecessary delay when third-party vulnerabilities are disclosed.

• Requirements

  Require a Bill of Materials for all components and sub-components of the product. For software, require a Software Bill of Materials (SBOM) [REF-1247] [REF-1311].

• Architecture and Design, Implementation, Integration, Manufacturing

  Maintain a Bill of Materials for all components and sub-components of the product. For software, maintain a Software Bill of Materials (SBOM). According to [REF-1247], "An SBOM is a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships."

• Operation, Patching and Maintenance

  Actively monitor when a third-party component vendor announces vulnerability patches; fix the third-party component as soon as possible; and make it easy for operators/customers to obtain and apply the patch.

• Operation, Patching and Maintenance

  Continuously monitor changes in each of the product's components, especially when the changes indicate new vulnerabilities, end-of-life (EOL) plans, etc.

Przykłady podatności

• CVE-2025-45612 product uses a vulnerable version of an authentication framework, allowing authentication bypass

Słabość nadrzędna

• CWE-1357 Reliance on Insufficiently Trustworthy Component
• CWE-657 Violation of Secure Design Principles

Kiedy powstaje

• Architecture and Design — The product architect or designer might choose a component that is already known to contain vulnerabilities or has a high likelihood of containing vulnerabilities in the future.
• Implementation — For reasons of compatibility or stability, developers might choose a third-party component, such as a library, that is already known to contain vulnerabilities.
• Patching and Maintenance — Since all products contain vulnerabilities, over time, a third-party component will be discovered to have a vulnerability.

Dotyczy

Not Language-Specific, Not OS-Specific, Not Architecture-Specific, Not Technology-Specific

Źródła

1. The Unfortunate Reality of Insecure Libraries — Jeff Williams, Arshan Dabirsiaghi, 2014
2. A06:2021 - Vulnerable and Outdated Components — OWASP, 2021
3. Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM) — NTIA Multistakeholder Process on Software Component Transparency Framing Working Group, 2021
4. The Cases for Using the SBOMs We Build — Amélie Koran, Wendy Nather, Stewart Scott, Sara Ann Brackett, 2022
5. OWASP Dependency-Check — OWASP
6. ICS Alert (ICS-ALERT-20-063-01): SweynTooth Vulnerabilities — ICS-CERT, 2020
7. Unleashing Mayhem over Bluetooth Low Energy — Matheus E. Garbelini, Sudipta Chattopadhyay, Chundong Wang, Singapore University of Technology and Design, 2020
8. Alert (AA21-356A): Mitigating Log4Shell and Other Log4j-Related Vulnerabilities — CISA, 2021
9. What Log4Shell taught us about application security, and how to respond now — Daniel Thomas, SC Media, 2022
10. A Framework for a Medical Device Security Program at a Healthcare Delivery Organization — Ali Youssef, 2022
11. Shared Responsibility Model Explained — Cloud Security Alliance, 2020
12. Medical Device Cybersecurity Regional Incident Preparedness and Response Playbook — Melissa Chase, Steven Christey Coley, Julie Connolly, Ronnie Daldos, Margie Zuk, Section 6.1: Medical Device Procurement, 2022