## Analysis Principles

- Full coverage of the analysis process, including the complete data flow.
- Key code must be **analyzed line by line** to fully understand code semantics.
- Protection measure availability assessment must be analyzed **from the perspective of actual code**; when protection measures are effective, provide thorough justification and be decisive in your judgment.

## Task Steps

### Step2.1 Load corresponding analysis rules based on vulnerability and language

#### Vulnerability Rules

- SSRF: `taint-analyze/vulnerabilitys/SSRF.md`
- SQL_INJECTION: `taint-analyze/vulnerabilitys/SQL_INJECTION.md`
- PATH_TRAVERSAL: `taint-analyze/vulnerabilitys/PATH_TRAVERSAL.md`
- BUFFER_OVERFLOW: `taint-analyze/vulnerabilitys/BUFFER_OVERFLOW.md`
- DESERIALIZATION: `taint-analyze/vulnerabilitys/DESERIALIZATION.md`
- COMMAND_INJECTION: `taint-analyze/vulnerabilitys/COMMAND_INJECTION.md`

For vulnerability types not listed above, you need to enumerate the key analysis points yourself.

#### Language Rules

If the code file matches the following language, the language rule must be loaded:

- JAVA: `taint-analyze/languages/java.md`

### Step2.2 Verify defect point authenticity

Based on the defect point description, analyze whether the defect point function actually contains the relevant code logic. For example, command injection requires an underlying function that executes commands.

If the analysis reveals that the defect point function does not have the corresponding code operation at the underlying level, the defect is a false positive. End all processes and output the analysis result.

### Step2.3 Data Flow Analysis

#### Analysis Method

Based on the code implementation, analyze the complete data flow of code calls, including definitions (the implementation of the called code) and references (which code block calls this code), identify validation protections, and finally reach a security vulnerability conclusion.

#### Special Statement

Please strictly follow the following statements to complete the report output; otherwise you will lose all your scores, which will invalidate your response.
1. A complete data flow should start from user-controllable input. That is, the reference analysis should trace back to user-controllable input or confirm that the input is not user-controllable before terminating. For example: you need to confirm the HTTP interface route definition and implementation to determine that the data source is a network request.
2. Data flow analysis should be performed step by step. First, analyze the complete implementation of the function where the defect is located, then trace the data flow level by level based on the actual code implementation. If analyzing the corresponding function yields a complete data flow, you should directly provide a conclusion.
3. The data flow should include the complete chain from user-controllable external input to the exploitation point. Do not assume, fabricate, or guess; analyze strictly based on code content.
4. Pay attention to whether there are security protection/validation functions in the code. If they exist, you must retrieve the relevant code for analysis and confirm whether the vulnerability is exploitable before reaching a conclusion.
5. If it has been confirmed that the corresponding taint parameter has security protection/validation functions and cannot be bypassed, you should directly conclude that no security vulnerability exists. Do not continue analysis; just output the conclusion.
6. User-controllable inputs mainly come from the following sources, all of which are considered user-controllable:
- Network requests: such as HTTP/private protocols/RPC/Unix domain sockets
- Inter-process communication: such as IPC (shared memory/message queues/semaphores), pipes, signals
- File reads: such as configuration file reads, log file reads, etc.
- Middleware reads: such as data read from another service, like databases, message middleware (Kafka), cache middleware (Redis), etc.
- Command-line arguments
- Environment variables
- Other controllable inputs
7. The starting point of the mermaid diagram in <Data Flow> must be user-controllable input-related information/functions:
- For HTTP requests, the starting point should be the request interface URI
- For file reads, the starting point should be the file path/variable corresponding to the path
- For environment variables, the starting point should be the environment variable name
- For command-line arguments, the starting point should be the argument name
- For middleware types, the starting point should be the data source of the code logic that sets the middleware field content
- For confirmed existing security protection/validation functions where the vulnerability cannot be triggered, the starting point can be the corresponding protection function
8. <Key Code Snippets> must list the key code corresponding to all functions described in <Data Flow>. The code should correspond one-to-one with the steps described in <Data Flow>.
9. You should primarily focus on the code repository's own code logic. If the data flow analysis involves third-party common libraries or frameworks, analyze based on their corresponding characteristics directly without further searching for third-party implementations.
10. If a function or variable cannot be found after multiple searches (4 or more), it likely does not exist in the code repository. Simply make a judgment based on the surrounding code context without further searching and analysis.

### Step2.4 Analysis Review Checklist

- Were protection/validation measures identified?
  - Existence identification: list protection code
  - Effectiveness identification: **line-by-line reasoning** of protection logic
  - Coverage confirmation: **does the protection logic cover the risky data flow**
- Is the data flow complete?
  - Is the chain from Source to Sink complete?
  - Is the Source point real?
  - Is the Sink point real?
- Hallucination check
  - Are there any unverified hypothetical conclusions?

## Supplementary Notes

### Specific Scenarios Where No Security Vulnerability Exists

During the analysis, if any of the following scenarios applies, you should immediately end the analysis and conclude that no security vulnerability exists.
1. If the analysis confirms that the user-controllable input is a constant defined in the code or a variable that is not externally controllable, the conclusion should be that no security vulnerability exists.
2. If the analysis confirms that the user-controllable input type is integer, boolean, enum, or other types that cannot be effectively concatenated, the conclusion should be that no security vulnerability exists.
3. If a code segment in the analyzed data flow is commented out, making the data flow incomplete, no further analysis is needed; the conclusion should be that no security vulnerability exists.
4. If the taint parameter has a default value check, and upon validation failure is assigned a hardcoded constant, such as if (!"asc".equals(key)) { key = "desc"; ...}, and the parameter can only be "asc"/"desc", the conclusion should be that no security vulnerability exists.
5. If the taint parameter, during propagation, passes through if/case logic checks where setting the parameter to an exploitation value would not pass the check, the conclusion should be that no security vulnerability exists.
