Reliance on Insufficiently Trustworthy Component

Incomplete Class
Structure: Simple
Description

This weakness occurs when a system integrates a component that cannot be fully trusted to meet security, reliability, and maintenance standards, creating risk for the entire product.

Extended Description

Modern products are often assembled from various third-party components, like open-source libraries or supplier hardware. Each part must be trustworthy; otherwise, it introduces risks like unfixable vulnerabilities, hidden malware, or components that can't be updated when security flaws are discovered. Even internally developed components can become untrustworthy if their source code is lost or their original developers are no longer available. Trust is subjective—different teams and stakeholders have varying criteria for security, safety, and cost. This means architects must make conscious trade-offs, understanding that relying on an insufficiently vetted component can compromise the entire system's integrity, regardless of where that component originated.

Common Consequences 1
Scope: Other

Impact: Reduce Maintainability

Potential Mitigations 3
Phase: RequirementsArchitecture and DesignImplementation
For each component, ensure that its supply chain is well-controlled with sub-tier suppliers using best practices. For third-party software components such as libraries, ensure that they are developed and actively maintained by reputable vendors.
Phase: Architecture and DesignImplementationIntegrationManufacturing
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."
Phase: OperationPatching and Maintenance
Continue to monitor changes in each of the product's components, especially when the changes indicate new vulnerabilities, end-of-life (EOL) plans, supplier practices that affect trustworthiness, etc.
Observed Examples 1
CVE-2020-9054Chain: network-attached storage (NAS) device has a critical OS command injection (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')) vulnerability that is actively exploited to place IoT devices into a botnet, but some products are "end-of-support" and cannot be patched (Firmware Not Updateable). [REF-1097]
References 4
A06:2021 - Vulnerable and Outdated Components
OWASP
24-09-2021
ID: REF-1212
SOFTWARE BILL OF MATERIALS
National Telecommunications and Information Administration
ID: REF-1246
Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM)
NTIA Multistakeholder Process on Software Component Transparency Framing Working Group
21-10-2021
ID: REF-1247
Zyxel Flaw Powers New Mirai IoT Botnet Strain
Brian Krebs
20-03-2020
ID: REF-1097
Applicable Platforms
Technologies:
Not Technology-Specific : UndeterminedICS/OT : Undetermined
Modes of Introduction
Requirements
Architecture and Design
Taxonomy Mapping
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
Notes
MaintenanceAs of CWE 4.10, the name and description for this entry has undergone significant change and is still under public discussion, especially by members of the HW SIG.