CWE-1059, Insufficient Technical Documentation, means the product does not have enough technical or engineering documentation to describe all its relevant software and hardware elements. MITRE lists usage, structure, architectural components, interfaces, design, implementation, configuration and operation. It applies to software teams and, because MITRE covers it explicitly, to hardware and ICS/OT products too.
How it happens
Documentation is the first thing cut when a schedule slips. Over time:
- Interfaces change and the reference is never updated.
- Configuration options exist that nobody wrote down.
- A feature ships with a manual that lists some of its behavior, not all of it.
- For hardware, the final reference artifacts are not kept.
MITRE gives one concrete case. In CVE-2022-3203, a wireless access point manual specifies that the only method of configuration is via web interface (CWE-1059), but there is an undisclosed telnet server that was activated by default (CWE-912). The manual said one thing. The device did another. Nobody reading the documentation would have known to turn the telnet service off.
What an attacker gains
The record describes the impact as follows:
- Reduced maintainability and reliability.
- Quality degradation: "Without a method of verification, one cannot be sure that everything only functions as expected."
- Hidden activities, as the access point example shows, where a service runs that the documentation never mentions.
MITRE adds a point that is easy to miss. When you pay time-limited security consultants for threat modeling, vulnerability discovery or pentesting, insufficient documentation forces them to spend hours learning how the product is organized, instead of finding flaws or suggesting mitigations. You pay for orientation instead of results.
For hardware, the lack of a formal final manufacturer reference can make it difficult or impossible to evaluate the final product, including post-manufacture verification. MITRE lists engineering artifacts such as hardware description language files, netlists, Gerber files, bills of materials and EDA tool files as part of that documentation.
How to find it
The record lists no detection methods, so this is an audit. Try:
- Compare the documentation against reality. List the open network ports and running services on a test unit and check that each one appears in the manual.
- Pick a component at random and ask whether someone outside the team could configure and operate it from the docs.
- Check whether the documentation covers each item MITRE names: usage, structure, interfaces, design, implementation, configuration and operation.
- For hardware, confirm that the final reference artifacts exist and match the shipped product.
A simple service check on a device or server can reveal undocumented listeners:
# List listening TCP ports on a Linux host to compare with the documentation
ss -ltn
Any port that no document explains deserves a question.
How to fix it
MITRE gives one mitigation, for the Documentation and Architecture and Design phases: ensure that design documentation is detailed enough to allow post-manufacturing verification. The same idea works for software.
- Treat documentation as a release requirement. A feature without updated docs is not done.
- Document every network service, default account and default setting. If it is on by default, it is in the manual.
- Keep docs in version control next to the code so changes travel together.
- Before a security engagement, hand the consultants a current architecture and interface description so their hours go to finding problems.
- For hardware, keep the final engineering artifacts as a formal reference and make them available for verification.
Your third-party components are part of the documented picture too. The free scan at gold.safeguard.sh/scan lists the dependencies in a manifest file, with no login, the file staying on your machine, and a limit of 100 dependencies. It is a quick way to start a component inventory.
Quick check
What went wrong in the access point example?
The manual said configuration was only possible through the web interface, but an undisclosed telnet server was enabled by default. The documentation did not match the product.
Why does this weakness cost money during pentests?
Time-limited consultants must spend part of their engagement learning how the product is organized, which leaves less time for finding flaws.
What is the one mitigation MITRE lists?
Make design documentation detailed enough to allow post-manufacturing verification.
