A pattern sink is the point where tainted data becomes dangerous, such as a deserialization call, command execution, or another security sensitive operation. Taint rules flag matches when data from a source reaches a sink without being cleaned, validated, or constrained in a way the rule recognises.
Expanded Definition
A pattern sink is the security-sensitive operation where a tainted value becomes dangerous because the program actually does something with it. In taint analysis, the sink is not merely a destination in code flow; it is the point at which input can trigger impact such as object construction, command execution, SQL invocation, template rendering, file access, or privilege-relevant actions. That distinction matters because many variables are only risky when they reach a specific operation, not when they are merely stored or passed around.
Guidance versus consensus is worth noting here. Most tooling and secure-coding discussions agree on the broad idea of a sink, but exact sink sets vary by language, framework, and rule pack. A deserialization call may be a sink in one context and an ordinary library call in another if the rule cannot establish exploitability. NHIMG treats the term as a control-point concept: the security meaning comes from the operation being sensitive, not from the presence of taint alone.
A common misunderstanding is to treat every function that receives user input as a sink. In practice, the boundary is narrower: a sink is the operation where misuse can create harm if upstream validation, cleansing, or constraint is insufficient.
Examples and Use Cases
Pattern sinks appear in static analysis, code review, and secure SDLC workflows whenever engineers need to decide which flows are actually hazardous. The same source may be harmless in one branch and dangerous in another because the sink changes the security profile.
- A deserialization routine becomes a sink when attacker-controlled bytes can influence object creation or gadget execution.
- A command execution wrapper becomes a sink when unsanitised arguments can alter the shell command that runs.
- A database query API becomes a sink when string concatenation bypasses parameterisation and input constraints.
- A template engine becomes a sink when untrusted content can change rendering behaviour or execute template expressions.
- A file write or path-handling operation becomes a sink when tainted input can redirect the target location or overwrite sensitive files.
In practice, the tradeoff is precision versus coverage. Broader sink definitions catch more risky flows but can produce noisy findings, while narrower sink definitions improve confidence but may miss edge cases that depend on framework-specific behaviour.
Security Implications
Misidentifying a sink weakens the entire taint rule because the analysis either misses real exposure or floods reviewers with false positives. If a dangerous operation is not modeled as a sink, tainted data can reach code paths that are treated as safe, which hides exploitable flows in review, testing, and automated scanning. If too many ordinary calls are modeled as sinks, teams stop trusting the rule output and the useful alerts get lost in noise.
The practical consequence is control failure at the moment of impact. The source may be remote and low trust, but the sink is where that data can change program behaviour, create an injection condition, or trigger irreversible action. For practitioners, the observable symptom is often a repeated alert around a sensitive API that still remains unresolved because teams disagree on whether the call is truly exploitable in the application context.
Domain and Governance Relevance
Pattern sinks matter most in application security governance because they define where input validation, sanitisation, and constrained APIs must be enforced. Without a clear sink model, secure coding standards become vague and code review cannot consistently separate benign data handling from security-sensitive operations. That is why sink catalogues often become part of rule tuning, secure language guidance, and validation policy.
For identity and access-adjacent systems, the term becomes especially relevant when tainted input can influence authentication, authorisation, or credential-handling logic. In those cases, the sink is not just an implementation detail; it marks the boundary where untrusted data could affect access decisions, session state, or administrative actions. NHIMG treats that boundary as governance-relevant because it determines where security controls must be strictest and where analyst attention should be concentrated.
If the sink definition is wrong, the organisation may approve code paths that should have been blocked or monitored, which turns a static-analysis concept into a real control gap.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK 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 | Pattern sinks are core to secure coding and SAST tuning. |
| Recommendation — Define and tune sinks in secure code review to catch unsafe input-to-impact flows. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Unsafe sinks often become exploit paths in exposed applications. |
| Recommendation — Map unsafe sinks to exploit paths and prioritize exposed application code paths for testing. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Sinks mark where untrusted data must be constrained before sensitive operations. |
| PR.IP — Information Protection Processes and Procedures | Sink definitions are part of secure development and code review procedures. | |
| Recommendation — Apply data-handling controls at sink points to prevent tainted input from triggering sensitive actions. Embed sink catalogues into secure development procedures and review gates. | ||
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 voice and contact-centre workflows need a different identity pattern from normal SSO?
