divoom-protocol is a small Bluetooth LE client library. The realistic attack surface is narrow:

• No network exposure. The library only speaks BLE to nearby Divoom devices. It does not open sockets, listen on ports, or make outbound HTTP calls.
• No untrusted input parsing. Public API accepts typed Python values (ints, bytes, RGB tuples). There is no string parsing of attacker-controlled input.
• No persistent secrets. The only state persisted to disk is a randomly generated controller UUID at ~/.divoom-protocol/state.json. It is not a credential and contains no PII.
• No code execution paths. The library does not exec, eval, or use subprocess against untrusted inputs.
• Hardware impact only. Worst-case misuse causes the user's own Divoom panel to show unexpected content or briefly disconnect. There is no path to compromise the host OS, network, or other devices via this library.

Open a private security advisory on the GitHub repository, or email the maintainer directly (address in pyproject.toml).

Please do not file public issues for security reports. Allow up to 30 days for an initial response.

• Run pip-audit periodically against your dependency graph. divoom-protocol's only runtime dependency is bleak.
• Pin a minimum version of divoom-protocol (e.g. >=0.1) rather than an exact pin so security patches flow in.
• If embedding in a multi-tenant context (unusual for an ambient display library), be aware that BLE radio activity is observable to anyone in physical proximity. The protocol bytes are not encrypted on the radio.

• All try/except blocks are scoped and either re-raise or log the exception (never silently swallow).
• Dependency pins use >= to allow security patches without breaking releases.
• bandit -r divoom_protocol/ runs clean (0 high, 0 medium severity findings).
• pip-audit runs clean (no known CVEs in dependency tree).
• Per-installation controller UUID is randomly generated, not derived from any identifying data.

• Vulnerabilities in bleak or other transitive dependencies — please report upstream.
• Vulnerabilities in the Divoom device firmware itself — report to Divoom directly.
• Issues that require physical access to the user's machine or BLE pairing key extraction.