Pattern sanitizers tell Semgrep to stop treating data as dangerous after the code validates or removes the risky input, so findings inside that guarded path are suppressed. Pattern propagators do the opposite: they describe how tainted data spreads into another variable or structure. Sanitizers reduce false positives, while propagators expand detection to cover taint that changes shape.
How pattern sanitizers and propagators change taint analysis coverage
Pattern sanitizers and pattern propagators are both taint-mode rules, but they serve opposite purposes in the analysis model. A sanitizer tells the engine where taint should stop because the code has validated, normalised, or removed the risky property. A propagator tells the engine how taint continues when data is copied, transformed, concatenated, or moved into a new container. The practical difference is whether the rule narrows the search space or preserves it as data changes shape.
That distinction matters because taint analysis is only useful when its dataflow assumptions match the code’s real behaviour. If sanitizers are too broad, they hide findings that still matter. If propagators are too weak, taint disappears too early and real exposure is missed. Semgrep’s taint mode is therefore not just about flagging sources and sinks, but about teaching the engine which operations change risk and which operations merely repackage it. In practice, many security teams encounter false confidence only after a validation step was treated as a complete cleanse rather than a partial check.
How Semgrep uses each rule in a taint-mode path
In taint mode, the analysis follows the path of untrusted input across assignments, function calls, object fields, and derived values. Pattern propagators extend that path. They are useful when data moves into another variable, is embedded into a larger string, or is wrapped in a structure that still preserves the original tainted content. Without propagators, the engine may lose sight of the flow once the code stops using the exact original variable name.
Pattern sanitizers work at the control point where the code meaningfully reduces risk. They are best reserved for checks that actually neutralise the dangerous property for the sink being analysed. A length check, for example, may be a valid sanitizer for one class of injection risk but not for another. That is why sanitizers should reflect the exact security assumption being made, not just any validation-looking code.
- A propagator preserves taint when the underlying value still carries risk after transformation.
- A sanitizer ends taint only when the code has actually made the input safe for the relevant sink.
- Both rules depend on context, because the same operation can be safe for one threat model and unsafe for another.
The most common implementation mistake is treating any validation as a full sanitizer and any copy as taint-neutral. That breaks the model in both directions: real issues vanish when taint is cleared too early, and noisy findings appear when taint is allowed to flow through operations that genuinely constrain it. For a practical reference on how machine-identity and access assumptions can also be mis-modelled when controls are applied too broadly, see the OWASP Non-Human Identity Top 10 at OWASP Non-Human Identity Top 10. Where the codebase uses shared helpers or layered wrappers, this guidance breaks down if the rule writer cannot express the exact point at which risk is removed or merely forwarded.
Where the distinction becomes misleading in edge cases
Tighter taint modelling often increases maintenance overhead, requiring teams to balance precision against rule complexity. That trade-off becomes visible when code performs partial validation, canonicalisation, or context-specific escaping.
Some routines look like sanitizers but only protect one downstream use. Others look like propagators but actually strip the property that matters to the sink. The consensus view is that rule authors should model the exact sink context rather than assuming one universal notion of safety, because the same transformation can be a sanitizer for SQL injection and merely a propagator for downstream logging or templating issues.
Another edge case is chained processing. A value may be filtered, then re-encoded, then merged into a composite object. In that chain, one step may just reshape the data while another genuinely reduces exposure. The difference between the two is operationally important because it determines whether a finding should be suppressed, tracked, or expanded across later flows. Where that chain crosses multiple libraries or abstraction layers, the safest assumption is to preserve taint until the code proves otherwise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 16 — Application Software Security | Taint rules model secure input handling and code-level validation behavior. |
| Recommendation — Apply Control 16 to review input handling paths and prevent unsafe dataflow assumptions. | ||
| MITRE ATT&CK | T1027 — Obfuscated Files or Information | Propagation and sanitization both affect how risky content is transformed and recognized. |
| Recommendation — Track transformation patterns that preserve risky content and tune detections accordingly. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Taint modeling governs when data remains risky as it moves through processing steps. |
| Recommendation — Use PR.DS to validate where data remains sensitive after transformation or filtering. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership of Non-Human Identities | Not directly applicable to this question; omitted? |
| Recommendation — Do not use | ||
Practitioner Guidance
What to prioritise: Model sanitizers only when a check truly makes the value safe for the specific sink you are analysing. If the code merely validates format, length, or type, treat that as a candidate control, not an automatic taint stop.
What to verify: Confirm that propagators capture every transformation that preserves meaning, including string building, object wrapping, field assignment, and helper methods. If taint disappears at an abstraction boundary, the rule set is probably under-modelled.
Common mistake: Teams often overuse sanitizers because suppression feels cleaner than tuning propagation. That shortcut tends to create blind spots in the exact paths that matter most, especially where input is normalised but still attacker-controlled.
Practitioner takeaway: The right balance is not “more sanitizers” or “more propagators,” but a rule set that matches how the application actually changes trust in the data as it moves.
Related resources from NHI Mgmt Group
- What is the difference between a rules-based secret scanner and a hybrid scanner?
- What is the difference between sandbox mode and true network isolation for AI workloads?
- What is the difference between static access rules and evidence-based access decisions?
- What is the difference between pattern matching and AI-native classification for sensitive data?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
