AI生成代码正在从“辅助建议”走向“直接参与提交、审查和修复”。2026年9月16日，GitHub更新AI Scan能力，使其在未启用CodeQL默认配置的部分仓库中也可用于拉取请求漏洞检测；9月17日，Microsoft再次强调，AI时代的主要风险仍集中在过度权限、未修补系统、暴露的执行路径和控制断层等基础问题。两项近期公开信息共同说明：AI可以提高检测效率，但不能替代上线责任人，也不能成为降低发布门槛的理由。
先明确原则：AI生成不等于责任转移
企业应把AI生成代码视为来源特殊的第三方输入，而不是天然可信的内部成果。无论代码由模型生成、开发者修改，还是由智能代理自动提交，最终合并与上线决定都由组织中的具体角色作出。因此，供应商可对工具缺陷、服务能力和合同承诺负责，使用方仍需对需求设计、权限配置、人工审查、测试验证及生产发布承担管理责任。
内容治理也不能脱离技术流程。《互联网信息服务管理办法》第十五条规定了互联网信息服务不得制作、复制、发布、传播的九类内容，第六条同时要求经营性互联网信息服务具备健全的网络与信息安全保障措施。落实到AI代码审查中，就是既检测传统漏洞，也检查代码是否可能生成违法信息、泄露秘密或个人信息、侵害合法权益、散布虚假内容。论坛常说的“九不准”和“七条底线”，可进一步转化为法律法规、国家利益、公民权益、公共秩序、道德风尚与信息真实性等发布检查项，具体条文应以来源链接为准。
上线前建立四道安全检测关口
第一道：来源与变更边界检查
- 记录使用的模型、插件、生成时间、提示词用途、提交人和修改范围，避免出现问题后无法还原过程。
- 禁止向外部模型提交密钥、真实用户数据、未公开源码、内部接口文档和其他敏感材料。
- 对模型推荐的依赖包、镜像和代码片段核验真实来源、版本、许可证及维护状态，防止误用不存在、被仿冒或存在供应链风险的组件。
- 统计单次提交的新增接口、权限变化、数据库操作和网络访问能力，超出原需求的代码必须单独审查。
第二道：自动化扫描与安全测试
静态应用安全测试、依赖分析、密钥扫描和基础设施即代码检查应进入持续集成流水线，并设置不可绕过的合并门禁。2026年9月16日发布的GitHub AI Scan更新说明显示，AI辅助漏洞发现正在覆盖更多符合条件的仓库，但该功能仍需在仓库、组织或企业层面启用，而且处于公开预览阶段。这意味着AI扫描适合作为补充检测层，不能取代成熟规则引擎、测试用例和人工判断。
- 先执行编译、单元测试、类型检查和代码规范检查，排除基础质量问题。
- 再检查注入、越权、路径遍历、不安全反序列化、服务端请求伪造、敏感信息泄露及弱加密等常见风险。
- 对新增依赖生成软件物料清单，核验版本、漏洞公告、许可证和完整性校验信息。
- 对登录、支付、管理后台、文件上传及对外API开展动态测试或针对性渗透测试。
- 发现高危漏洞、明文密钥或未经授权的高权限调用时，直接阻断合并与发布。
第三道：人工复核业务语义
扫描工具能够发现已知模式，却未必理解“这个用户是否有权执行这项操作”。人工评审应重点检查身份认证、对象级授权、租户隔离、异常处理、日志脱敏、数据删除和业务状态转换。至少安排一名未参与代码生成的评审者进行独立检查；涉及资金、个人信息、关键数据或生产运维权限时，应增加安全人员和业务负责人联合签字。
第四道：受控发布与运行监测
近期Microsoft安全实践文章指出，AI环境中的攻击路径可能跨越身份、终端、应用、网络和AI系统，并建议采用明确验证、最小权限和假设已失陷等零信任原则。对应到发布环节，应通过灰度放量、最小化服务账号权限、限制出站连接、设置异常告警并保留快速回滚能力，避免一个生成错误演变为跨系统事件。
用责任矩阵划清漏洞归属
- 开发者：核对生成结果、补充测试、说明风险，不得以“模型写的”为由免除审查义务。
- 代码评审者：对可读性、业务语义、权限边界和异常路径给出独立结论。
- 安全团队：制定检测规则、风险等级、阻断标准和例外审批流程，并验证高风险模块。
- 产品与业务负责人：确认需求合法、数据使用必要、功能不会突破原有用户授权范围。
- 发布负责人：核验门禁结果、审批记录、回滚方案和监控配置，只对证据完整的版本放行。
- AI工具供应商：依据合同承担平台安全、服务缺陷、数据处理和已承诺能力范围内的责任。
责任划分应以证据链为基础。建议在工单和代码仓库中保存生成标记、提交记录、扫描报告、评审意见、例外批准、制品哈希和部署日志。发生漏洞时，先判断问题来自需求、生成内容、人工修改、配置、依赖还是发布操作，再按照合同和内部制度处理，避免笼统归责给“AI”或某一名开发者。
把“九不准”和“七条底线”做成发布门禁
上线评审不应只问“代码能否运行”，还应回答“内容是否合法、数据是否必要、权限是否最小、事实是否可核验、责任是否可追溯”。
对于中文论坛、内容社区和生成式应用，可在功能测试中加入敏感内容拦截、事实来源提示、投诉处置、账号滥用防护和人工复核机制。若AI代码新增内容生成或自动发布能力，应检查其是否可能绕过审核、伪造来源、批量扩散不实信息或侵犯他人权益。这样才能把原则性底线转化为可执行、可审计的工程控制。
总结
AI生成代码安全治理的关键，不是增加一次“AI扫描”，而是建立贯穿生成、提交、检测、评审、发布和运行的闭环。组织应坚持AI代码默认不可信、自动扫描不等于安全结论、重大风险必须人工复核、生产责任必须落实到人的原则。只有当技术门禁、内容底线和责任证据同时完备，AI带来的速度提升才不会变成漏洞扩散速度的提升。
事件或资料日期：
2026年9月16日：GitHub发布“Code scanning AI Scan no longer requires CodeQL default setup”更新，资料见官方更新说明[1]。
2026年9月17日：Microsoft发布“From guidance to action: Security fundamentals that materially reduce risk”，资料见官方安全博客[2]。
2024年12月6日第二次修订：《互联网信息服务管理办法》现行条文及历史沿革见来源链接。
