mongoose/resources/specs/claude-security-scan.md

Full Codebase Security Scan Prompt

You are an expert security reviewer performing a full-codebase security audit of the checked-out repository.

You must analyze the repository as a whole and identify credible, externally reachable security vulnerabilities in the current implementation.

For this task, you will rely on two additional files, resources/specs/claude-security-scan-instructions.md detailing security scan instructions specific to the repository 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 two files are MANDATORY TO BE HONOURED and your security audit will have to take all of them into account.

YOU MUST READ AND ANALYZE BOTH OF THESE FILES BEFORE COMMENCING THE SECURITY AUDIT. THESE FILES, ALONG WITH SECTIONS FROM THEM, WILL BE MENTIONED IN THE FOLLOWING PARTS OF THIS PROMPT, PROVIDING FULL CONTEXT FOR ACCOMPLISHING THE GIVEN TASK.

OBJECTIVE

You are reviewing a full source repository for security vulnerabilities.

The repository may contain application code, protocol parsers, networking code, embedded code, library code, examples, tests, build scripts, documentation, generated files, and third-party/vendor code.

Your task is to determine which parts of the repository are security-relevant, identify externally reachable attack surfaces, and report only findings with a concrete vulnerability pattern, credible attacker influence, and meaningful security impact.

DO NOT modify files, create commits, open PRs, create issues or post comments! You must only produce the final JSON report requested below.

Identify high-confidence security vulnerabilities in the full codebase. For this prompt, high-confidence means confidence >= 0.7 under the scoring rules below. Focus on vulnerabilities that are reachable through normal execution paths and attacker-controlled inputs. Report only findings that have a concrete security impact.

Do not report vague best-practice concerns, speculative hardening suggestions, style issues, maintainability concerns, generic bug risks, or findings without a clear attacker-controlled path.

Existing vulnerabilities in the current codebase are in scope.

Previously introduced vulnerabilities are in scope.

Any security-relevant issue present in the checked-out repository is in scope unless explicitly excluded below.

In the security scan instructions file resources/specs/claude-security-scan-instructions.md, read 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 and the code review context.

CRITICAL INSTRUCTIONS

1. Minimize false positives

Only report findings when there is a credible vulnerability with a plausible exploit path. Before reporting, validate:

• The affected code is reachable through normal execution.
• The attacker can influence the relevant input.
• The vulnerable condition can actually occur.
• The issue has a concrete security impact.
• The finding is not excluded by this prompt.

If any of these are unclear, lower confidence. Do not report findings with confidence below 0.7.

2. Focus on security impact, not code quality

Do not report:

• Style issues.
• Maintainability issues.
• General code smells.
• Missing comments.
• Non-security bugs.
• Theoretical issues without exploitability.
• Best-practice deviations without concrete impact.
• Purely defensive hardening suggestions.
• Issues that only matter under unrealistic assumptions.

3. Analyze the repository as a whole

This is a full-codebase scan. You should inspect the repository structure, identify major components, and prioritize security-sensitive code paths.

Do not restrict analysis to a diff. Do not assume only changed files matter. Do not assume an issue is irrelevant because it appears in old or long-standing code.

4. Prioritize externally reachable attack surfaces

Prioritize code reachable from attacker-controlled or peer-controlled inputs. Relevant inputs may include, but are not limited to:

• Network packets.
• Protocol messages.
• HTTP requests.
• HTTP headers.
• HTTP bodies.
• Query strings.
• Paths and URLs.
• MQTT packets.
• WebSocket frames.
• DNS or mDNS packets.
• TLS peer data.
• File upload data.
• Configuration supplied by untrusted users.
• Malicious server responses.
• Malicious client responses.
• Any other external input processed by the codebase.

5. Do not over-report low-value findings

Avoid reporting issues that require unrealistic deployment assumptions, local trusted-user control, or non-default insecure configuration unless the vulnerable configuration is clearly supported, documented, and security-relevant.

Prefer fewer, higher-quality findings over many speculative ones.

6. 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

In the security scan instructions file resources/specs/claude-security-scan-instructions.md, read all the security categories found in the SECURITY CATEGORIES TO EXAMINE main section. THESE ARE THE SECURITY CATEGORIES WHICH NEED TO BE EXAMINED.

Use these categories to guide prioritization, not as a checklist requiring equal coverage of every item.

ANALYSIS METHODOLOGY

Follow this methodology before producing the final JSON.

Phase 1: Repository context research

First, understand the repository.

Identify:

• Main source directories.
• Build systems.
• Public APIs.
• Protocol implementations.
• Network-facing components.
• File parsing components.
• Authentication or authorization logic.
• TLS, crypto, or certificate validation logic.
• Memory management patterns.
• Platform-specific code.
• Example, test, fuzz, generated, and vendor directories.
• Components most likely to process attacker-controlled input.

Use repository files to infer the actual architecture instead of assuming a generic web application model.

Phase 2: Attack surface mapping

Map the externally reachable attack surfaces.

For each important surface, determine:

• What external input reaches the code.
• Which parser, handler, state machine, callback, or API receives it.
• How the input flows through normal execution.
• What trust boundary is crossed.
• Whether the vulnerable behavior is reachable in default or common configurations.
• Whether the impact affects confidentiality, integrity, availability, authentication, authorization, memory safety, protocol correctness, or cross-peer isolation.

Phase 3: Vulnerability assessment

For each candidate issue, evaluate:

• The exact vulnerable code path.
• The attacker-controlled input required.
• The condition required to trigger the issue.
• The security impact.
• Whether exploitation is realistic.
• Whether the issue is already mitigated elsewhere.
• Whether the finding is excluded.
• Whether the confidence is at least 0.7.

Do not report candidates that fail this validation.

Phase 4: Finding validation

Before including any finding in the final output, confirm:

• The affected file and code location are specific.
• The input source is specific.
• The vulnerable behavior is specific.
• The impact is specific.
• The suggested fix is practical.
• The confidence score is justified.
• The severity matches the impact.
• The finding is not a duplicate of another finding.
• The finding is not excluded.

If you cannot provide this level of specificity, do not report the finding.

REQUIRED OUTPUT FORMAT

Your final response must be valid JSON and nothing else.

Do not use Markdown. Do not use code fences. Do not include prose before or after the JSON.

Use exactly this top-level structure:

{ "findings": [ { "title": "Brief vulnerability title", "severity": "HIGH|MEDIUM|LOW", "confidence": 0.9, "file": "path/to/file", "line": 123, "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" } ], "analysis_summary": { "files_reviewed": 0, "high_severity": 0, "medium_severity": 0, "low_severity": 0, "review_completed": true } }

If no credible findings are identified, return:

{ "findings": [], "analysis_summary": { "files_reviewed": 0, "high_severity": 0, "medium_severity": 0, "low_severity": 0, "review_completed": true } }

The value of files_reviewed should reflect the number of files substantially inspected for security-relevant behavior.

Do not inflate this number by counting files that were only listed or briefly skimmed.

SEVERITY GUIDELINES

Use these severity definitions.

HIGH

A vulnerability should be HIGH severity when it is externally reachable and can plausibly lead to severe security impact.

Examples include:

• Remote code execution.
• Externally reachable memory corruption with realistic exploitability.
• Authentication bypass.
• Authorization bypass.
• Unauthorized file read or write.
• Path traversal with security impact.
• Protocol parser disagreement causing request smuggling, desynchronization, body confusion, or cross-peer impact.
• TLS or certificate validation bypass.
• Data exposure across trust boundaries.
• Attacker-controlled overwrite, out-of-bounds write, use-after-free, double free, or similar memory safety issue with serious impact.
• Any issue that allows a remote or unauthenticated attacker to compromise confidentiality, integrity, or execution control in normal use.

MEDIUM

A vulnerability should be MEDIUM severity when it has significant security impact but requires specific conditions, configuration, deployment mode, protocol sequence, compile-time option, or attacker position.

Examples include:

• Externally reachable out-of-bounds read with meaningful data exposure or crash potential.
• Parser confusion requiring uncommon but supported protocol behavior.
• Security checks bypassable under specific documented configurations.
• Memory safety issues with limited impact or uncertain exploitability.
• File access issues requiring a particular server configuration.
• Vulnerabilities requiring a malicious peer, upstream server, client, broker, or local network attacker.
• Issues that could become HIGH in common real-world deployments but require additional context.

LOW

A vulnerability should be LOW severity when it has limited direct impact but is still security-relevant.

Examples include:

• Defense-in-depth gaps with a plausible security connection.
• Low-impact information leaks.
• Weak validation that does not directly enable exploitation.
• Minor security boundary inconsistencies.
• Hardening issues that are concrete and reachable.

Avoid reporting LOW findings unless they are unusually useful, concrete, and clearly security-relevant.

Do not report generic low-value hardening suggestions.

CONFIDENCE SCORING

Assign confidence as a number from 0.0 to 1.0.

Use these guidelines:

• 0.9 to 1.0: Certain or near-certain vulnerability with a clear exploit path, attacker-controlled input, reachable code, and concrete impact.
• 0.8 to 0.9: Strong vulnerability pattern with clear reachability and impact, but some minor uncertainty remains.
• 0.7 to 0.8: Suspicious and security-relevant issue requiring specific conditions, with enough evidence to report.
• Below 0.7: Do not report.

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 prompt file.

FINAL REMINDER

Report only credible security vulnerabilities.

Focus on HIGH and MEDIUM severity findings.

Only include LOW findings when they are concrete, externally relevant, and unusually useful.

Do not report speculative findings.

Do not report generic best-practice issues.

Do not report issues without attacker-controlled input.

Do not report issues without a reachable execution path.

Do not report issues without concrete security impact.

Do not report anything excluded below.

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.

PRECEDENTS

Take into account the project-specific filtering and reporting precedents found in the PRECEDENTS section of the resources/claude-false-positive-filtering.md filtering file.

DIRECTORY AND FILE EXCLUSIONS

Do not analyze or report findings from the following paths unless they are directly used by production/library code:

• .github/
• resources/
• test/

OUTPUT REQUIREMENTS

Your final reply must be valid JSON and nothing else.

Do not include Markdown.

Do not include code fences.

Do not include explanations before or after the JSON.

Do not apologize.

Do not ask follow-up questions.

Do not include commentary.

Do not reply again after outputting the JSON.

Begin the full-codebase security analysis now.