File linters are useful because they are strict, fast, and predictable. Security bugs are usually not useful in those same ways. They often depend on application behavior, trust boundaries, or the way one file interacts with another. That is why a lint-clean file can still be unsafe to ship.
What linters are designed to do
Linters are built to enforce rules that can be expressed clearly and checked mechanically. They are excellent at style, syntax, and known anti-patterns, but they are not designed to understand whether a file gives the wrong person access to data or assumes a value is safe when it is not.
Why security is different
- Security depends on context, not just code shape.
- Some bugs only appear when multiple files are considered together.
- Threats often involve attacker behavior, not just programmer mistakes.
- Many dangerous paths look normal at the line level.
Common blind spots
- Authorization checks that are missing or incomplete
- Secrets exposed in logs or config files
- Unsafe default values hidden in helpers
- Validation that is technically present but logically wrong
What to do instead
Use the linter as a gate for mechanical quality, then use AI or human review to inspect the parts that depend on intent. Security review is about asking what could go wrong, not just whether the code compiles and passes style checks.