CWE-1080, Source Code File with Excessive Number of Lines of Code, is exactly what it sounds like: one file doing too much.
MITRE notes that what counts as too many lines varies by team. The CISQ quality standard suggests a default threshold of 1000. MITRE also states that this entry is primarily a quality issue with no direct security implications, and it must not be used to map real world vulnerabilities.
How it happens
Files grow by accretion. A feature lands in the nearest convenient file, then another, then a fix. Nobody splits it because splitting is work that no ticket asks for.
What an attacker gains
Nothing directly. MITRE lists reduced maintainability and increased analytical complexity. The security effect is indirect: a very large file is harder to understand and change, so finding and fixing a vulnerability inside it takes longer and is more error prone.
How to find it
MITRE lists automated static analysis as a detection method. A line count check is the simplest version and takes one command.
# List source files over 1000 lines
find . -name "*.py" -exec wc -l {} + | awk '$1 > 1000'
Many linters also have a maximum file length rule.
How to fix it
- Set a team threshold and enforce it in the linter, starting with a warning.
- Split files along real boundaries, such as one responsibility per module.
- Move code when you touch it rather than in one risky rewrite.
- Keep tests around the code you move so behavior stays the same.
Quick check
Does a long file make your application vulnerable by itself?
No. MITRE treats it as a quality issue with no direct security implications. The risk is that bugs inside it are harder to spot and fix.
