安全与权限 · 实作指南
审查 AI 生成程式，也要审查容器建置过程
应用原始码看似乾净，建置产物仍可能夹带凭证。
容易忽略的交付产物
假设 AI 生成的应用通过功能测试，但建置时以参数传入凭证下载私人套件。只看应用档案会漏掉另一道边界：哪些东西进入映像，以及哪些会留在各层产物。建议列出建置输入，包括原始码、套件来源、生成档案与密钥。真正送往正式环境的产物值得独立审查，不能因为版本库没有明文密码，就推断交付包也完全没有。
让建置密钥只在必要时出现
Docker 文件提供建置密钥挂载方式，应使用建置器支援的机制，而不是把普通参数当成保密通道。下载套件与执行应用的凭证亦应分开。还要查看安装脚本及日志：若某步把值复制到别处，临时挂载也保护不了。建议各阶段使用最小范围凭证，并以能撤销的专用身份代替开发人员长期个人权限，让交付後的责任更清晰。
流程一览
检查可重建的发布版本
透过受控发布流程产生映像，并以摘要识别版本。检查已知密钥模式及档案清单，找出意外加入的压缩档、本地设定或客户文件。演练可放入假凭证，确认扫描真的能拦住。扫描是有用检查，但不是不存在外泄的证明；仍应缩小建置脉络，审查每个步骤，避免直接把整个工作目录复制进产物，令临时文件和备份一起被发布。
交付也要能重新建置
交付时确定依赖更新後由谁重建、从哪里取得获准凭证，不应必须依靠原开发者的笔电。记录刻意排除的档案，以及建置凭证出问题时如何撤销。这能让 AI 辅助开发更容易维护，但界线仍要说清：乾净的建置不会证明业务逻辑或授权设计正确。功能、权限与交付产物三方面都要有各自的检查，不能互相代替。
检查客户真正收到什麽
安装压缩档、容器映像和支援资料包应分开检查。映像乾净，不代表把开发工作目录压成 ZIP 也安全。建立发布清单，列出允许资源与必要执行档，再核对真正交付包。特别注意备份设定、测试输出、暂存客户资料和历史日志；它们可能对执行毫无需要，却容易被一并收进去。交付後保存清单，让日後重建也有相同标准。
来源与延伸阅读
- Build secretsBuild secretsDocker · 官方文件 ·
- Using secrets in GitHub ActionsUsing secrets in GitHub ActionsGitHub · 官方文件 ·
编辑原则
本系列以 AI 辅助原创撰写，并对照连结的公开来源。实作建议与假设情境属编辑分析，并非客户实绩。来源发布日期及产品细节可能与本系列整理日期不同。