gitcode-pr-security-review

GitCode PR Security Review

Overview

Automatically review code security issues in Pull Requests of GitCode repositories, use the sdk-security-audit skill for security analysis, and publish the review results as comments to the corresponding PR.

Workflow

1. Obtain the GitCode access token

From the environment variable GITCODE_TOKEN obtain the GitCode access token. If the environment variable does not exist, use the question tool to prompt the user to enter the GitCode access token.

2. Obtain the repository URL

Use the question tool to prompt the user to enter the GitCode repository URL address.

Parse the repository URL, extract the owner and repo information.

Supported URL formats:

• https://gitcode.com/owner/repo
• https://gitcode.net/owner/repo

3. Obtain all Pull Requests in Open status

Use the GitCode API to obtain all Pull Requests in Open status of the repository:

GET https://gitcode.com/api/v5/repos/{owner}/{repo}/pulls?state=open

Request headers:

Authorization: Bearer {GITCODE_TOKEN}

4. Traverse each Pull Request

For each Pull Request, perform the following steps:

4.1 Obtain the PR's file changes

Use the GitCode API to obtain all file changes of the PR:

GET https://gitcode.com/api/v5/repos/{owner}/{repo}/pulls/{number}/files

Request headers:

Authorization: Bearer {GITCODE_TOKEN}

The response contains the change information for each file, including:

• filename: file path
• patch: diff content of the change
• additions: number of added lines
• deletions: number of deleted lines

4.2 Extract the changed code

For each file, extract the changed code content from the patch field.

Parse the diff format, identify the newly added code lines and their line numbers.

Important: code review should only target the newly added code, ignoring deleted code.

4.3 Perform code security review

Try to use the sdk-security-audit skill：

First try to use the skill tool to load the sdk-security-audit skill, and perform a security review on the changed code.

Pass the following information to the sdk-security-audit skill:

• File path
• Changed code content
• Corresponding line number range

Fallback mechanism：

If the sdk-security-audit skill does not exist or fails to load, use the built-in strict audit logic:

1. Audit principles：

   • 0 false positives: prefer missing a report over making a false report
   • Evidence-driven: only report issues with clear evidence
   • Conservative and strict: only report security issues that are 100% certain

2. Scope of inspection(only inspect newly added code):

   • Buffer overflow: directly using user-input length/index without checking bounds
   • Null pointer dereference: directly dereferencing a pointer without checking for NULL
   • Memory leak: no corresponding free/delete after malloc/new
   • Uninitialized variable: using an uninitialized local variable
   • Format string vulnerability: user input directly used as a printf format string
   • Integer overflow: arithmetic operations may cause overflow and are not checked
   • SQL injection: user input is directly concatenated into SQL statements
   • Command injection: user input is directly concatenated into system/exec commands

3. Evidence requirements：

   • The complete code context must be visible
   • The existence of the problem must be clearly proven
   • It must be determined to be reachable from external input
   • It must be determined that the necessary checks are missing

4. Report format：

   ## [HIGH] {问题标题}
   
   - **问题类型**：{类型}
   - **文件位置**：{file_path}:{line_number}
   - **问题代码**：{问题代码片段}
   - **风险描述**：{详细描述}
   - **修复建议**：{具体修复方案}
   

5. Silence rules：

   • Uncertain potential issues → do not report
   • Cannot be judged due to lack of context → do not report
   • May exist but cannot be proven → do not report
   • Code style issues → do not report
   • Performance suggestions → do not report

4.4 Generate review results

Based on sdk-security-audit the output of the skill, generate the review results, including:

• Security issue description
• Severity
• Code location (file path and line number)
• Fix suggestions

Important: only handle high-confidence security issues, and ignore low-risk and medium-risk issues.

4.5 User confirmation

Use question the tool to show the review results to the user and ask whether to continue posting comments.

If the user confirms, continue to the next step; otherwise, skip the current PR.

4.6 Post comments to the PR

For each high-confidence security issue, use the GitCode API to post a comment to the corresponding PR:

POST https://gitcode.com/api/v5/repos/{owner}/{repo}/pulls/{number}/comments

Request headers:

Authorization: Bearer {GITCODE_TOKEN}
Content-Type: application/json

Request body:

{
  "body": "安全问题描述和修复建议",
  "commit_id": "{commit_id}",
  "path": "{file_path}",
  "position": {line_number}
}

Where:

• body: security issue description and fix suggestions
• commit_id: the latest commit ID of the PR
• path: file path
• position: code line number

Important: each issue should be posted as a separate comment; do not combine multiple issues into one comment.

5. Process the next PR

After completing the review of the current PR, determine whether high-confidence security issues were found:

• If high-confidence issues are found: after posting comments, ask the user whether to continue reviewing the next PR
• If no high-confidence issues are found: automatically continue reviewing the next PR without user confirmation

6. Complete the review

After completing the review of all PRs, report a summary of the review results to the user.

Resources

scripts/

This skill uses the following scripts:

• gitcode_api.py: GitCode API interaction tool, containing the following functions:
  • Get PR list
  • Get PR file changes
  • Post PR comments

references/

• gitcode_api_docs.md: GitCode API documentation reference, containing explanations of the API endpoints used