What are the signs that a Semgrep rule is too broad or too narrow in real repositories?

Why Broad or Narrow Semgrep Rules Fail in Real Repositories

The sign of a rule that is too broad is not just extra findings, it is the loss of trust. When developers see matches on harmless code paths, test fixtures, or patterns that do not represent the intended risk, they start ignoring the rule. A rule that is too narrow creates the opposite failure: it looks precise, but it quietly misses the real code shape that appears across services, forks, wrappers, and slight variations in naming.

For Semgrep, the practical question is whether the rule consistently captures the underlying security or quality condition across the repository’s actual coding style. Repositories are full of aliases, helper functions, indirection, generated code, and copy-pasted variants, so a rule that works in a single file often degrades when faced with real engineering practice. In practice, the first signal of a bad rule is usually reviewer behaviour, not the pattern syntax itself.

What matters is whether the result set feels like the issue you intended to encode. If maintainers cannot quickly separate signal from noise, or if obvious examples are absent from the output, the rule is not yet tuned for the codebase it is meant to protect.

How It Works in Practice

A practical semgrep rule should be tested against three things: representative true positives, representative false positives, and the repository patterns that tend to hide the construct you care about. Good tuning is rarely about a single match. It is about whether the rule survives variation in naming, control flow, language features, and framework conventions without becoming noisy.

Signs that a rule is too broad usually appear as repeated false positives in common code patterns such as wrappers, logging, benign constants, guard clauses, or test data. Signs that it is too narrow usually appear when the same bug or insecure pattern is present in several files, but only one instance is reported because the rule overfits to a particular syntax form.

• Too broad: matches on code that is technically similar but semantically safe.
• Too narrow: misses obvious instances that differ only by variable names, function layering, or minor refactoring.
• Well-tuned: catches the intended pattern across the codebase with a manageable review burden.

The best validation method is to compare the rule output against a small, curated set of real repository examples, then expand to a wider sample and look for drift. If the rule only behaves correctly in one module or one coding style, it is not robust enough for repository-scale use. This is especially true in monorepos and polyglot services, where one pattern may appear in several idioms and abstraction layers.

One useful way to judge precision is whether a finding still looks actionable after a code owner reads the surrounding context. If the answer becomes “technically yes, but not actually a problem,” the rule is too broad. If the answer becomes “we definitely want to catch that, but this rule never sees it,” the rule is too narrow. These controls tend to break down when the codebase contains heavy abstraction, generated code, or framework-specific wrappers because the surface syntax stops resembling the underlying risk.

Common Variations and Edge Cases

Tighter Semgrep rules often reduce noise, but that usually increases maintenance cost, so teams have to balance precision against coverage. The right tradeoff depends on whether the rule is meant for education, developer workflow, or enforcement.

Autofix-capable or policy-style rules can tolerate slightly more breadth if the remediation is cheap and low risk. High-impact rules, especially those tied to release gates, need stronger precision because noisy failures create bypass pressure. Rules that target security issues in framework code often need extra care, since one syntactic pattern may represent many different runtime behaviours depending on context.

Edge cases also appear when a repository contains generated code, vendored dependencies, experimental branches, or intentionally duplicated examples. Those areas can make a rule look better or worse than it really is, so teams should not judge a rule only on a single project snapshot. They should also watch for scope drift: a rule that was written for one language feature can become too broad after a refactor or too narrow after a library migration.

When Semgrep output repeatedly forces the reviewer to ask “is this actually the same issue,” the rule needs adjustment; when it never finds the issue where engineers expect it, the rule is probably encoding the wrong abstraction. The most reliable tuning target is not perfect recall or perfect precision in the abstract, but stable, understandable results in the repositories that matter.

Practitioner Guidance

What to verify: Test the rule against at least one confirmed true positive, one confirmed false positive, and one nearby variant that should match but does not. That three-point check usually exposes whether the problem is overmatching, undermatching, or an incomplete pattern model.

What good looks like: Reviewers can explain the finding in one sentence, and the match set stays consistent after ordinary refactors such as renaming, helper extraction, or wrapper functions. If a small code change causes the rule to swing from noisy to blind, it is not stable enough yet.

Practitioner takeaway: A good Semgrep rule is one that preserves reviewer trust across real repository variation, not one that only looks correct on the exact syntax it was written against.

Related resources from NHI Mgmt Group

• What are the signs that a Sigma rule is too narrow for real-world threat hunting?
• What are the signs that authorization testing is too narrow for real-world web applications?
• What are the signs that ATT&CK coverage is too narrow for real incidents?
• What are the signs that a bot detection program is too narrow for real fraud prevention?