CWE-1357: Reliance on Insufficiently Trustworthy Component

ClassIncomplete

The product is built from multiple separate components, but it uses a component that is not sufficiently trusted to meet expectations for security, reliability, updateability, and maintainability.

View on MITRE
Back to CWE Lookup

Extended Description

Many modern hardware and software products are built by combining multiple smaller components together into one larger entity, often during the design or architecture phase. For example, a hardware component might be built by a separate supplier, or the product might use an open-source software library from a third party. Regardless of the source, each component should be sufficiently trusted to ensure correct, secure operation of the product. If a component is not trustworthy, it can produce significant risks for the overall product, such as vulnerabilities that cannot be patched fast enough (if at all); hidden functionality such as malware; inability to update or replace the component if needed for security purposes; hardware components built from parts that do not meet specifications in ways that can lead to weaknesses; etc. Note that a component might not be trustworthy even if it is owned by the product vendor, such as a software component whose source code is lost and was built by developers who left the company, or a component that was developed by a separate company that was acquired and brought into the product's own company. Note that there can be disagreement as to whether a component is sufficiently trustworthy, since trust is ultimately subjective. Different stakeholders (e.g., customers, vendors, governments) have various threat models and ways to assess trust, and design/architecture choices might make tradeoffs between security, reliability, safety, privacy, cost, and other characteristics.

Technical Details

Structure
Simple

Applicable To

Languages
Platforms

Source-backed guidance

Additional facts reviewed against primary or authoritative security sources.

Verify controls for CWE-1357 with SSDF evidence

Use NIST SSDF verification and vulnerability-response practices to detect CWE-1357, Reliance on Insufficiently Trustworthy Component, throughout the product lifecycle. Derive review questions, static or dynamic checks, and negative tests from the CWE's causal behavior; define the components and lifecycle stages each check covers; and retain findings with enough evidence to distinguish the root cause from symptoms and impacts. Track escapes and false negatives, then improve the verification plan after every confirmed occurrence.

NIST SP 800-218 Secure Software Development FrameworkNational Institute of Standards and Technology

Address Reliance on Insufficiently Trustworthy Component during Requirements

MITRE associates mitigation with Requirements, Architecture and Design, Implementation, Integration, and Manufacturing; documented detection approaches include Automated Static Analysis; recorded impacts include Reduce Maintainability. Use these source-defined anchors to turn CWE-1357 into implementation, review, and verification checks for the affected component.

CWE-1357: Reliance on Insufficiently Trustworthy ComponentMITRE CWE

Triage CWE-1357 against known exploitation evidence

Use CISA's Known Exploited Vulnerabilities catalog to test whether a vulnerability mapped to CWE-1357, Reliance on Insufficiently Trustworthy Component, has evidence of exploitation in the wild. Confirm the CVE-to-CWE root-cause mapping independently before attaching the example, then capture the affected product, required action, and remediation deadline. A missing KEV match is not evidence that the weakness is unexploited, and a KEV entry must not be generalized to every occurrence of this CWE.

Known Exploited Vulnerabilities CatalogCybersecurity and Infrastructure Security Agency

Apply precise root-cause mapping to CWE-1357

Apply MITRE's full root-cause mapping guidance when using CWE-1357, Reliance on Insufficiently Trustworthy Component. Separate weakness language from attacker prerequisites and technical impact, check the entry's abstraction and vulnerability-mapping notes, and prefer the most specific Base or Variant supported by the evidence. Record the rejected alternatives and require an independent review before the mapping is used for remediation trends or program metrics.

CVE to CWE Root Cause Mapping GuidanceMITRE CWE

Validate CWE-1357 with root-cause mapping checks

Apply MITRE's root-cause mapping quick tips to CWE-1357, Reliance on Insufficiently Trustworthy Component. Confirm the finding describes the causal weakness rather than an impact or attack pattern, compare the abstraction and mapping notes with plausible alternatives, and have a second reviewer challenge the selection. Preserve the evidence and reasoning so recurring defects can be measured against one consistent identifier.

CVE to CWE Root Cause Mapping Quick TipsMITRE CWE

Frequently Asked Questions

What is CWE-1357: Reliance on Insufficiently Trustworthy Component?+

CWE-1357: Reliance on Insufficiently Trustworthy Component is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product is built from multiple separate components, but it uses a component that is not sufficiently trusted to meet expectations for security, reliability, updateability, and maintainability. Many modern hardware and software products are built by combining multiple smaller components together into one larger entity, often during the design or architecture phase. For example, a hardware component might be built by a separate supplier, or the product might use an open-source software library from a third party. Regardless of the source, each component should be sufficiently trusted to ensure correct, secure operation of the product. If a component is not trustworthy, it can produce significant risks for the overall product, such as vulnerabilities that cannot be patched fast enough (if at all); hidden functionality such as malware; inability to update or replace the component if needed for security purposes; hardware components built from parts that do not meet specifications in ways that can lead to weaknesses; etc. Note that a component might not be trustworthy even if it is owned by the product vendor, such as a software component whose source code is lost and was built by developers who left the company, or a component that was developed by a separate company that was acquired and brought into the product's own company. Note that there can be disagreement as to whether a component is sufficiently trustworthy, since trust is ultimately subjective. Different stakeholders (e.g., customers, vendors, governments) have various threat models and ways to assess trust, and design/architecture choices might make tradeoffs between security, reliability, safety, privacy, cost, and other characteristics.

What are the security consequences of Reliance on Insufficiently Trustworthy Component?+

If exploited, CWE-1357 (Reliance on Insufficiently Trustworthy Component) it can compromise Other, leading to outcomes such as Reduce Maintainability.

How do you prevent or mitigate Reliance on Insufficiently Trustworthy Component?+

Recommended mitigations for CWE-1357 include: 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. 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." 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.

What are real-world examples of Reliance on Insufficiently Trustworthy Component?+

MITRE documents real CVEs mapped to CWE-1357, including CVE-2020-9054. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.

What is the difference between a CWE and a CVE?+

A CWE (Common Weakness Enumeration) like CWE-1357 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.

Learn More

Advertisement