Claude: scan only src/ files

resources/specs/areas/common_misc.md

@@ -24,7 +24,7 @@ Primary files:
 
 Perform a focused security review centered on these files and this security surface.
 
-Supporting code outside these files may be inspected when necessary to establish reachability, data flow, state, validation, mitigation, or impact, but do not independently review unrelated areas.
+Supporting code elsewhere under `src/` may be inspected when necessary to establish reachability, data flow, state, validation, mitigation, or impact, but do not inspect or report code outside `src/` or independently review unrelated areas.
 
 ## Area-Specific Security Guidance
 

resources/specs/areas/mongoose_core.md

@@ -17,7 +17,7 @@ Primary files:
 
 Perform a focused security review centered on these files and this security surface.
 
-Supporting code outside these files may be inspected when necessary to establish reachability, data flow, state, validation, mitigation, or impact, but do not independently review unrelated areas.
+Supporting code elsewhere under `src/` may be inspected when necessary to establish reachability, data flow, state, validation, mitigation, or impact, but do not inspect or report code outside `src/` or independently review unrelated areas.
 
 ## Area-Specific Security Guidance
 

resources/specs/areas/net_builtin.md

@@ -12,7 +12,7 @@ Primary files:
 
 Perform a focused security review centered on these files and this security surface.
 
-Supporting code outside these files may be inspected when necessary to establish reachability, data flow, state, validation, mitigation, or impact, but do not independently review unrelated areas.
+Supporting code elsewhere under `src/` may be inspected when necessary to establish reachability, data flow, state, validation, mitigation, or impact, but do not inspect or report code outside `src/` or independently review unrelated areas.
 
 ## Area-Specific Security Guidance
 

resources/specs/areas/protocols.md

@@ -15,7 +15,7 @@ Primary files:
 
 Perform a focused security review centered on these files and this security surface.
 
-Supporting code outside these files may be inspected when necessary to establish reachability, data flow, state, validation, mitigation, or impact, but do not independently review unrelated areas.
+Supporting code elsewhere under `src/` may be inspected when necessary to establish reachability, data flow, state, validation, mitigation, or impact, but do not inspect or report code outside `src/` or independently review unrelated areas.
 
 ## Area-Specific Security Guidance
 
@@ -24,7 +24,7 @@ Supporting code outside these files may be inspected when necessary to establish
 - Look for malformed MQTT packets that can trigger out-of-bounds reads/writes, stack buffer overflow, heap corruption, assertion/crash, or parser desynchronization.
 - Specifically check SUBSCRIBE and UNSUBSCRIBE handling for unbounded numbers of topics, malformed topic length fields, missing QoS bytes, invalid QoS values, and writes to fixed-size response arrays.
 - Verify that PUBLISH handling enforces topic length, packet length, QoS rules, retained flag handling, packet identifier requirements, and message bounds before accessing fields.
-- Check broker examples and protocol handlers for authorization bypass, cross-topic data exposure, wildcard topic mishandling, `$SYS` or reserved topic confusion, and unintended publish/subscribe access.
+- Check protocol handlers for authorization bypass, cross-topic data exposure, wildcard topic mishandling, `$SYS` or reserved topic confusion, and unintended publish/subscribe access.
 - Review MQTT reconnect/resubscribe logic for stale connection state, packet identifier reuse bugs, and memory lifetime problems after close/reconnect.
 - Treat unauthenticated single-packet broker crash, client crash from malicious broker response, or memory corruption during MQTT parsing as reportable.
 

resources/specs/areas/tls.md

@@ -19,9 +19,9 @@ Primary files:
 
 Perform a focused security review centered on these files and this security surface.
 
-Supporting code outside these files may be inspected when necessary to establish reachability, data flow, state, validation, mitigation, or impact, but do not independently review unrelated areas.
+Supporting code elsewhere under `src/` may be inspected when necessary to establish reachability, data flow, state, validation, mitigation, or impact, but do not inspect or report code outside `src/` or independently review unrelated areas.
 
-Connection, core, network, and helper code may be inspected when needed to understand the complete TLS execution path.
+Connection, core, network, and helper code under `src/` may be inspected when needed to understand the complete TLS execution path.
 
 ## Area-Specific Security Guidance
 
@@ -33,7 +33,7 @@ Trace attacker-controlled TLS peer input through normal client and server execut
 
 **TLS, Certificate, Hostname Verification, and Cryptographic Validation:**
 - Review all TLS backends, including built-in TLS, mbedTLS, OpenSSL, WolfSSL, and custom TLS integration, for equivalent security behavior where possible.
-- Flag certificate verification bypasses, accidental `skip_verification` use in security-sensitive examples or defaults, missing hostname verification when `name`/SNI is available, or inconsistent validation across TLS backends.
+- Flag certificate verification bypasses, accidental `skip_verification` use in security-sensitive defaults, missing hostname verification when `name`/SNI is available, or inconsistent validation across TLS backends.
 - For hostname verification, check wildcard handling carefully. A wildcard certificate identity must not match multiple DNS labels. For example, `*.example.com` must not match `a.b.example.com`.
 - Verify that wildcard matching is applied only to certificate presented identifiers, not to arbitrary reference identifiers or general DNS glob matching.
 - Review `mg_match` or other glob/matching helpers if used for certificate identity checks, authorization checks, filesystem paths, routing, or topic matching. Flag cases where glob semantics are broader than the security policy requires.

resources/specs/areas/web_http_auth.md

@@ -16,9 +16,9 @@ Primary files:
 
 Perform a focused security review centered on these files and this security surface.
 
-Supporting code outside these files may be inspected when necessary to establish reachability, data flow, state, validation, mitigation, or impact, but do not independently review unrelated areas.
+Supporting code elsewhere under `src/` may be inspected when necessary to establish reachability, data flow, state, validation, mitigation, or impact, but do not inspect or report code outside `src/` or independently review unrelated areas.
 
-For OTA behavior, follow operations into TLS, flash, filesystem, JSON, URL, or other support code when necessary, while keeping the review centered on the `web_http_auth` surface.
+For OTA behavior, follow operations under `src/` into TLS, flash, filesystem, JSON, URL, or other support code when necessary, while keeping the review centered on the `web_http_auth` surface.
 
 ## Area-Specific Security Guidance
 
@@ -47,14 +47,13 @@ For OTA behavior, follow operations into TLS, flash, filesystem, JSON, URL, or o
 - Verify that range requests and static response headers cannot cause out-of-bounds reads or disclose memory.
 
 **OTA/Firmware Update and Device Dashboard Security:**
-- Review firmware update endpoints and examples for missing authentication, authorization bypass, path confusion, arbitrary write, unsafe flash offset/length handling, and failure to verify firmware authenticity where the code claims secure update behavior.
+- Review firmware update endpoints and code paths for missing authentication, authorization bypass, path confusion, arbitrary write, unsafe flash offset/length handling, and failure to verify firmware authenticity where the code claims secure update behavior.
 - Check update chunk parsing for integer overflow, flash boundary crossing, rollback/downgrade exposure, incomplete image bootability, and crash/power-loss unsafe state transitions.
 - Flag any code path where unauthenticated network input can write firmware, configuration, filesystem contents, flash pages, bootloader state, or device identity material.
-- Review device dashboard examples for security-sensitive default routes, credentials, upload handlers, debug endpoints, config mutation endpoints, and CORS/header behavior when they are likely to be copied into production.
-- Do not report ordinary insecure demo behavior unless it creates a realistic copy-paste production vulnerability or affects library code.
+- Review device dashboard code for security-sensitive default routes, credentials, upload handlers, debug endpoints, config mutation endpoints, and CORS/header behavior.
 
 **Authentication, Authorization, and Access-Control Patterns in Mongoose Integrations:**
-- Review examples and helper APIs that implement HTTP auth, cookies, sessions, tokens, device dashboards, REST APIs, upload endpoints, and firmware update endpoints.
+- Review helper APIs and code paths that implement HTTP auth, cookies, sessions, tokens, device dashboards, REST APIs, upload endpoints, and firmware update endpoints.
 - Flag authentication bypasses caused by prefix route matching, glob matching, decoded-vs-raw URI confusion, case normalization mistakes, missing boundary checks, or default-open sensitive endpoints.
 - Check for authorization decisions made in client-side JavaScript only. Client-side checks are not security boundaries.
 - Review CORS and origin checks only when they protect credentialed sensitive operations and the exploit path is concrete.

resources/specs/claude-false-positive-filtering.md

@@ -5,7 +5,7 @@
 3. The exploit depends on NULL, dangling, fake, or corrupted pointers/objects supplied by a local caller, including invalid `mg_connection`, `mg_mgr`, `mg_str`, iobufs, or callback data.
 4. The exploit requires manually mutating internal structs, flags, parser offsets, descriptor indexes, connection state, TLS state, MQTT/WebSocket state, or filesystem state into impossible combinations.
 5. The bug exists only in tests, fuzz harnesses, benchmarks, synthetic unit tests, or debug-only code, with no shared production logic.
-6. The issue is only in a tutorial/demo/example with no realistic production relevance or sensitive operation.
+6. The affected file is outside `src/`.
 7. The attacker must edit source code, build flags, compile-time macros, TLS backend choices, filesystem roots, or local device configuration.
 8. The attacker must directly write hardware registers, MMIO, DMA descriptors, descriptor ownership bits, IRQ state, cache registers, or peripheral configuration.
 9. Generic DoS from high traffic volume, many valid connections, slow clients, missing quotas, missing rate limits, or ordinary resource saturation.
@@ -27,7 +27,7 @@
 6. Does the report provide exact files, functions, line numbers, data flow, bounds reasoning, state reasoning, or a minimal malformed input?
 7. Is the malformed input shape clear, such as CL+TE HTTP, oversized MQTT SUBSCRIBE, malformed WebSocket length, DNS compression loop, wildcard TLS certificate, invalid packet header length, or encoded path traversal?
 8. Is the severity justified by reachability and impact?
-9. Is this a library/helper/default/example-pattern vulnerability rather than only arbitrary application misuse?
+9. Is this a library/helper/default vulnerability rather than only arbitrary application misuse?
 10. Is the fix specific enough to act on: reject CL+TE, bound arrays, validate DNS pointers, enforce one-label wildcard matching, check packet lengths, canonicalize paths, or bound RX loops?
 11. Is a DoS finding caused by a concrete implementation flaw rather than volume, slow clients, missing quotas, or capacity limits?
 12. In embedded context, can a small malformed input reliably crash, wedge, corrupt, or permanently disrupt a device/process?
@@ -53,11 +53,11 @@
 17. Filter reports requiring direct mutation of connection internals such as protocol flags, closing flags, handler pointers, iobuf fields, callback pointers, or user data.
 18. Filter reports requiring attacker control of `MG_ENABLE_*`, TLS backend macros, filesystem backend macros, compiler flags, debug flags, sanitizer settings, or platform defines.
 19. Filter direct hardware-access reports requiring writes to registers, DMA descriptors, MMIO, IRQ state, cache controls, or peripheral configuration.
-20. Filter generic “Mongoose lacks authentication” reports unless a helper, example, route pattern, auth parser, MQTT broker behavior, dashboard, upload handler, or OTA endpoint creates a concrete issue.
+20. Filter generic “Mongoose lacks authentication” reports unless a helper, route pattern, auth parser, MQTT broker behavior, dashboard, upload handler, or OTA endpoint creates a concrete issue.
 21. Filter generic rate-limit/quota/connection-cap/upload-cap findings unless a specific bug lets a small malformed input trigger crash, corruption, infinite loop, or disproportionate exhaustion.
 22. Filter purely theoretical UB, portability, unaligned-access, or signed-overflow reports with no supported-platform impact and no realistic external trigger.
 23. Filter RFC non-compliance without concrete smuggling, bypass, memory corruption, data exposure, state corruption, or crash.
-24. Keep security-relevant production-like examples: dashboards, upload servers, MQTT brokers, firmware update flows, auth examples, TLS examples, and filesystem-serving examples.
+24. Keep security-relevant production library code under `src/` for dashboards, uploads, MQTT, firmware updates, authentication, TLS, and filesystem serving.
 25. Keep client-side findings caused by malicious servers, brokers, DNS responders, TLS peers, WebSocket peers, or HTTP peers.
 26. Keep callback-related findings only when Mongoose invokes the callback normally and then unsafely continues using freed or mutated state.
 27. Keep availability findings when one malformed packet, request, certificate, DNS response, MQTT message, WebSocket frame, or small sequence can reliably crash, wedge, corrupt, or disrupt a Mongoose target.
@@ -66,4 +66,4 @@
 30. For dashboard reports, do not infer unauthenticated access from a route-specific check alone; account for the broader authentication flow. Keep concrete reachable bugs such as path traversal, unsafe decoded paths, or file read/write/delete issues.
 31. Filter reports regarding DNS transaction ID predictability or lack of strict question-name matching in DNS response processing, as these are acknowledged design limitations of the current implementation.
 32. Filter reports that unauthenticated SNTP time affects TLS certificate validity when Mongoose only performs the SNTP sync if mg_boot_timestamp_ms has not already been initialized.
-33. Filter TCP ISN predictability, weak sequence-number generation, RFC 6528 non-compliance, blind/off-path handshake spoofing, forged RST, and sequence-number-guessing reports in the built-in TCP/IP stack.
+33. Filter TCP ISN predictability, weak sequence-number generation, RFC 6528 non-compliance, blind/off-path handshake spoofing, forged RST, and sequence-number-guessing reports in the built-in TCP/IP stack.

resources/specs/claude-pr-security-review.md

@@ -1,10 +1,10 @@
-Review the complete PR diff. This contains all code changes in the PR.
+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. Do not comment on existing security concerns.
+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.
 
@@ -29,7 +29,7 @@ Also read the `Area-Specific Security Guidance` section from every area prompt:
 * `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 regardless of which source files the PR modifies. Do not choose one area or make this PR review area-scoped. Review the PR diff and report only security vulnerabilities introduced by that PR.
+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.
 
@@ -48,7 +48,7 @@ Phase 2 - Comparative Analysis:
 - Flag code that introduces new attack surfaces
 
 Phase 3 - Vulnerability Assessment:
-- Examine each modified file for security implications
+- 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
@@ -121,6 +121,6 @@ Better to miss some theoretical issues than flood the report with false positive
 
 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 codebase context, then analyze the PR changes for security implications.
+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.

resources/specs/claude-security-scan.md

@@ -18,11 +18,13 @@ YOU MUST READ AND ANALYZE THE ASSIGNED AREA PROMPT AND THE COMMON FILTERING PROM
 
 You are reviewing one assigned security area in a 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.
+The `src/` directory contains the protocol parsers, networking code, embedded code, library code, generated code, and platform-specific code in scope for this review.
 
 The area-specific prompt defines the primary files and security surface for this invocation. Your task is to identify externally reachable attack surfaces within that assigned area and report only findings with a concrete vulnerability pattern, credible attacker influence, and meaningful security impact.
 
-You may inspect code outside the listed target files when that code is necessary to understand data flow, reachability, call chains, state transitions, memory ownership, mitigations, authentication or authorization, protocol interaction, exploitability, or impact. Inspecting supporting code must not turn into an independent security review of unrelated areas. Findings must remain tied to the assigned target and security surface.
+The security review target is limited to code under `src/`. Do not analyze, count, or report code outside `src/` as part of the security review.
+
+You may inspect code outside the listed target files only when it is also under `src/` and is necessary to understand data flow, reachability, call chains, state transitions, memory ownership, mitigations, authentication or authorization, protocol interaction, exploitability, or impact. Inspecting supporting code must not turn into an independent security review of unrelated areas. Findings must remain tied to the assigned target and security surface and must identify an affected file under `src/`.
 
 DO NOT modify files, create commits, open PRs, create issues or post comments! You must only produce the final JSON report requested below.
 
@@ -83,7 +85,7 @@ Do not report:
 
 ### 3. Analyze the assigned scan area
 
-This is a targeted scan centered on the primary files and security surface defined by the assigned area prompt. Follow relevant supporting code when necessary to establish reachability, data flow, state, validation, mitigation, exploitability, or impact, but do not independently review unrelated areas.
+This is a targeted scan centered on the primary files and security surface defined by the assigned area prompt. Follow relevant supporting code under `src/` when necessary to establish reachability, data flow, state, validation, mitigation, exploitability, or impact, but do not inspect code outside `src/` as part of the security review or independently review unrelated areas.
 
 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.
 
@@ -149,13 +151,12 @@ Follow this methodology before producing the final JSON.
 
 ### Phase 1: Repository context research
 
-First, understand the assigned area in repository context.
+First, understand the assigned area within `src/`.
 
 Identify:
 
-* Main source directories.
-* Build systems.
-* Public APIs.
+* Relevant directories under `src/`.
+* Public APIs declared under `src/`.
 * Protocol implementations.
 * Network-facing components.
 * File parsing components.
@@ -163,10 +164,9 @@ Identify:
 * TLS, crypto, or certificate validation logic.
 * Memory management patterns.
 * Platform-specific code.
-* Example, test, fuzz, generated, and vendor directories.
 * Components in the assigned area most likely to process attacker-controlled input.
 
-Use repository files to infer the actual architecture instead of assuming a generic web application model.
+Use files under `src/` to infer the actual architecture instead of assuming a generic web application model.
 
 ### Phase 2: Attack surface mapping
 
@@ -359,10 +359,9 @@ Take into account the project-specific filtering and reporting precedents found
 
 ## 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/
+Only analyze and report findings from files under `src/`.
+
+Do not analyze or count code outside `src/` as part of the security review.
 
 ## OUTPUT REQUIREMENTS