Scan Policy Rules

This page documents every rule with a stable anchor equal to its ruleId. Use these anchors for deep links from tooling and SARIF.

Crypto libraries

crypto_lib_present

• What it means: The binary appears to include a cryptographic library (e.g., OpenSSL, mbedTLS, wolfSSL, BoringSSL).
• Why it matters: Helpful context for other crypto/hardening findings; not an issue by itself.
• Evidence you’ll see: Library names or technology indicators in the report.
• How to fix: No action required. Use alongside weak‑crypto and transport‑security findings.

Weak crypto algorithms

weak_crypto_algorithms

• What it means: The binary references weak or deprecated cryptography (e.g., MD5, SHA‑1, RC4, DES, ECB mode).
• Why it matters: These primitives are vulnerable and can undermine authentication, integrity, or confidentiality.
• Evidence you’ll see: Algorithm names or cipher/mode identifiers.
• How to fix: Replace with modern primitives (SHA‑256/512, AES‑GCM or ChaCha20‑Poly1305, Ed25519/ECDSA‑P256). Remove compatibility fallbacks.

Insecure randomness

insecure_random

• What it means: Non‑cryptographic random sources appear to be used without a secure alternative.
• Why it matters: Weak randomness can break keys, tokens, and nonces.
• Evidence you’ll see: References to APIs like rand/srand/GetTickCount/time without secure RNGs nearby.
• How to fix: Use a CSPRNG (getrandom/arc4random/libsodium randombytes/CTR_DRBG). Ensure all security‑sensitive randomness comes from a CSPRNG.

Network indicators (grouped)

network_indicators

• What it means: The binary shows signs of networking (HTTP(S) URLs, MQTT/CoAP markers, socket usage).
• Why it matters: Context for transport security and exposure; not always a problem on its own.
• Evidence you’ll see: Counts of URLs/protocols and common socket calls.
• How severity is chosen: Low by default; increases to medium if plaintext HTTP is present.
• How to fix: Prefer HTTPS/TLS; review protocol usage; restrict network access where possible.

Insecure protocols

insecure_protocol_http

• What it means: Plaintext HTTP endpoints were found.
• Why it matters: Unencrypted traffic exposes data and invites interception/tampering.
• Evidence you’ll see: One or more http:// endpoints in findings.
• How to fix: Replace with HTTPS, enforce TLS verification, remove plaintext fallbacks.

telnet_present

• What it means: Telnet/Telnetd usage is indicated.
• Why it matters: Telnet is unencrypted and frequently targeted.
• Evidence you’ll see: Strings like “telnet”, “telnetd”, and login prompts.
• How to fix: Remove Telnet; use SSH or secure management channels.

ftp_present

• What it means: FTP client/server indicators are present.
• Why it matters: FTP is plaintext and susceptible to credential theft/mitm.
• Evidence you’ll see: “ftp://”, “ftpd”, or command strings.
• How to fix: Replace with HTTPS/SFTP; disable legacy services.

Secrets detection (strong patterns)

suspected_secrets

• What it means: Embedded secrets or strong secret patterns were found (e.g., PEM private keys, AWS AKIA IDs).
• Why it matters: Secrets in binaries can be extracted and abused at scale.
• Evidence you’ll see: A count of suspected secrets and examples (truncated) when safe.
• How severity is chosen: Scales with count and sensitivity of patterns.
• How to fix: Remove secrets; use a secrets manager; inject at runtime; rotate leaked credentials.

Update/OTA and signature verification

signed_update_support

• What it means: Update/OTA flow appears to verify signatures.
• Why it matters: Signed updates prevent malicious firmware/application injection.
• Evidence you’ll see: Mentions of signature verification symbols/strings.
• How to fix: Ensure verification is mandatory, failures are fatal, and keys are protected.

insecure_update_mechanism

• What it means: Update/OTA logic is indicated without clear signature verification.
• Why it matters: Unsigned updates allow unauthorized or malicious code to be installed.
• Evidence you’ll see: Update/OTA references without corresponding verification evidence.
• How to fix: Enforce signed updates, verify before apply, add rollback protection.

Memory protections

writable_executable_section

• What it means: The binary appears to contain sections that are both writable and executable (W^X violation).
• Why it matters: W^X increases risk of code‑injection and exploitation.
• Evidence you’ll see: Section names/flags indicating both write and execute permissions.
• How to fix: Enforce W^X; enable RELRO/PIE; audit linker and build flags.

stack_protector_enabled

• What it means: Stack protection appears enabled (evidence like __stack_chk_fail).
• Why it matters: Stack canaries reduce impact of buffer overflows.
• Evidence you’ll see: Hardening symbol(s) present.
• How to fix: Ensure stack protector is enabled consistently across all modules.

stack_protector_missing

• What it means: No evidence of stack protector.
• Why it matters: Missing canaries increase risk from memory‑safety bugs.
• Evidence you’ll see: Absence of common hardening symbols.
• How to fix: Compile with -fstack-protector-strong or equivalent; confirm across modules.

Secure boot indicators

secure_boot_present

• What it means: Evidence suggests secure/verified boot is implemented.
• Why it matters: Prevents execution of untrusted boot code.
• Evidence you’ll see: References to signature verification in the boot path.
• How to fix: Ensure keys are protected, versions/counters enforced, and failures stop boot.

secure_boot_missing_evidence

• What it means: No clear evidence of secure boot where we’d expect it.
• Why it matters: Boot sequence may allow untrusted code.
• Evidence you’ll see: Boot‑related indicators without verification references.
• How to fix: Add immutable root‑of‑trust verification before executing loaded code; protect keys and enforce failures.

Flash encryption likelihood (ESP‑IDF specific)

flash_encryption_likely

• What it means: Likely evidence of flash/storage encryption (not definitive).
• Why it matters: Encrypting stored data mitigates extraction/forensics risks.
• Evidence you’ll see: Partition/flash terms with crypto libraries or AES references.
• How to fix: Validate key management, key storage, and the threat model.

Debug interfaces

debug_interfaces_enabled

• What it means: Indicators suggest debug interfaces (JTAG/SWD/UART) may be enabled.
• Why it matters: Debug ports can bypass security if exposed in production.
• Evidence you’ll see: References to JTAG/SWD/UART or debug consoles.
• How to fix: Disable/lock debug in production; require authentication; remove debug consoles.