CWE-561: Dead Code | Glexia
CWE-561 (Dead Code) weakness overview with consequences, detection methods, mitigations, related CVEs and MITRE ATT&CK context.
Glexia's Take · Automated analysis
CWE-561: Dead Code
Dead Code represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Other: Quality Degradation: Dead code that results from code that can never be executed is an indication of problems with the source code that needs to be fixed and is an indication of poor quality.
- Other: Reduce Maintainability
Developer Pattern
CWE-561 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Automation confidence
high confidence from CWE-561, 4.20.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Official CWE Definition
CWE-561: Dead Code
The product contains dead code, which can never be executed.
Dead code is code that can never be executed in a running program. The surrounding code makes it impossible for a section of code to ever be executed.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- The condition for the second if statement is impossible to satisfy. It requires that the variables be non-null. However, on the only path where s can be assigned a non-null value, there is a return statement.
- In the following class, two private methods call each other, but since neither one is ever invoked from anywhere else, they are both dead code. (In this case it is a good thing that the methods are dead: invoking either one would cause an infinite loop.)
- The field named glue is not used in the following class. The author of the class has accidentally put quotes around the field name, transforming it into a string constant.
Remediation
- Implementation: Remove dead code before deploying the application.
Detection
- Architecture or Design Review: According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.) Formal Methods / Correct-By-Construction Cost effective for partial coverage: Attack Modeling
- Automated Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Binary / Bytecode Quality Analysis Compare binary / bytecode to application permission manifest
- Dynamic Analysis with Manual Results Interpretation: According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Automated Monitored Execution
- Automated Static Analysis: According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Permission Manifest Analysis
- Automated Static Analysis - Source Code: According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Source Code Quality Analyzer Cost effective for partial coverage: Warning Flags Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer
- Dynamic Analysis with Automated Results Interpretation: According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Web Application Scanner Web Services Scanner Database Scanners
- Manual Static Analysis - Source Code: According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Manual Source Code Review (not inspections) Cost effective for partial coverage: Focused Manual Spotcheck - Focused manual analysis of source
Mappings
Related CVEs, CWEs, and ATT&CK context
Related CWEs
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.