What Is Semgrep Rule? Definition & Examples

A Semgrep rule is a pattern that tells the scanner what code construct to look for and what to report when it appears. Rules can detect vulnerabilities, code smells, and style problems. In practice, the value comes from matching the rule to the language, framework, and security risk the team actually needs to control.

Expanded Definition

A Semgrep rule is a pattern-based detection instruction that defines what source code, configuration, or infrastructure-as-code construct should be matched and what finding should be reported. It is used to identify security issues, correctness problems, and code quality concerns before they reach production. The practical boundary is important: a rule is not the vulnerability itself, and it is not a generic policy statement. It is a precise search condition that must fit the language syntax and the control objective you want to enforce.

Guidance versus consensus: there is broad agreement that rule precision matters more than rule volume, but teams disagree on how aggressively to tune for false positives versus missed findings. A noisy rule can be ignored; an overly narrow rule can miss the exact construct you meant to govern. In other words, the operational quality of a Semgrep rule depends on context, not just syntax.

For readers working in security engineering, the main misunderstanding is treating all rules as equally useful. A rule for a style issue and a rule for an authentication flaw serve very different governance purposes, even if they are both written in the same format.

Examples and Use Cases

Semgrep rules commonly appear in workflows where teams want code-level policy checks that are fast enough to run early and often. They are especially useful when the security question can be expressed as a recognisable code pattern rather than a runtime-only behaviour.

Detecting insecure use of dangerous functions, such as deserialisation paths or command execution wrappers.
Flagging hardcoded secrets, tokens, or API keys in application source before code is merged.
Identifying missing input validation or unsafe data flows in web application handlers.
Checking infrastructure-as-code for overly permissive cloud permissions or insecure defaults.
Enforcing team-specific secure coding conventions where the organisation wants a policy check, not just a vulnerability scan.

The tradeoff is that rule quality depends on how well the pattern reflects the exact coding idiom used by the team. A rule that is too generic may produce broad noise, while a rule that is too specific may only catch one implementation variant and miss the rest. That is why practitioners usually validate rules against representative code samples before relying on them in a build pipeline.

Security Implications

When Semgrep rules are poorly designed, the failure mode is usually not a dramatic tool outage but weak detection coverage. Teams may believe they are scanning for an entire class of issues while actually only catching one syntax shape. That gap matters because code review and automated scanning are often the last consistent opportunity to stop insecure patterns before deployment.

A noisy rule can also create alert fatigue. If developers see too many low-value findings, real issues get triaged like routine clutter. The result is a governance problem as much as a technical one: security intent exists, but enforcement no longer has credibility. Conversely, a brittle rule that only matches one library call or one framework version can create a false sense of assurance.

For NHI-adjacent code, this can be particularly relevant when rules are used to spot exposed credentials, unsafe token handling, or weak service-to-service authentication patterns. The practitioner observation is straightforward: rule design should reflect the real failure modes in the codebase, not an abstract ideal of secure coding.

Domain and Governance Relevance

Semgrep rules matter in broader application security because they turn secure coding expectations into repeatable checks that can be embedded in pull requests, CI pipelines, and repository governance. That makes them useful for ownership decisions: which findings are mandatory, which are advisory, and which need exception handling.

In identity-heavy systems, the relevance increases when code is responsible for secrets, tokens, service accounts, or delegated access paths. A rule that catches unsafe credential storage or overly permissive access logic supports Non-Human Identity governance indirectly by reducing the number of machine-authentication weaknesses that reach production. For teams managing agentic workflows, the same logic can help surface unsafe tool invocation or unguarded access to sensitive endpoints.

If your organisation uses policy-as-code patterns, Semgrep rules become part of the control layer rather than just a developer convenience. Their value is not only in finding defects, but in making security expectations visible, reviewable, and enforceable at the point where code is changed.

Risk and Threat Considerations

Semgrep rules introduce risk when they are treated as equivalent to real assurance. The material exposure is missed detection, especially when a rule only matches narrow syntax or fails to reflect common framework variants. That creates a gap between what teams think they are checking and what is actually being enforced.

Failure mechanism: attackers and insecure changes benefit when the rule set is incomplete, overly noisy, or tuned to the wrong code pattern. In practice, dangerous constructs can pass review because the scanner never matched the specific implementation style, or developers can start discounting findings after repeated false positives.

Impact: vulnerable code, exposed secrets, weak access logic, and insecure token handling can move through the pipeline into production. Over time, the organisation loses confidence in automated scanning, and control coverage becomes inconsistent across repositories and languages.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	8 — Audit Log Management	Semgrep supports early detection of insecure code patterns before release.
	16 — Application Software Security	Rules enforce secure coding checks against application vulnerabilities.
	5 — Account Management	Rules can detect hardcoded secrets and unsafe credential handling in code.
Recommendation — Use CIS Control 8 to centralise scan findings and preserve reviewable evidence of security checks. Apply CIS Control 16 to embed Semgrep rules into secure development and code review gates. Use CIS Control 5 to flag and remove embedded credentials from source code.
OWASP Non-Human Identity Top 10	NHI-01 — Inventory and Ownership of Non-Human Identities	Semgrep can surface code paths that create or handle machine credentials.
	NHI-03 — Secrets and Credential Management	Rule patterns often target hardcoded tokens, keys, and insecure secret handling.
Recommendation — Map code checks to NHI-01 and inventory every service identity path that code can create or expose. Apply NHI-03 to detect exposed secrets and enforce safer credential storage patterns.

Practitioner Guidance

Why practitioners should care: the value of a Semgrep rule is measured by whether it consistently catches the exact issue you meant to control. Teams should treat rule authoring as part of security engineering, not as a one-time scanning setup task.

What to watch for: the common warning sign is a rule set that produces either too many low-value findings or too few meaningful ones. Both usually indicate that the rule logic is not aligned with the actual code patterns in use.

Practitioner takeaway: validate rules against real code examples and review false positives and false negatives together, because both affect whether the control is trusted.

Semgrep Rule