Pattern-Either

Expanded Definition

Pattern-either is a Semgrep pattern operator that broadens a single rule without making it vague. It tells the engine to match any one of several alternative code shapes, which is useful when the same weakness appears through different syntactic forms, imports, annotations, or method calls.

The key boundary is that all branches should describe the same underlying issue. If the alternatives are really different behaviours, different risk conditions, or different remediation paths, they usually deserve separate rules. Pattern-either is for expressing equivalence in matching logic, not for collapsing unrelated findings into one bucket.

In practice, this makes rule authoring more maintainable. A security author can cover language-specific variations while keeping the intent of the rule readable, testable, and easier to tune. That is especially important in code scanning, where brittle rules either miss real issues or create noisy alerts.

Definitions vary a little across static analysis tooling, but the operational meaning is consistent: pattern-either is a matcher for alternatives, while the rest of the rule still determines context, constraints, and severity. The operator helps express “any of these forms” cleanly, not “anything similar.”

Examples and Use Cases

Typical uses for pattern-either include:

• matching the same insecure API call in several language idioms, such as different helper functions that all reach the same sink;
• covering multiple annotation or decorator combinations that enable the same security condition;
• capturing different import paths or aliasing patterns without duplicating the full rule;
• detecting repeated risky constructs across framework variants, while keeping the rule concise enough to maintain;
• reducing rule sprawl when one policy must apply to several acceptable code shapes but one security outcome.

The tradeoff is breadth versus precision. A wider matcher can improve coverage, but every added alternative increases the chance of accidental matches if the surrounding constraints are too weak. Good Semgrep rules usually pair pattern-either with enough context to ensure the alternatives really represent the same issue.

For teams writing large rule sets, the practical value is consistency. It is easier to review one carefully structured rule with several alternatives than five near-duplicates that drift over time.

Security Implications

Pattern-either matters because rule quality directly affects detection quality. If the operator is used too narrowly, security scanning misses real variants of the same flaw. If it is used too broadly, analysts inherit false positives and spend time triaging code that is not actually risky.

That failure mode is common in heterogeneous codebases where the same security weakness appears through framework wrappers, helper functions, or language-specific shorthand. The problem is not the operator itself, but the assumption that syntactic alternatives always map to the same security meaning.

Failure mechanism: weak surrounding constraints let one permissive alternative match unrelated code, while an overly strict branch fails to catch a legitimate variant. In both cases, the rule becomes less trustworthy as a security control.

Impact: teams either miss exploitable patterns or lose confidence in the scanner because of noisy results. Over time, that weakens review quality, slows remediation, and can leave recurring classes of issues unaddressed.

Security, Operational and Governance Implications

From a governance perspective, pattern-either is part of rule engineering discipline. It helps security teams encode policy once while still respecting the reality that secure and insecure code often looks different across languages, frameworks, and developer styles.

The operational implication is that rule maintainers need to validate each branch as if it were a small test case. A branch that is technically valid but semantically too loose can dilute the rule, while a branch that is too specific can create blind spots in production scans.

For practitioners, the important judgement is not “can I express more alternatives?” but “do these alternatives truly represent the same control objective?” When the answer is yes, pattern-either is an efficient way to improve maintainability without losing intent.

Used well, it supports consistent enforcement across varied codebases. Used carelessly, it turns a precise detection into a catch-all pattern that is harder to trust and harder to govern.

Related resources from NHI Mgmt Group

• What is the difference between pattern matching and AI-native classification for sensitive data?
• What breaks when organisations use one Azure identity pattern for every workload?
• Why do standing NHI credentials remain such a high-risk pattern?
• Why do MCP and A2A together create more identity risk than either one alone?