Most teams need a few custom rules, not hundreds. Ask how long it takes to write one that catches a known internal mistake, how you test it, where it lives, and who maintains it. If the answer involves a vendor services engagement for every rule, plan for that dependency.
Why custom rules come up
Default rules know common framework behaviour. They do not know that your company wraps database access in an internal helper, that one logging function must never receive tokens, or that a deprecated internal API should be banned. Custom rules encode that local knowledge.
You may also need a custom rule to stop a false positive pattern repeating. If a sanitiser is internal, the tool does not know it cleans input, and every use looks like a flaw.
Do you need them at all
Often not at first. If the default rule set finds real issues on your pilot repositories and the noise is manageable, skip custom rules for now. Write them when you see the same preventable mistake three times.
A free or open source engine with a rule language can be enough for a small team. Be honest about the cost, though: someone has to learn the language and own the rules.
Questions about authoring
- What does a rule look like? Is it a pattern close to the source language, a query language, or a configuration file with regular expressions?
- How long did the vendor's own solution engineer take to write a rule for your example? Ask them to do it live, using a mistake from your history.
- Can a developer, not only a specialist, read and review a rule?
- Can a rule express data flow, such as "this input must not reach that function without passing through this cleaner", or only a pattern match on syntax?
Data flow matters. Syntax patterns find banned calls. Flow rules find misuse of values, which is where most injection style flaws live.
Questions about testing and lifecycle
- Can you write test cases, with code that should match and code that should not, and run them in CI?
- Are rules stored as files in version control, with review, or only inside a dashboard?
- Can you scope a rule to a directory, a language, or a team?
- What happens to your rules when the vendor updates the engine? Ask about versioning and breaking changes.
- Can you export your rules? If you leave, a rule set you wrote is an asset. Ask what format it is in.
A short authoring test
Take one internal anti pattern, for example calling a deprecated internal function. Give each candidate tool an hour to write a rule, a positive test and a negative test, and run it against a repository. Record the elapsed time and whether the rule found both known uses and nothing else.
Two outcomes matter. A rule that takes a day to write means you will write few. A rule that fires on code that is actually fine means you have just created a new source of noise.
Keeping rules healthy
Give each rule an owner and a reason. Review fire rates quarterly. Delete rules that fire nothing and rules that developers always dismiss.
Quick check
Is a large number of default rules a good sign?
Not by itself. Rule count says little about accuracy. Judge rules by how many real findings they produce on your code.
Should custom rules live in the dashboard?
Prefer files in version control. They are reviewable, testable and portable if you change tools.
Safeguard supports policies, gates and guardrails you can define for your own requirements, and the free scan at gold.safeguard.sh/scan is a quick way to see results on your dependencies.
Last reviewed: 19 October 2026.
