Skip to content

WIP (experiment DO NOT MERGE) Add WLED secure coding AI review instruction guides#5572

Draft
Copilot wants to merge 11 commits intomainfrom
copilot/create-ai-review-guide-wled
Draft

WIP (experiment DO NOT MERGE) Add WLED secure coding AI review instruction guides#5572
Copilot wants to merge 11 commits intomainfrom
copilot/create-ai-review-guide-wled

Conversation

Copy link
Copy Markdown
Contributor

Copilot AI commented May 6, 2026

this PR is an experiment for creating a security-aware review checklist (for coderabbit PR reviews) that should be relevant for WLED.
The list is based on the OWASP "top 10" from https://github.com/github/awesome-copilot/blob/main/instructions/security-and-owasp.instructions.md

DO NOT MERGE yet!!


This PR now includes:

  • corrected docs filename spelling to match existing docs/*.instructions.md naming pattern:
    • docs/securecode.instructions.md
    • docs/secure-short.instructions.md
  • follow-up adjustments to both guides based on review feedback, including:
    • explicit WLED threat-model assumptions (typical firewall/DMZ/VPN deployment)
    • removal of any mandatory TLS/HTTPS baseline expectation
    • clarification that protocol-defined unauthenticated UDP multicast/broadcast paths should not be flagged solely for lacking auth
    • OTA integrity guidance framed as checksum/hash/signature verification without requiring TLS
    • wording consistency and clarity improvements across both files
  • additional verification against the suggested rule set from issuecomment-4393037994, with missing coverage added to docs/securecode.instructions.md, including concrete pattern guidance for:
    • UDP packet bounds and protocol range clamping
    • explicit JSON parse-error handling patterns
    • OTA integrity checks in Update.* paths
    • FreeRTOS stack/recursion safety checks
    • mDNS/hostname sanitization constraints
    • outbound URL validation (without HTTPS requirement)
    • optional unicast UDP source filtering (advisory)
    • CSRF Origin/Referer advisory checks for non-internet-exposed deployments
    • credential exposure checks in API/config serialization
    • security-event logging coverage
    • workflow action pinning and permission hardening specifics

Summary by CodeRabbit

  • Documentation
    • Added security review guidelines and a 24-rule checklist covering critical security areas including buffer safety, input validation, authentication, secure defaults, and protection against common vulnerabilities.
    • Refined rule wording and priorities to better fit WLED’s technical constraints and realistic deployment model.

Summary by CodeRabbit

  • Documentation
    • Added comprehensive security review standards for embedded firmware and web UI components, covering vulnerability assessment and compliance criteria.
    • Added hardening checklist to guide code review processes with structured rules and severity levels.

Agent-Logs-Url: https://github.com/wled/WLED/sessions/82b5d757-7791-4aa3-8f77-96b25e52b6d5

Co-authored-by: softhack007 <91616163+softhack007@users.noreply.github.com>
Agent-Logs-Url: https://github.com/wled/WLED/sessions/dc60e89a-6f5e-4441-8b4d-a70d61c1bf5c

Co-authored-by: softhack007 <91616163+softhack007@users.noreply.github.com>
@softhack007 softhack007 changed the title Add WLED secure coding AI review instruction guides WIP (experiment DO NOT MERGE) Add WLED secure coding AI review instruction guides May 6, 2026
@softhack007

This comment was marked as outdated.

@coderabbitai

This comment was marked as outdated.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 6, 2026

Important

Review skipped

Ignore keyword(s) in the title.

⛔ Ignored keywords (1)
  • WIP

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 01f01b05-52e6-40e9-8dd0-6b69b95b5b0c

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • ✅ Review completed - (🔄 Check again to review again)

Walkthrough

Adds two WLED-focused security review instruction documents: a concise strict-mode checklist (docs/secure-short.instructions.md) and a comprehensive AI-assisted guide (docs/securecode.instructions.md) that define file targets, threat-model assumptions, rule sets for firmware/web UI, secrets/supply-chain checks, and reviewer output requirements.

Changes

WLED security instruction documents

Layer / File(s) Summary
Targeting / Metadata
docs/secure-short.instructions.md, docs/securecode.instructions.md
Both files add YAML front-matter with applyTo globs and descriptive metadata to scope the review to relevant source/config files.
Concise checklist content
docs/secure-short.instructions.md
Introduces a 26-rule "WLED strict-mode security review" checklist organized as CRITICAL (1–12) and IMPORTANT (13–26), covering memory safety, logging/format strings, input validation, auth for state changes, fail-closed parsing, XSS/dynamic-code prohibitions, secret handling (logs/workflows/LittleFS), GitHub Actions pinning/permissions/shell safety, and additional robustness/validation requirements.
Comprehensive guidance content
docs/securecode.instructions.md
Adds a full WLED-focused review framework: scope/threat-model assumptions, severity taxonomy, firmware checklist (FW1–FW14) including buffer/overflow/auth/OTA/stack/hostname checks, web UI checklist (WEB1–WEB7) covering DOM XSS, dynamic execution, postMessage/redirect validation, server-side validation guidance, secrets/logging standards (SEC1–SEC6), and supply-chain/CI checks (SC1–SC3).
Reviewer output & AI behavior
docs/secure-short.instructions.md, docs/securecode.instructions.md
Defines reviewer output formatting: map findings strictly to enumerated rules, include severity + exact file/line + concrete fix direction, prioritize higher severities; securecode adds AI reviewer behavior and prioritization guidance.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

  • wled/WLED#5480: Related — intersects with .coderabbit.yaml and instructions-rework that introduce path-scoped rules and alignment checks for *.instructions.md files.

Suggested reviewers

  • DedeHai
  • netmindz
  • willmmiles
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately describes the main change: adding WLED secure coding AI review instruction guides. The 'WIP (experiment DO NOT MERGE)' prefix clearly signals the PR's intent.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

  • Generate code and open pull requests
  • Plan features and break down work
  • Investigate incidents and troubleshoot customer tickets together
  • Automate recurring tasks and respond to alerts with triggers
  • Summarize progress and report instantly

Built for teams:

  • Shared memory across your entire org—no repeating context
  • Per-thread sandboxes to safely plan and execute work
  • Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@coderabbitai coderabbitai Bot added enhancement discussion AI Partly generated by an AI. Make sure that the contributor fully understands the code! labels May 6, 2026
coderabbitai[bot]

This comment was marked as resolved.

Comment thread docs/securecode.instructions.md Outdated
@softhack007
Copy link
Copy Markdown
Member

@coderabbitai please look for similar secure coding guidelines/checklists in github projects that have similarities with the WLED architecture and build tooling. Additionally, look up the original OWASP "top 10".

  • suggest additional rules or modifications in case this PR has important security risks uncovered.
  • verify that rules from this PR are clear and relevant for future coderabbit PR reviews (WLED context), and suggest improvements.
  • create a prioritized list to summarize your finding and suggestions.

@coderabbitai

This comment was marked as outdated.

@softhack007
Copy link
Copy Markdown
Member

@coderabbitai some expectations stated in #5572 (comment) are technically over-the-top (currently unfeasible due to very limited flash space). Also you can assume that WLED will be operated behind a firewall (DMZ style, wireguard, or VPN), which reduces some risks that system exposed to the "open internet" have to deal with. Technical constraints include:

  • TLS/HTTPS is not used due to unknown performance impact, and flash size increase
  • authentication of UDP connections is not feasible atm, especially for multicast/broadcast channels
  • if protocol standards do not foresee authentication, WLED cannot break out of the specs just to add that

Please revise your proposal accordingly.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 6, 2026

Tip

For best results, initiate chat on the files or code changes.

@softhack007, understood — those are important practical constraints. Here is the revised proposal, with rules adjusted to reflect WLED's flash budget, no-TLS baseline, protocol-compliance requirements, and the assumed firewall boundary.


Revised Prioritized Rule Proposal

Changes from previous version (summary)

Rule Previous Revised Reason
OTA firmware integrity 🔴 P1 (TLS + hash) 🟠 P2 (hash only) TLS not feasible; hash check alone has value but firewall reduces blast radius
SSRF / outbound URL injection 🔴 P1 (HTTPS + allowlist) 🟡 P3 (allowlist only) Firewall mitigates; HTTPS not feasible; allowlist still prevents misconfiguration abuse on LAN
Credential storage & API exposure 🔴 P1 (NVS encrypt + API) 🟠 P2 (API exposure only) NVS encryption impractical; passwords in unauthenticated API responses still a real LAN risk
Default/hardcoded credentials 🔴 P1 🔴 P1 (unchanged) Firewall doesn't protect against LAN-local attackers with default creds
UDP input bounds checking 🟠 P2 (auth + bounds) 🟠 P2 (bounds only) Auth not feasible per specs; bounds/length checking is purely a memory-safety concern, no protocol change needed
UDP source IP allowlist 🟠 P2 🟡 P3 (optional/configurable) Multicast/broadcast precludes strict allowlist; a user-configurable option is reasonable but not a hard rule
CSRF via Origin header 🟠 P2 🟡 P3 Firewall reduces risk; Origin header check remains cheap and advisable but not critical
FreeRTOS stack overflows 🟠 P2 🟠 P2 (unchanged) Firmware-internal, unrelated to TLS/network
mDNS/hostname injection 🟠 P2 🟠 P2 (unchanged) LAN-local injection is still a valid threat behind firewall
Fail-closed parsing 🟡 P3 🟡 P3 (unchanged) Purely firmware-internal
Allocation churn 🟡 P3 🟡 P3 (unchanged) Purely firmware-internal
Security event logging 🟡 P3 🟡 P3 (unchanged) Useful for local incident forensics
GHA SHA pinning 🟡 P3 🟡 P3 (unchanged) CI/supply chain, unrelated to device constraints

🔴 P1 — CRITICAL (revised)

1. Default / Hardcoded Credentials [A07/A05]
A device behind a firewall is still exposed to LAN-local attackers and compromised hosts on the same segment. Default/known credentials are the first thing exploited in lateral movement.

Rule: Flag const char* or String literals that appear to be hardcoded passwords or PSKs in source (not loaded from config). Flag absence of a "change default password" prompt or enforcement on first boot.


🟠 P2 — IMPORTANT (revised)

2. OTA Firmware Integrity [A08] — hash-only, no TLS requirement
Even behind a firewall, a LAN-local attacker or a compromised update source can push a malicious firmware binary. A lightweight CRC/SHA hash check on the incoming image is feasible without TLS.

Rule: Flag OTA update paths (Update.begin(), Update.write()) where the incoming firmware binary is flashed without verifying a checksum or hash against a known-good value. Do not require TLS/HTTPS (not feasible). Do not require certificate pinning.

3. Credential/Password Exposure via API Responses [A02]
Sending Wi-Fi PSK, AP password, or MQTT credentials in a JSON API response readable by unauthenticated LAN clients remains a real risk regardless of firewall.

Rule: Flag any API endpoint or config serialization path that includes wifiPass, apPass, mqttPass, or equivalent credential fields in JSON responses sent to clients that have not been authenticated. Flag serial/debug output that logs these values.

4. UDP Input Length/Bounds Checking [A03] — no auth requirement
Authentication of E1.31, DDP, Art-Net, and TPM2.net UDP streams is not feasible and not required by specs. However, bounds checking on received byte lengths before writing to LED/pixel buffers is purely a memory-safety concern and imposes no protocol changes.

Rule: Flag any parsePacket() / recvfrom() handler that writes received bytes to a pixel or LED buffer without first validating that packetSize does not exceed the allocated buffer length. Flag missing max-universe and max-channel bounds enforcement for E1.31 and Art-Net within spec limits — not to reject valid traffic, but to clamp it.

5. FreeRTOS Task Stack Overflows [A03 / embedded]
Firmware-internal, unaffected by network constraints.

Rule (unchanged): Flag xTaskCreate / xTaskCreatePinnedToCore calls with stack sizes below 4096 bytes for tasks that perform String/JSON operations. Flag recursive functions called from task context without documented stack depth analysis.

6. mDNS / Hostname Injection [A03]
User-controlled hostname fed into MDNS.begin() without sanitization is a LAN-local injection risk.

Rule (unchanged): Flag MDNS.begin(), MDNS.addService(), or ArduinoOTA.setHostname() calls where the hostname is taken from user config without restricting to [a-zA-Z0-9-] and clamping to 63 chars per RFC 1123.


🟡 P3 — SUGGESTIONS (revised)

7. Outbound URL Validation (SSRF / misconfiguration) [A10] — no HTTPS requirement
SSRF risk is substantially reduced behind a firewall. However, user-supplied URLs driving HTTPClient.begin() (webhooks, Hue bridge, sync targets) without any scheme/host validation can still enable misconfiguration abuse on the local network. No HTTPS requirement.

Rule: Flag HTTPClient.begin(userSuppliedString) or equivalent where the URL string originates from JSON config/user input without scheme (http://) validation and host allowlist or format check. Drop any HTTPS enforcement requirement.

8. CSRF via Origin Header [A01/A04]
Risk is reduced behind firewall. Origin header checking is inexpensive and recommended but not critical.

Rule (downgraded): Flag state-changing HTTP handlers (/json/state, /win, etc.) that accept requests with no Origin or Referer header check. Treat as advisory only for devices confirmed to be firewall-isolated.

9. Configurable UDP Source Filter (optional, not mandatory) [A01]
Full allowlist is not feasible for multicast/broadcast. A user-configurable source IP filter (when unicast is in use) is a reasonable optional hardening.

Rule (advisory only): Flag unicast-only UDP receive paths that have no mechanism for the user to restrict accepted source IPs. Do not flag multicast/broadcast paths. Note this as a hardening option, not a defect.

10–12. Existing rules — Clarifications (unchanged in priority)

  • Fail-closed parsing: Concretize to deserializeJson() return-value checks and silent zero-defaults for safety-relevant fields (LED count, pin assignment).
  • Allocation churn: Add String concatenation in loop bodies and ISR-adjacent code as explicit flag targets.
  • Security event logging: Flag auth failures, OTA attempts, config resets, AP activation with no DEBUG_PRINT at WARN level.
  • GHA SHA pinning: Flag mutable version tags (@v3) vs. full commit SHAs; flag permissions: write-all.

Final Revised Priority Table

Priority Rule OWASP Notes
🔴 P1 Hardcoded/default credential detection A07/A05 LAN-local risk even behind firewall
🟠 P2 OTA hash/checksum verification (no TLS) A08 Feasible without TLS
🟠 P2 Password/credential exposure in API responses A02 LAN risk
🟠 P2 UDP input bounds/length checking (no auth) A03 Memory safety only, no protocol change
🟠 P2 FreeRTOS stack overflow detection A03 Firmware-internal
🟠 P2 mDNS/hostname injection sanitization A03 LAN-local
🟡 P3 Outbound URL scheme/host check (no HTTPS) A10 Misconfiguration only
🟡 P3 CSRF Origin header check (advisory) A01 Downgraded; firewall mitigates
🟡 P3 Configurable UDP source filter (optional) A01 Advisory/hardening only
🟡 P3 Fail-closed parsing (WLED-specific) A04 Needs concretization
🟡 P3 Allocation churn in loops/ISR context Embedded Needs concretization
🟡 P3 Security event logging A09 Local forensics
🟡 P3 GHA SHA pinning A08 CI/supply chain

The three rules that were 🔴 P1 in the previous proposal — SSRF with HTTPS, OTA with TLS, and UDP authentication — have been either downgraded or stripped of the infeasible requirements, keeping only the parts that are actionable within WLED's flash and protocol constraints.

@softhack007
Copy link
Copy Markdown
Member

@copilot please adjust this PR according to suggestions made in #5572 (comment)

Copilot AI and others added 2 commits May 7, 2026 00:05
Agent-Logs-Url: https://github.com/wled/WLED/sessions/73d38e00-6610-47e7-a7de-4a926fe0cc68

Co-authored-by: softhack007 <91616163+softhack007@users.noreply.github.com>
Agent-Logs-Url: https://github.com/wled/WLED/sessions/73d38e00-6610-47e7-a7de-4a926fe0cc68

Co-authored-by: softhack007 <91616163+softhack007@users.noreply.github.com>
Copy link
Copy Markdown
Contributor Author

Copilot AI commented May 7, 2026

@copilot please adjust this PR according to suggestions made in #5572 (comment)

Updated as requested in commit 9351b1b (plus core revision in 466cff6). The docs now reflect the feasibility constraints from issuecomment-4393037994: explicit firewall-based assumptions, no mandatory TLS baseline, no mandatory auth for protocol-defined unauthenticated UDP multicast/broadcast paths, and OTA integrity guidance without TLS requirement.

Copilot AI requested a review from softhack007 May 7, 2026 00:06
@softhack007
Copy link
Copy Markdown
Member

@copilot #5572 (comment) also suggests new rules and concrete patterns to be checked. Please verify each suggested rule for coverage in the existing instructions (docs/securecode.instructions.md) and add rules when they are not covered yet.

Copilot AI and others added 3 commits May 7, 2026 00:13
Copy link
Copy Markdown
Contributor Author

Copilot AI commented May 7, 2026

@copilot #5572 (comment) also suggests new rules and concrete patterns to be checked. Please verify each suggested rule for coverage in the existing inst...

Done in 5abba3e (with added coverage introduced in eb68806). I verified the suggested rules from issuecomment-4393037994 against docs/securecode.instructions.md and added missing coverage/concrete patterns, including: UDP bounds/clamps, explicit JSON parse error handling, OTA integrity checks in Update flows, FreeRTOS stack/recursion guidance, hostname sanitization, outbound URL validation, optional unicast UDP source filtering, CSRF advisory checks, credential exposure in API/config responses, security-event logging coverage, and workflow pinning/permission specifics.

@softhack007

This comment was marked as resolved.

@coderabbitai

This comment was marked as resolved.

@softhack007

This comment was marked as outdated.

@coderabbitai

This comment was marked as outdated.

aligns with coderabbit suggestions
Clarified security review instructions and enhanced severity descriptions for hardcoded secrets and credential exposure.
@softhack007

This comment was marked as outdated.

@coderabbitai

This comment was marked as outdated.

@softhack007

This comment was marked as outdated.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 7, 2026

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
echo "=== docs/securecode.instructions.md ==="
cat docs/securecode.instructions.md

echo ""
echo "=== docs/secure-short.instructions.md ==="
cat docs/secure-short.instructions.md

Length of output: 12858


@softhack007, here is the repeated verification against the current file state:


✅ All 13 Revised Rules — Now Fully Integrated

Priority Rule securecode.instructions.md secure-short.instructions.md Status
🔴 P1 Hardcoded/default credentials SEC1 + SEC3 R8 + R23
🟠 P2 OTA hash verification (no TLS) FW10 R24
🟠 P2 Credential exposure in API responses SEC5 R26
🟠 P2 UDP input bounds (no auth) FW4 R3
🟠 P2 FreeRTOS stack overflow FW11 R25
🟠 P2 mDNS/hostname injection FW12 R25
🟡 P3 Outbound URL validation (no HTTPS) FW13 (SUGGESTION)
🟡 P3 CSRF Origin check (advisory) WEB7 (SUGGESTION)
🟡 P3 UDP source filter (optional) FW14 (SUGGESTION)
🟡 P3 Fail-closed parsing (WLED-specific) FW6 R5
🟡 P3 Allocation churn (loop/ISR-specific) FW7 + FW8 R14 + R15
🟡 P3 Security event logging SEC6
🟡 P3 GHA SHA pinning SC2 R11

Previously Flagged Gaps — Both Now Resolved

Gap Previous Status Current Status
FW11 (FreeRTOS), FW12 (mDNS), SEC5 (credential exposure) absent from short checklist ⚠️ Missing ✅ Added as Rules 25 & 26
Absolute runner paths (/home/runner/work/WLED/WLED/…) in Scope section 🐛 Bug ✅ Fixed to repo-relative (wled00/, usermods/, .github/workflows/)

One Remaining Minor Nit

secure-short.instructions.md, Rule 10 — double-backtick formatting around wsec.json:

# current (renders oddly in some Markdown viewers)
or in LittleFS files other than ``wsec.json``

# should be
or in LittleFS files other than `wsec.json`

This is cosmetic only and has no effect on review behavior.


Summary: The integration is complete. All 13 rules from the revised proposal are present and correctly scoped in both files. The short checklist has been correctly extended to 26 rules with the header description updated to match. No substantive gaps remain.

coderabbitai[bot]

This comment was marked as outdated.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
docs/secure-short.instructions.md (1)

31-46: 💤 Low value

IMPORTANT rules are sound; consider splitting rule 25 for clarity.

The 14 IMPORTANT rules provide good coverage of secondary security concerns. Rule 24 correctly requires OTA integrity without TLS (matching constraints).

Optional refinement: Rule 25 (line 45) combines two distinct embedded concerns: FreeRTOS stack safety and mDNS/hostname sanitization. If the 26-rule compact format is later relaxed, splitting this into two rules would improve clarity and specificity.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/secure-short.instructions.md` around lines 31 - 46, Split the combined
Rule 25 into two separate rules for clarity: one rule that flags xTaskCreate and
xTaskCreatePinnedToCore calls that allocate insufficient stack for use of
String/JSON (explicitly mention checking stack size against worst-case
String/JSON usage), and a second rule that flags MDNS.begin() and
ArduinoOTA.setHostname() calls with unsanitized hostnames (explicitly require
hostname validation/sanitization and allowed-character checks); update
references in the list so the new rules replace the single Rule 25 entry and
keep numbering consistent.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@docs/secure-short.instructions.md`:
- Around line 31-46: Split the combined Rule 25 into two separate rules for
clarity: one rule that flags xTaskCreate and xTaskCreatePinnedToCore calls that
allocate insufficient stack for use of String/JSON (explicitly mention checking
stack size against worst-case String/JSON usage), and a second rule that flags
MDNS.begin() and ArduinoOTA.setHostname() calls with unsanitized hostnames
(explicitly require hostname validation/sanitization and allowed-character
checks); update references in the list so the new rules replace the single Rule
25 entry and keep numbering consistent.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 83d69bdb-b4d9-4ec2-b333-37539ff5905b

📥 Commits

Reviewing files that changed from the base of the PR and between 2fd1c1e and 4363121.

📒 Files selected for processing (1)
  • docs/secure-short.instructions.md

- OTA update flows should validate firmware integrity using the checksum/hash/signature mechanism available in the firmware/platform implementation.
- Do not require TLS/certificate pinning as a mandatory review criterion.
- In OTA paths (`Update.begin()`, `Update.write()`, and related flows), flag flashing without integrity verification.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@willmmiles do you think this point is feasible?
(most of the PR is wishful thinking any way 🎅 )

### FW11: FreeRTOS task stack and recursion safety
- **Severity**: IMPORTANT
- In `xTaskCreate`/`xTaskCreatePinnedToCore` tasks that process `String`/JSON-heavy data, verify stack-size sufficiency and avoid unbounded recursion.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

possible addition:

  • check that functions do not store "large data" (>2kB) on stack.
  • verify that recursions are bounded

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (3)
docs/securecode.instructions.md (1)

179-179: 💤 Low value

Minor: Correct GitHub capitalization.

The official platform name is "GitHub" (capital H).

Suggested fix
-- Avoid direct interpolation of untrusted `${{ github.event.* }}` values in `run` commands.
+- Avoid direct interpolation of untrusted `${{ GitHub.event.* }}` values in `run` commands.

Note: If the intent is to reference the literal GitHub Actions expression syntax github.event.*, the lowercase form is technically correct for the expression context itself. In that case, you could clarify:

-- Avoid direct interpolation of untrusted `${{ github.event.* }}` values in `run` commands.
+- Avoid direct interpolation of untrusted GitHub Actions context values (e.g., `${{ github.event.* }}`) in `run` commands.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/securecode.instructions.md` at line 179, Update the sentence that
currently reads "Avoid direct interpolation of untrusted `${{ github.event.* }}`
values in `run` commands." to use the correct platform capitalization "GitHub"
(i.e., "Avoid direct interpolation of untrusted `${{ github.event.* }}` values
in GitHub Actions `run` commands."), while preserving the literal expression
`github.event.*` in lowercase if you intend to show the expression syntax.
docs/hardening.instructions.md (2)

27-27: 💤 Low value

Clarify scope of Rule 10 with improved structure.

Rule 10 combines two distinct concerns—workflow/log output and LittleFS file storage—in a single sentence. The "or" construction makes it slightly ambiguous whether both clauses apply to "secret exposure" or if they're alternatives.

Suggested rewording for clarity
-10. **No secret exposure in workflows/log output, or in LittleFS files other than `wsec.json`**.
+10. **No secret exposure in workflows/log output or in LittleFS files** (except `wsec.json`).

Or split into two sub-points if the distinction is important:

-10. **No secret exposure in workflows/log output, or in LittleFS files other than `wsec.json`**.
+10. **No secret exposure**: reject secrets in workflow/log output and in LittleFS files other than `wsec.json`.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/hardening.instructions.md` at line 27, The Rule 10 sentence is ambiguous
because it joins workflow/log output and LittleFS file storage with "or"; update
the text for clarity by either (a) rephrasing the single sentence to explicitly
state both must not contain secrets (e.g., "No secret exposure in workflows or
log output, and no secret storage in LittleFS files except wsec.json"), or (b)
split into two sub-points under Rule 10—one forbidding secrets in workflows/log
output and a second forbidding secrets in LittleFS files other than
`wsec.json`—so the scope of each restriction is unambiguous.

2-2: 💤 Low value

Consider removing CSS from the applyTo glob.

The applyTo glob includes css files, but none of the 26 hardening rules are meaningfully applicable to CSS. CSS files don't contain buffer operations, format strings, auth logic, or other rule targets. Consider removing css from the glob to avoid unnecessary processing.

Suggested adjustment
-applyTo: "**/*.{cpp,h,hpp,ino,js,htm,html,css,yml,yaml}"
+applyTo: "**/*.{cpp,h,hpp,ino,js,htm,html,yml,yaml}"
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/hardening.instructions.md` at line 2, The applyTo glob currently
includes CSS via the line applyTo:
"**/*.{cpp,h,hpp,ino,js,htm,html,css,yml,yaml}"; remove "css" from that brace
list so it reads applyTo: "**/*.{cpp,h,hpp,ino,js,htm,html,yml,yaml}" (or
equivalent) to avoid running the 26 hardening rules against CSS files; if you
later need CSS-specific checks, create a separate rule set or glob for CSS
instead.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@docs/hardening.instructions.md`:
- Line 27: The Rule 10 sentence is ambiguous because it joins workflow/log
output and LittleFS file storage with "or"; update the text for clarity by
either (a) rephrasing the single sentence to explicitly state both must not
contain secrets (e.g., "No secret exposure in workflows or log output, and no
secret storage in LittleFS files except wsec.json"), or (b) split into two
sub-points under Rule 10—one forbidding secrets in workflows/log output and a
second forbidding secrets in LittleFS files other than `wsec.json`—so the scope
of each restriction is unambiguous.
- Line 2: The applyTo glob currently includes CSS via the line applyTo:
"**/*.{cpp,h,hpp,ino,js,htm,html,css,yml,yaml}"; remove "css" from that brace
list so it reads applyTo: "**/*.{cpp,h,hpp,ino,js,htm,html,yml,yaml}" (or
equivalent) to avoid running the 26 hardening rules against CSS files; if you
later need CSS-specific checks, create a separate rule set or glob for CSS
instead.

In `@docs/securecode.instructions.md`:
- Line 179: Update the sentence that currently reads "Avoid direct interpolation
of untrusted `${{ github.event.* }}` values in `run` commands." to use the
correct platform capitalization "GitHub" (i.e., "Avoid direct interpolation of
untrusted `${{ github.event.* }}` values in GitHub Actions `run` commands."),
while preserving the literal expression `github.event.*` in lowercase if you
intend to show the expression syntax.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 9d476561-594e-456a-824d-0070923f2bc7

📥 Commits

Reviewing files that changed from the base of the PR and between 2fd1c1e and bfdc594.

📒 Files selected for processing (2)
  • docs/hardening.instructions.md
  • docs/securecode.instructions.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

AI Partly generated by an AI. Make sure that the contributor fully understands the code! discussion enhancement wontfix

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants