A linter catches security bugs when its rules target unsafe constructs, such as dynamic code execution, weak randomness, disabled certificate checks and shell calls built from strings. Style rules do not. Turn on the small set of rules that flag dangerous calls, make them block merges, and leave formatting to the formatter.
Style rules and safety rules are different jobs
Most lint configs grew out of style debates: quote types, line length, import order. Those rules help readability and have almost no security value. A safety rule asks a different question: does this line call something that is risky when the input is not trusted?
If your config mixes both, developers learn to treat every warning as noise. Separating the two lists is the first step. Keep the style rules in the formatter and the editor, and keep a short, named set of safety rules that must pass.
Rule families worth turning on
Look in your language's linter for rules in these families. Names differ by tool, so check your own docs.
- Dynamic code execution: calls that run a string as code.
- Shell and process calls built from concatenated strings.
- Weak or non-cryptographic random numbers used for tokens or identifiers.
- Disabled TLS or certificate verification.
- Hardcoded credentials in assignments with names like password or token.
- Unsafe deserialization of data that may come from outside.
- Query strings assembled with string formatting instead of parameters.
None of these proves a vulnerability. Each one marks a place where a reviewer should ask where the input comes from.
Keep the noise down
A rule that fires two hundred times on day one will be switched off by day three. A few habits help:
- Enable one family at a time and fix or suppress existing hits in a single cleanup pull request.
- Require a written reason on every suppression comment, and review those in code review.
- Run the rules on changed files first if the legacy backlog is large, then widen the scope.
- Track the suppression count. A rising number means the rule is wrong or the team is tired.
For a deeper look at where fast checks belong, see pre-commit checks vs CI checks.
Make the rules block, in CI
A warning in the editor is advice. A failing required check is a control. Run the same lint config in CI and mark the job as required in branch protection, so a local bypass does not skip it. The reasoning is covered in Git no-verify bypass and the CI backstop.
Be honest about the limit. Linters read one file or function at a time. They do not follow data across services, check your dependencies, or know whether a risky call is reachable from a public endpoint. They are the cheapest layer, not the whole stack.
Try it yourself
Open the demo and watch how a pull request gate decides whether a change can merge. Look at which findings block and which are only reported.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Linters cover your own code style and a slice of unsafe calls. Safeguard adds dependency and SBOM scanning, reachability analysis and policy gates on pull requests. A free scan is available at gold.safeguard.sh/scan.
Quick check
Is a linter a replacement for a SAST tool?
No. A linter checks patterns in one file at a time. Code scanning tools trace data flow further, so the two overlap but do not replace each other.
Should security lint rules be warnings or errors?
Errors, once the existing backlog is cleaned up. A warning that never blocks a merge tends to be ignored.
Last reviewed: 19 October 2026.
