安全摄像头本来是用来降低风险的。所以 Hanwha Vision/Wisenet 这件事才会让安全圈格外在意：一名研究者称，他在摄像头固件里发现了 GitHub token，而且它出现在登录页面相关的前端文件中。

网络摄像头固件包中被安全扫描器发现的已遮盖 CI token

这件事不应该被读成“所有摄像头都被攻破了”。根据作者的说法，token 很快被吊销；目前核对到的公开资料也没有证明存在大规模利用。更有价值的结论是：嵌入式设备也会继承 Web 产品和 CI/CD 流水线里的普通错误，只是这些错误会被打进 firmware image，随后被客户安装并长期遗忘。

7 月 24 日的原始文章描述了研究过程：下载 Hanwha 固件，提取文件系统，再运行 secret scanner。作者说 TruffleHog 在大约 30 个文件中发现了同一个 GitHub credential。他还称，这个 token 对 Hanwha 的 GitHub organization 中数百个仓库拥有 admin privileges。作者披露后，Hanwha 据称在 12 小时内回复，表示 token 已经 revoked。

我没有找到 Hanwha 官方 advisory 来确认受影响型号、固件版本或 token 权限细节。但 Hanwha 官网显示，这家公司销售 network cameras、视频管理和 AI security 产品，场景包括机场、银行、数据中心、城市监控、政府、医疗、交通和 utilities。也就是说，摄像头固件里的 secret 不是一个小小的开发事故。

机制很关键。作者认为问题出在用 Vite 构建的 Web UI：某个变量似乎把 CI job 的环境写进了 client-side files。Vite 文档写得很清楚：带 VITE_ 前缀的变量会在打包后暴露到客户端代码中，其他变量正常情况下不应通过这条路径暴露。所以重点不是“Vite 会泄露 secret”，而是 build boundary 没有被严格治理。

固件会让错误保存得更久。网站上的 bundle 可以重新构建并部署。摄像头 firmware image 可能出现在厂商下载页、分销商归档、NVR 维护流程和现场设备里，几年都没人动。吊销 token 能解决紧急 credential 风险，但不能解释为什么一个权限很宽的 secret 会进入 release artifact。

IP 摄像头的管理员应该冷静处理。先盘点型号和 firmware versions，查看厂商 advisory 和更新。如果厂商没有公开说明，就向支持渠道询问：你的型号是否受影响，固件里的 embedded credentials 是否已经移除，相关 secrets 是否已经轮换。

不要把摄像头当成被动设备。它更像一个由外部供应商管理的小电脑。把它放进单独的 VLAN 或隔离网络。除非功能确实需要，不要让摄像头直接访问互联网。能用本地 NVR 或管理服务器通过 ONVIF/RTSP 连接，就不要让每台摄像头自由访问云端。

采购也要换问题。Datasheet 会告诉你分辨率、夜视和镜头，却不会告诉你厂商是否扫描最终 firmware artifact，是否使用环境变量 allowlist，token 是否短期有效且权限最小，release 是否签名，vulnerability disclosure 的响应时间是多少。

厂商需要的是枯燥但可靠的控制：扫描源码、构建后的 Web bundle、解包后的 rootfs 和最终 firmware archive。只要出现 token、private key、webhook secret 或内部 credential，build 就应该失败。Frontend build job 不应该因为方便就拿到 organization-wide token。

这件事里比较好的部分是响应。研究者说 Hanwha 在 12 小时内回复并撤销 token。这不能抹掉 build failure，但说明可见的 security contact 和成熟的 response process 很重要。Hacker News 讨论大约有 640 points 和 230 comments，话题也很快转向实践：ONVIF、VLAN、阻断 WAN、自托管 NVR，以及把摄像头当成不可信 endpoint。

核心教训很简单：security product 仍然是 software product。Firmware 是 release artifact，Web UI 是 client bundle，更新系统是 supply chain 的一部分。如果这些环节能把 CI secret 带到客户手里，摄像头就不再只是一个被动盒子。