mirror of
https://github.com/cesanta/mongoose.git
synced 2026-11-06 15:51:25 +00:00
127 lines
7.4 KiB
Markdown
127 lines
7.4 KiB
Markdown
Review only changes under `src/` in the complete PR diff. Ignore all other changes in the PR.
|
|
|
|
# OBJECTIVE
|
|
|
|
Perform a security-focused code review to identify HIGH-CONFIDENCE security vulnerabilities that could have real exploitation potential.
|
|
|
|
This is not a general code review - focus ONLY on security implications newly added by this PR under `src/`. Do not analyze, count, or report changes outside `src/`. Do not comment on existing security concerns.
|
|
|
|
For this task, you will rely on the specified shared security-review sections in `resources/specs/claude-security-scan.md`, the specified security-guidance sections in the six `resources/specs/areas/*.md` prompts listed below, and `resources/specs/claude-false-positive-filtering.md` detailing patterns, precedents, exclusion rules based on which some of the identified vulnerabilities will be excluded from the final reporting. The instructions, rules and criterias found in those referenced sections and the filtering file are MANDATORY TO BE HONOURED and your security audit will have to take all of them into account.
|
|
|
|
YOU MUST READ AND ANALYZE THE SPECIFIED SECTIONS AND THE FILTERING FILE BEFORE COMMENCING THE SECURITY AUDIT. THESE SOURCES WILL BE MENTIONED IN THE FOLLOWING PARTS OF THIS PROMPT, PROVIDING FULL CONTEXT FOR ACCOMPLISHING THE GIVEN TASK.
|
|
|
|
# CRITICAL INSTRUCTIONS
|
|
1. MINIMIZE FALSE POSITIVES: Only flag issues where you're >80% confident of actual exploitability
|
|
2. AVOID NOISE: Skip theoretical issues, style concerns, or low-impact findings
|
|
3. UNDERSTANDING CONTEXT AND SCOPE OF REVIEW: In `resources/specs/claude-security-scan.md`, read only the `External Attacker Threat Model` and `Mongoose-Specific Security Review Scope` subsections found in the `SECURITY SCAN CONTEXT` main section for a full understanding of the scanning model, code review context and the perspective from which the scanning is going to take place. Do not apply unrelated full-scan instructions from that file. In particular, do not inherit assigned-area scan scope, full-scan JSON output requirements, full-scan `review_completed` semantics, instructions to scan long-standing code independently of the PR, or area-selection workflow behavior. This PR prompt's scope, methodology, validation, and output rules remain authoritative.
|
|
4. TREAT EXCLUSIONS AS MANDATORY. The exclusions section below is mandatory. If a potential finding falls under an exclusion, do not report it. If a finding partially overlaps an exclusion, only report it if there is a concrete, non-excluded security impact.
|
|
|
|
# SECURITY CATEGORIES TO EXAMINE
|
|
|
|
Read the general/common security categories in the `GENERAL SECURITY CATEGORIES TO EXAMINE` section of `resources/specs/claude-security-scan.md`.
|
|
|
|
Also read the `Area-Specific Security Guidance` section from every area prompt:
|
|
|
|
* `resources/specs/areas/common_misc.md`
|
|
* `resources/specs/areas/mongoose_core.md`
|
|
* `resources/specs/areas/web_http_auth.md`
|
|
* `resources/specs/areas/tls.md`
|
|
* `resources/specs/areas/net_builtin.md`
|
|
* `resources/specs/areas/protocols.md`
|
|
|
|
Use only the security guidance from the area prompts and ignore their full-scan-specific `Target` sections. Consider the complete set of common and area-specific security categories for every file the PR modifies under `src/`. Do not choose one area or make this PR review area-scoped. Ignore all other changed paths and report only security vulnerabilities introduced by the PR under `src/`.
|
|
|
|
Use these categories to guide prioritization, not as a checklist requiring equal coverage of every item.
|
|
|
|
# ANALYSIS METHODOLOGY
|
|
|
|
Phase 1 - Repository Context Research:
|
|
- Identify existing security frameworks and libraries in use
|
|
- Look for established secure coding patterns in the codebase
|
|
- Examine existing sanitization and validation patterns
|
|
- Understand the project's security model and threat model
|
|
|
|
Phase 2 - Comparative Analysis:
|
|
- Compare new code changes against existing security patterns
|
|
- Identify deviations from established secure practices
|
|
- Look for inconsistent security implementations
|
|
- Flag code that introduces new attack surfaces
|
|
|
|
Phase 3 - Vulnerability Assessment:
|
|
- Examine each modified file under `src/` for security implications
|
|
- Trace data flow from user inputs to sensitive operations
|
|
- Look for privilege boundaries being crossed unsafely
|
|
- Identify injection points and unsafe deserialization
|
|
|
|
# REQUIRED OUTPUT FORMAT
|
|
|
|
You MUST post your findings as a single top-level PR comment using:
|
|
|
|
`gh pr comment ${{ env.PR_NUMBER }} --repo ${{ github.repository }} --body-file <file>`
|
|
|
|
The PR comment body MUST be readable GitHub-flavored Markdown.
|
|
|
|
Start with this exact heading:
|
|
|
|
`## Claude PR Security Review`
|
|
|
|
Then include this summary section first:
|
|
|
|
`### Analysis Summary`
|
|
|
|
- Files reviewed: <number>
|
|
- High severity findings: <number>
|
|
- Medium severity findings: <number>
|
|
- Low severity findings: <number>
|
|
- Review completed: true|false
|
|
|
|
Then include the findings section:
|
|
|
|
`### Findings`
|
|
|
|
If there are no findings, write exactly:
|
|
|
|
`No security findings identified.` Then STOP. Do not add anything else.
|
|
|
|
If there are findings, list each finding using this format:
|
|
|
|
`#### <severity>: <brief vulnerability title>`
|
|
|
|
- **Confidence:** <0.0-1.0>
|
|
- **File:** `<path/to/file>`
|
|
- **Line:** <line number>
|
|
- **Description:** <clear explanation of the vulnerability>
|
|
- **Attack scenario:** <how an attacker could trigger or exploit this issue>
|
|
- **Impact:** <concrete security impact>
|
|
- **Recommendation:** <specific remediation guidance>
|
|
- **Evidence:** <relevant code behavior or data flow supporting the finding>
|
|
|
|
Do not include raw JSON in the PR comment.
|
|
Do not include any text before the `## Claude PR Security Review` heading.
|
|
Do not include findings below 0.7 confidence.
|
|
|
|
# SEVERITY GUIDELINES
|
|
- **HIGH**: Directly exploitable vulnerabilities leading to RCE, data breach, or authentication bypass
|
|
- **MEDIUM**: Vulnerabilities requiring specific conditions but with significant impact
|
|
- **LOW**: Defense-in-depth issues or lower-impact vulnerabilities
|
|
|
|
# CONFIDENCE SCORING
|
|
- 0.9-1.0: Certain exploit path identified, tested if possible
|
|
- 0.8-0.9: Clear vulnerability pattern with known exploitation methods
|
|
- 0.7-0.8: Suspicious pattern requiring specific conditions to exploit
|
|
- Below 0.7: Don't report (too speculative)
|
|
|
|
When judging confidence, also take into account the signal quality criteria found in the `SIGNAL QUALITY CRITERIA` section of the `resources/specs/claude-false-positive-filtering.md` filtering file.
|
|
|
|
# FINAL REMINDER: Focus on HIGH and MEDIUM findings only.
|
|
|
|
Better to miss some theoretical issues than flood the report with false positives. Each finding should be something a security engineer would confidently raise in a PR review.
|
|
|
|
# IMPORTANT EXCLUSIONS - DO NOT REPORT:
|
|
|
|
Read the `HARD EXCLUSIONS` section found in the `resources/specs/claude-false-positive-filtering.md` filtering file, for each possbile vulnerability found, check if it matches any items from the patterns listed in that section and if that is the case, exclude that vulnerability from the report. DO NOT REPORT IT if a match is found. Also, take into account the project-specific filtering and reporting precedents found in the `PRECEDENTS` section of the filtering file.
|
|
|
|
Begin your analysis now. Use the repository exploration tools to understand the `src/` codebase context, then analyze only the PR changes under `src/` for security implications.
|
|
|
|
Your final action must be posting the PR comment. You should not reply again after posting the PR comment.
|