先说结论：这不是“把密钥放进 .env”就能解决的问题

研究者描述的泄露链从公开固件开始。他先解开外层包，再从升级程序还原 rootfs 的解密流程，最后用 secret scanner 在约 30 个文件里发现同一 GitHub token。最关键的代码线索不是某位开发者手写了 token，而是前端构建对象疑似接收了整个 `process.env`，于是 CI 作业能看到的变量被一并固化进静态资源。只要资源进入固件，设备可能多年不更新，短期构建失误就变成长期供应链风险。

这对中文开发者很实用，因为相同错误不只发生在摄像头。Vite、Webpack、Next.js、移动应用打包、桌面壳和 Docker 构建都可能把服务端环境误带到客户端。正确做法不是把真实值换一个变量名，而是建立显式允许列表：只有确认可公开的键才能进入前端；客户端公开变量使用单独前缀和最小 CI job；构建后对 bundle、source map、镜像层与发布制品做 secret scan，并让发现结果阻断发布。

写作时必须把三种状态分开

第一种是研究者直接从下载固件观察到的内容：文件、环境变量和重复 token。第二种是研究者通过 GitHub 查询得到的权限与仓库范围，这部分仍需厂商或平台审计交叉确认。第三种是推测：实体设备是否把资源实际发给浏览器、历史上是否有人利用、环境里的特殊 IP 为什么存在。原作者明确把部分内容标为猜测，二次报道不能用军事背景拼出没有证据的攻击故事。

研究者称 Hanwha 在 12 小时内回复并撤销 token，这是积极的响应信号，却不是完整结案。负责的事故处理还要回答：哪些型号和版本受影响，token 何时创建、被哪些作业使用，是否有异常克隆或设置修改，历史固件和 CDN 缓存如何处理，其他环境变量是否包含可利用凭据，以及客户是否需要升级。没有官方公告时，只能把这些列为待确认问题。

一篇高价值内容可以附一份十分钟自查：搜索前端代码对 `process.env` 的展开，检查客户端变量前缀，导出生产 bundle 后跑 secret scanner，查看 source map 与静态 JSON，核对 CI 账号是否拥有组织管理权限，并把长期 token 改成短期、最小权限凭据。真正的教训不是“硬件公司也会犯低级错误”，而是任何能读取秘密的构建步骤，都必须证明输出不含秘密。