List every path rule in the old scanner, translate each one into the new tool's syntax, then test it against a sample tree to confirm it excludes the same files and nothing more. Glob dialects differ, so a rule that skipped one test folder in the old tool can silently skip a whole directory in the new one.
Why path rules are the quiet risk
Teams add ignore paths over the years: test fixtures, vendored samples, generated code, documentation examples. Each is a small blind spot that someone decided was acceptable. When you move to a new scanner, those rules are rebuilt from memory or copied by eye, and small syntax differences turn into large coverage differences.
A rule that is too narrow only creates noise. A rule that is too broad creates a hole.
Common syntax differences
| Behavior | What to check |
|---|---|
| Recursive wildcard | Does a double star match nested folders, and does a single star cross slashes? |
| Leading slash | Is the pattern anchored to the repo root or matched anywhere? |
| Trailing slash | Does it match only directories? |
| Case sensitivity | Is matching case sensitive on every operating system? |
| Negation | Can you re-include a file after excluding its parent? |
| Match target | Is the pattern tested against manifest paths, all files, or findings? |
The last row is the least obvious. Some scanners apply ignore rules to which files are scanned, others to which findings are reported. The first prevents any analysis of that path, the second only hides output.
Steps
- Inventory. Collect path rules from the scanner config, the UI, the CI job and any wrapper scripts. Rules hide in all four places.
- Annotate. For each rule, write down why it exists and who added it. If nobody knows, flag it.
- Translate. Write the new syntax next to the old.
- Test on a tree. Create a small directory tree with files that should and should not match, run both tools in a dry run or file listing mode, and compare the lists.
- Diff real results. Scan a real repository with the new rules and without them. The difference is what the rules hide. Read that list.
- Date them. Give each rule an owner and a review date.
Rules that deserve suspicion
Be wary of any rule that excludes a top level folder, anything named vendor, third_party or similar, and any rule using a broad wildcard on file extensions. Vendored code is a frequent source of real vulnerabilities, and ignoring it because it is not first party is rarely a deliberate risk decision.
Also check rules that exist only because of a past false positive. If the new scanner no longer produces that false positive, the rule can simply be dropped.
Prefer narrow, explained rules
A rule should name the smallest path that solves the problem and carry a comment with the reason. A pattern like a single fixtures folder, with a note, is easy to audit. A broad pattern with no note is how blind spots stay forever.
Quick check
Should I copy every ignore rule across?
No. Copy those with a known reason and an owner. Run the new scanner without the others and see whether they are still needed.
How do I know a rule is hiding real findings?
Scan once with the rule and once without. Read the findings that appear only in the second run.
Last reviewed: 19 October 2026.
