文章目录 / 点击展开
AI 可以加速代码安全审查，但不能替代安全测试和专业判断。正确用法是让它帮助梳理资产、入口、信任边界和可疑路径，再用代码、配置、测试结果和运行证据确认问题。不要仅凭模型输出给漏洞定级，也不要直接执行未经审查的修复补丁。
先确定审查范围和关键资产
先列出本次变更涉及的服务、接口、队列、数据库、对象存储、密钥和第三方依赖。明确哪些数据属于账号、个人信息、支付、内部配置或业务机密，并标记互联网入口、管理员入口和内部服务调用。
安全审查应以变更为中心，同时向外追踪调用链。只把一个函数交给 AI，通常看不到鉴权中间件、输入来源、数据库约束和部署配置，容易产生误报或漏报。
第一步：画出数据流和信任边界
把请求从用户输入到最终存储或外部调用的路径写清楚，包括身份验证、权限判断、解析、业务校验、查询、日志和响应。每跨越一次系统、账号或权限域，都视为新的信任边界。
请根据以下路由、服务和配置整理数据流：
1. 列出外部输入与敏感资产；
2. 标出身份验证、授权和数据校验位置；
3. 仅提出待验证风险，不直接判定漏洞；
4. 为每项风险给出需要查看的代码或运行证据。若上下文不完整，要求模型明确“缺少哪些文件”，不要让它用假设填补架构。
第二步：按风险类别检查代码
优先检查越权、注入、敏感信息泄漏、服务端请求伪造、文件上传、反序列化、路径处理、开放重定向和不安全加密。对于 AI 功能，还要检查提示注入、工具越权、知识库数据泄漏和模型输出直接驱动危险操作。
每个发现必须包含代码位置、可控输入、到达危险操作的路径、现有防护和可复现条件。如果没有完整路径，应标为“待验证”，避免把模式匹配结果当作真实漏洞。
第三步：核对鉴权与业务权限
登录成功不等于有权操作资源。逐个检查资源是否绑定当前用户或组织、管理员操作是否单独授权、批量接口是否逐项校验、后台任务是否保留发起者身份，以及对象 ID 是否可被替换访问其他数据。
权限测试至少覆盖未登录、普通用户、其他组织用户、过期权限和管理员角色。AI 可以生成测试矩阵，但角色关系和预期结果必须由业务负责人确认。
第四步：审查依赖、配置和密钥
检查依赖锁文件、镜像基础版本、公开端口、跨域策略、调试开关、默认账号和日志级别。密钥不应出现在源码、前端资源、错误响应、测试快照或日志中；生产与测试环境应使用不同凭据和最小权限。
依赖风险以实际扫描工具和供应商公告为准。模型可以解释公告与影响路径，但不能凭记忆判断某个版本一定安全。
第五步：小步修复并设计反向测试
每次只修一个风险，保持变更可审查。除了正常测试，还要添加证明旧行为会失败、修复后被阻止的安全回归测试。例如越权修复需要测试其他用户资源，注入修复需要覆盖参数边界，文件上传需要检查扩展名、内容和存储路径。
生成补丁时要求 AI 解释原有防护为什么不足、修复依赖什么前提、可能改变哪些正常行为和如何回滚。代码层评审可配合 GitHub Copilot 代码审查流程，但安全结论仍需独立验证。
第六步：验证与发布
先运行最小相关测试，再执行静态分析、依赖扫描和完整测试。对高风险修复在测试环境复现攻击路径，确认日志和告警能记录异常但不会泄露敏感值。上线后监控错误率、拒绝率、异常权限访问和新告警。
若问题已被利用或可能影响真实用户，应进入安全事件流程，而不是只提交普通代码修复。保留时间线、影响范围、证据和处置记录。
安全审查清单
- 是否明确资产、入口和信任边界。
- 每个风险是否有可控输入到危险操作的完整路径。
- 是否单独检查业务权限而非只看登录状态。
- 密钥和敏感数据是否可能进入前端、日志或错误消息。
- AI 或自动化工具是否具有超出任务需要的权限。
- 修复是否包含能够防止回归的反向测试。
- 高风险问题是否经过人工安全复核。
常见问题
AI 能发现所有代码漏洞吗
不能。它容易受上下文缺失影响，也无法替代运行环境、真实权限和业务规则验证。应与静态分析、依赖扫描、测试和人工评审组合使用。
可以把完整生产代码交给在线模型吗
先核对组织的数据政策、供应商条款和保留设置。敏感代码、密钥、客户数据和未公开漏洞不应在缺乏授权时上传。
修复后为什么还要保留安全测试
因为同类问题可能在重构或新增接口时再次出现。回归测试把安全边界变成可持续执行的约束。
排查运行错误和请求链路时，可结合 AI 接口与日志分析流程 收集证据，但日志必须先脱敏。