CWE-1085, Invokable Control Element with Excessive Volume of Commented-out Code, describes a function or method with a large amount of code that has been commented out inside its body.
MITRE notes that the right amount varies, and the CISQ standard suggests a default threshold of 2% commented code. The entry is a quality issue with no direct security implications, and it is prohibited for mapping real vulnerabilities.
How it happens
A developer tries a new approach and keeps the old lines nearby "just in case." The old code never gets deleted. Over time a function is half live code and half archaeology.
// Smell
void applyDiscount(Order o) {
// if (o.isPartner()) { o.setRate(0.30); }
// if (o.total() > 5000) { o.setRate(0.20); }
o.setRate(rateFor(o));
}
A reader cannot tell whether those lines are dead for good, waiting to return, or a note about a security rule someone removed on purpose.
What an attacker gains
Nothing directly. MITRE lists reduced maintainability and the indirect security effect of making vulnerabilities harder to find and fix. Commented out checks are a particular worry: someone may uncomment a validation or an authorization test without realizing why it was disabled.
How to find it
MITRE lists automated static analysis. Many linters report the share of commented code, and a search for comment lines that end in a semicolon or contain braces finds most of it.
How to fix it
- Delete the dead code. Version control keeps it.
- Write the reason in the commit message, not in a block of old code.
- Add a linter rule against commented out code and run it in CI.
- If a security check was disabled on purpose, record why in a short comment or a ticket.
Quick check
Where should old code live if you might need it again?
In version control history. A commit message can explain the change, and the file stays readable.
