# Checklist

Please strictly verify the historical conversation records and the output report against the following checklist items. Confirm each item one by one; otherwise you will be penalized.

## Reasoning Process Check

Primarily checks historical conversation records / tool call history.

### Reasoning Hallucination Check

1. All code analysis has been fully closed-loop; there are no functions remaining to be analyzed.
2. All conclusions are supported by relevant code evidence; there are no hypothetical/guessed conclusions (except when code cannot be accessed).

### Code Chain Integrity Check

1. Unless it has been confirmed that the vulnerability is unexploitable or that the corresponding parameters are already protected or validated, the analysis process must trace back to the code/function that parses user-controllable input.
2. If the code chain contains security protection/validation functions, the corresponding code must be retrieved for analysis, and a conclusion on safety must be reached. If it is confirmed that the vulnerability cannot be triggered, the <Code Chain Integrity Check> passes.
3. If the trace leads to user-controllable input being an HTTP request, the corresponding interface URI must be explicitly identified.
4. When the controllable input originates from middleware (databases, caches, message queues, etc.), search for code logic that sets the corresponding field content.
5. For conclusions stating that no security vulnerability exists, if any of the following specific scenarios apply, there is no need to provide complete code, and the <Code Chain Integrity Check> passes:
    - Confirmed that the user-controllable input is a constant defined in the code or a variable that is not externally controllable.
    - Confirmed that the user-controllable input type is integer, boolean, enum, or other types that cannot be effectively concatenated.
    - A code segment in the data flow is commented out, making the data flow incomplete.
    - SQL injection vulnerability: if it involves simple numeric concatenation, uses parameterized preprocessing, ORM framework, or other protections.
    - Server-Side Request Forgery (SSRF) vulnerability: if there are security protection/validation functions, the corresponding parameter is integer or boolean type (unexploitable), or it cannot be directly controlled (e.g., read from configuration files, environment variables, database queries, or other methods that are not actually directly controllable and require prior control of the corresponding file or environment).
    - File path traversal, path injection, or other file-related vulnerabilities: confirmed that no file read/write operations exist.
    - After multiple searches, the corresponding function or variable cannot be found, and combined with code context analysis, the function's purpose has been explained and conforms to the code logic; in this case, the <Code Chain Integrity Check> passes.
6. The current analysis chain covers one of the following:
    - Parse user input -> taint variable propagation -> trigger vulnerability
    - Confirm absence of security protection/validation -> taint variable propagation -> trigger vulnerability
    - Confirm existing security protection/validation -> cannot trigger vulnerability
    - Confirm matching specific scenario where no security vulnerability exists -> cannot trigger vulnerability
7. If the analysis involves third-party code or frameworks, the analysis may be based on framework characteristics and project usage patterns without providing complete code.

## Report Structure Check

Primarily checks the output report.

### Vulnerability Existence

1. Existence conclusions are only allowed in two categories: exists / does not exist.

### Vulnerability Exploitation Conditions and Trigger Method

1. Vulnerability exploitation conditions and trigger method must correspond to each other with logical consistency; contradictions must not occur. If contradictions exist, the <Exploitation Conditions and Trigger Method> check fails.
2. The key is to verify whether the constraints on taint parameters in the exploitation conditions (such as numeric values, regex, enum types) contradict the items listed in the trigger method. Contradictions cause the <Exploitation Conditions and Trigger Method> check to fail. For example: if the regex filters single quotes, the trigger method cannot include single quotes.

### Data Flow

#### Controllable Input Constraint Check

1. When the controllable input is an HTTP request type, the <Data Flow> starting point must be the relevant interface URI.
2. When the controllable input is a file read type, the <Data Flow> starting point must be the corresponding file path.
3. When the controllable input originates from middleware (databases, caches, message queues, etc.), identify the code logic that sets the corresponding field and trace the data flow.
4. If it is confirmed that the relevant taint parameters all have security protection/validation functions and the vulnerability cannot be triggered, the <Controllable Input Constraint Check> passes.
5. If the conclusion is that no security vulnerability exists and the <Code Chain Integrity Check> passes, the <Controllable Input Constraint Check> passes.

#### Coverage Check

1. The <Data Flow> must cover the complete propagation chain obtained from the reasoning analysis.

### Key Code Snippets

1. The code listed in <Key Code Snippets> must correspond one-to-one with the steps in the <Data Flow>; omissions are not allowed.


# Checklist Evaluation Output Definition

You must output your evaluation results in the following XML structure:
<result>
<conclusion>Pass/Fail</conclusion>
<explain>Brief explanation of the pass/fail reason</explain>
<advice>Next step action recommendation: output report/
1. Retrieve xxx code, continue analysis
2. xxx
</advice>
</result>

Example 1:
<result>
<conclusion>Fail</conclusion>
<explain>The current analysis process did not explicitly identify the interface URI corresponding to the HTTP request, and there may be security protection/validation functions that were not analyzed, failing the code chain integrity check</explain>
<advice>Next step action recommendation:
1. Retrieve route binding code, continue analysis, and identify the interface URI
2. Retrieve the possible validation function validator.check_input_and_output_valid implementation, and analyze whether it is sufficiently secure
</advice>
</result>

Example 2:
<result>
<conclusion>Pass</conclusion>
<explain>All checklist items have passed</explain>
<advice>Next step action recommendation: output report</advice>
</result>
