embedded-engineer
PassAudited by ClawScan on May 10, 2026.
Overview
This instruction-only embedded engineering skill appears purpose-aligned, but its sample IoT code includes hardcoded placeholder credentials and insecure network/OTA patterns that should be hardened before real deployment.
This skill is reasonable to install as an instruction-only embedded engineering reference. Treat the included code as educational, not production-ready: replace placeholder credentials, secure MQTT with TLS/authentication, and use signed HTTPS OTA updates before deploying anything to real hardware.
Findings (3)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If copied unchanged into a real project, users may normalize storing Wi-Fi passwords directly in firmware.
The example includes a hardcoded Wi-Fi credential-looking value. It appears illustrative and purpose-aligned for embedded networking code, but hardcoding real credentials would be unsafe.
const char* ssid = "IoT_Network"; const char* password = "SecurePassword123";
Replace placeholders with secure configuration handling, avoid committing real secrets, and document credential storage best practices.
A copied deployment could expose device commands or telemetry to parties that can reach the broker/topic namespace.
The example uses a public MQTT broker on the common plaintext port and subscribes to command/config topics. This is relevant to IoT examples, but real deployments need authentication, authorization, TLS, and topic isolation.
const char* mqtt_server = "broker.hivemq.com";
const int mqtt_port = 1883;
...
mqtt.subscribe("iot/devices/ESP32_SENSOR_001/commands");
mqtt.subscribe("iot/devices/ESP32_SENSOR_001/config");Use a private or authenticated broker, TLS, per-device credentials, restricted topics, and explicit command validation before deploying similar code.
If adapted directly, a device could install firmware from an unauthenticated or tampered update source.
The reference firmware example demonstrates downloading and applying OTA updates from a remote URL over HTTP. OTA updates are expected for IoT examples, but unsecured firmware update paths are high-impact if reused without verification.
http.begin("http://update.server.com/firmware/latest.json");
...
t_httpUpdate_return ret = httpUpdate.update(client, url);Require HTTPS, signed firmware, version/rollback checks, trusted update metadata, and user or fleet-policy approval for OTA updates.