CWE-1110 is about documentation, not code. The product's design documentation does not adequately describe control flow, data flow, system initialization, relationships between tasks and components, rationales, or other important aspects of the design.
MITRE lists it as applying to anything, and to ICS and OT systems in particular. It is a quality issue with no direct security implications, and it must not be used to map real vulnerabilities.
How it happens
Design lives in people's heads. The system was built fast, the original authors moved on, and the only description is the code itself. Or a document existed once and stopped being updated. New engineers learn by reading everything.
What an attacker gains
MITRE lists reduced maintainability and increased analytical complexity. There is no direct attacker benefit. The cost lands on defenders: a security reviewer who cannot see where data enters and leaves a system, or how components start up, will find fewer problems and take longer to fix the ones they do find.
How to find it
The record lists no detection methods. Ask a new team member or an outside reviewer to explain data flow and startup order from the documents alone. Wherever they have to read code to answer, the documentation has a gap.
How to fix it
There are no formal mitigations in the record. A useful design document usually covers:
- Components and how they relate.
- How data moves between them, and where it crosses trust boundaries.
- What happens at startup and shutdown.
- Why important choices were made, not just what was chosen.
Keep it short enough that it gets updated, and review it whenever the design changes.
Quick check
Why list a documentation gap as a weakness at all?
Because it raises the cost of finding and fixing real flaws. MITRE records the effect as reduced maintainability and increased analytical complexity.
