CWE-1357, Reliance on Insufficiently Trustworthy Component, is a class level weakness. The product is built from separate components and uses one that is not trusted enough to meet expectations for security, reliability, updateability and maintainability. For software teams it is the supply chain risk question in CWE form.
How it happens
Modern hardware and software products are assembled from smaller parts, often chosen at design time: a supplier's hardware block, an open source library. Each part needs to be trustworthy enough for the product to work correctly and securely.
MITRE lists what goes wrong when a component is not:
- Vulnerabilities that cannot be patched fast enough, or at all.
- Hidden functionality such as malware.
- No way to update or replace the component when security needs it.
- Hardware built from parts that miss specifications in ways that cause weaknesses.
Ownership does not guarantee trust. MITRE's examples include a component whose source code was lost and whose developers left, or one from a company that was acquired and folded into your own. Trust is also subjective: customers, vendors and governments have different threat models and ways of judging it, and design choices trade off security against reliability, safety, privacy and cost.
The record points to CVE-2020-9054, a chain in which a network-attached storage device has a critical, actively exploited OS command injection used to put IoT devices in a botnet, while some of the products are end of support. The command injection is one weakness. Relying on products that can no longer be fixed is the one this entry describes.
What an attacker gains
The record's consequence is other and reduced maintainability. The attacker gains come indirectly, through whatever flaws or hidden functions the component carries, and through your inability to fix them quickly.
How to find it
MITRE notes static analysis can find some instances, and the weakness is as much about process as code. The useful checks are about knowledge:
- Do you have a complete list of components and sub-components, with versions?
- For each, is there an active maintainer, a release history and a security contact?
- Is there an end of life date, and a plan for after it?
- Can you update or replace it without rewriting the product?
A dependency scan answers the first question quickly. The free scanner at gold.safeguard.sh/scan runs in the browser with no login, keeps your file on your machine and covers up to 100 dependencies. The Gold directory adds package and advisory context, and reachability analysis tells you whether your code calls the vulnerable function in a doubtful component, which helps rank what to replace first.
How to fix it
From the record:
- Make sure each component's supply chain is well controlled, with sub-tier suppliers following good practice. For third-party libraries, make sure they are developed and actively maintained by reputable vendors.
- Maintain a Bill of Materials for all components and sub-components. For software, that is an SBOM, which MITRE quotes as a formal, machine-readable inventory of components and dependencies, with information about them and their hierarchical relationships.
- During operation and maintenance, keep monitoring each component for changes, especially new vulnerabilities, end of life plans and supplier practices that affect trustworthiness.
A small policy helps make this concrete:
Before adding a dependency, record:
- who maintains it and when it last released
- how security issues are reported and fixed
- what we do if it is abandoned (replace, fork, vendor)
- which parts of our code call it
Try it yourself
See how a dependency inventory is built from a lockfile and what it shows about each component.
Click through it at your own pace, or open it full screen.
Quick check
Can a component from your own company be untrustworthy?
Yes. MITRE gives the examples of source code that was lost with departed developers, or a component from an acquired company.
Why does MITRE recommend a bill of materials?
You cannot judge or monitor components you have not listed. An SBOM is a machine-readable inventory of components and their relationships.
Is trust the same for every organization?
No. MITRE notes trust is subjective and depends on each stakeholder's threat model.
