Local Rule

Expanded Definition

A local rule is a Semgrep rule written and owned by the team that runs the scan, rather than imported from a shared catalogue. In practice, it lets security or engineering teams encode organisation-specific patterns, exceptions, or risky coding habits that generic rule packs may miss. Local rules can be temporary, for a one-off investigation, or committed as YAML for repeated use across repositories.

The boundary that matters most is between reusable signal and ad hoc tuning. A local rule is not the same as a vendor-maintained rule set, and it is not automatically a policy standard simply because it exists in the scanner. Guidance versus consensus is important here: the prevailing practice is to use local rules for narrow, high-value detections while avoiding a proliferation of one-off rules that nobody curates. That distinction is easy to miss when teams treat every exception as a permanent rule.

For readers comparing it with adjacent concepts, the key difference is ownership. A central rule pack defines broad baseline coverage; a local rule captures local context, such as an internal framework usage pattern, a bespoke API wrapper, or a code path that only exists in one product line.

Examples and Use Cases

Local rules tend to appear when a team needs detection fidelity that shared content cannot provide. They are especially common in mature codebases where the most important findings come from organisation-specific conventions rather than generic vulnerabilities.

• A platform team writes a rule to flag a prohibited internal helper that wraps secret handling in an unsafe way.
• A product team creates a temporary rule to search for a newly discovered insecure pattern while a broader rule pack is still catching up.
• A security engineer stores a YAML rule in the repository so the same custom check runs in CI on every pull request.
• A team tunes a rule to reduce noise in a framework-specific code path that otherwise produces repeated false positives.

The main trade-off is maintenance burden. Local rules improve relevance, but they also create ownership questions: if the author leaves or the code pattern changes, the rule can become stale quickly. That is why a local rule works best when it is tied to an identifiable control need and reviewed like other security logic, not treated as a throwaway scanner tweak.

Security Implications

Local rules matter because they can close coverage gaps that generic scanning misses. If an organisation has a custom authentication wrapper, a proprietary secrets manager, or a recurring insecure coding pattern, a shared rule set may never recognise it as risky. In that case, the absence of a local rule can leave a blind spot even when scanning appears to be enabled and healthy.

Mismanaged local rules create their own risks. Overly broad rules can flood developers with false positives, which leads to alert fatigue and eventual rule abandonment. Overly narrow rules can encode a false sense of assurance because teams believe a control exists when it only catches one variant. A common practitioner observation is that local rules fail most often at the lifecycle stage, not at creation: they are written for a specific incident or code smell, then never revised as the codebase evolves.

In security operations, the consequence is uneven visibility. One repository may have strong custom detection while another has none, producing inconsistent enforcement across similar systems.

Domain and Governance Relevance

Local rules sit at the intersection of code security, scan governance, and detection ownership. They matter most when an organisation wants to translate local knowledge into repeatable scanning logic without waiting for upstream rule maintenance. In that sense, the rule itself is a governance artefact as much as a technical one: it captures what the team considers important enough to detect consistently.

For identity and NHI-heavy environments, local rules become more valuable when the codebase contains service accounts, API keys, tokens, or custom automation paths that standard application rules do not model well. That does not make the term inherently an identity concept, but it does mean local rules often become the practical place where machine-credential misuse patterns are detected in code before they reach production.

Governance breaks down when nobody owns rule quality, exception handling, or retirement. Teams that want local rules to remain useful need a clear boundary between tactical scanning logic and durable security policy.

Related resources from NHI Mgmt Group

• Why are local .env files and config notes risky in Microsoft 365?
• How should teams respond to a local Linux privilege escalation flaw in shared environments?
• What is the difference between global identity strategy and local governance?
• How should security teams handle local accounts in cloud and SaaS apps?