Use an existing rule when one already covers the bug class, and write a custom rule only for something specific to your code, such as an internal API that is unsafe in certain uses. A custom rule is code you must test, document and maintain, so it should earn its place.
The cost nobody budgets
Writing the first version of a rule takes an afternoon. The cost is the following years: language upgrades, false positive reports, new developers asking why the build failed, and the day the author leaves. ESLint's own documentation makes a related point when it warns that building on core rules is fragile because they are not part of the public API. Anything you depend on can move.
Five questions
- Is the bug class common? Injection, unsafe deserialization and hard-coded secrets are covered by existing rulesets. Check there first.
- Is the pattern specific to your code? A wrapper function, an internal client library or a naming convention is invisible to generic rules. This is where custom rules shine.
- Can you state it in one sentence? "Never call legacyAuth outside the auth module" is a good rule. "Find insecure design" is not.
- Can you test it? If you cannot write both a flagged and a safe example, you cannot tell whether the rule works.
- Who will own it? If nobody can answer, do not ship it.
Decision table
| Situation | Better choice |
|---|---|
| Well known weakness class | Existing rule, tuned |
| Existing rule is noisy in your framework | Tune or scope it first, then consider custom |
| Banned internal function | Custom rule |
| Architectural boundary, such as no database calls from controllers | Custom rule or a dependency boundary check |
| Needs data flow across services | Probably beyond a simple rule |
| Business logic flaw | Review and tests, not a rule |
Middle options
Before writing code, look at configuration. Many engines let you turn a rule on for some directories only, change its severity, or ban a function with a built-in restricted syntax setting. Those options carry far less maintenance than a rule you wrote.
A short pilot
- Write the rule for one pattern.
- Run it on the full repository in warning mode.
- Review every result, or a sample if there are many.
- If most results are real, keep it. If most are noise, rewrite or drop it.
OWASP's source code analysis page lists high false positive counts as a known weakness of static tools in general. A custom rule inherits that problem, so plan the feedback loop before the rule ships.
Quick check
Is a custom rule better than code review?
For a repeatable mechanical pattern, yes, because it never gets tired. For judgment calls about design or business logic, review is better.
How many custom rules is too many?
There is no magic number. A useful limit is the number your team can name an owner for and review at least once a quarter.
Safeguard's scanning covers dependencies and SBOMs, and its reachability analysis helps show which findings your code can actually call. You can run a free scan on a repository.
Sources
Last reviewed: 19 October 2026.
