用 AI 做安全加固清单：常见疏漏项

上线前一天的评审会上，安全同事把去年的检查表投到屏幕上，一行行念，念到「密钥管理」时停住了：仓库里有三个配置文件带着明文密钥，其中一个还是两年前提交的。这类场面在复盘里出现得太频繁，以至于原因常被写成「意识不足」。更准确的说法是，这些疏漏不会报错，不做也没人发现，直到出事。AI 在这件事上的用处是把检查项列全、把责任分到人；哪一条对你真的要紧，仍然得靠熟悉这套系统的人判断。

反复出事的，总是那几个位置

权限过大、密钥进仓库、默认配置暴露在公网、日志里带敏感字段、依赖长期不更新——这五类几乎年年重演。共同点是它们都站在「默认安全」的反面：框架装好就能跑，跑起来就是可用的，于是没人回头改。数据库的默认端口、没设密码的缓存、用初始账号登录的管理后台，这些在本地开发时毫无痛感，一上公网就是入口。

另一类疏漏藏在流程里：离职人员的账号没回收、测试环境直接连生产库、临时开的调试接口忘了关。它们不属于任何一次提交，代码评审看不见，扫描器也扫不出来。调用外部模型服务时留下的令牌同样归入此类，API 密钥泄露之后能被拿去做什么，往往比团队预估的严重。

三个阶段，各自该留下什么

按开发、部署、运行三段切，每段产出物的性质不同：前两段留下的是配置与记录，第三段留下的是证据。

第三行是最容易形式化的一格。审计日志的价值不在存了多久，在于出事后能不能回答「谁在什么时候改了什么」。答不上来，日志就只是一堆占空间的文本。

按阶段切，是因为签字的人不同

按漏洞类型分类看起来更专业，用起来会卡在责任上：一个注入风险既涉及开发写法，也涉及部署时的参数配置，还涉及运行期的监控，分给谁都不合适。按阶段分，开发管密钥和日志字段，运维管网段和账号，运行期管监控和补丁，每条都有明确的归属人。

归属清楚了，清单才可能被执行。没有归属的检查项，最后都会落到「大家都以为别人会做」的位置上。

提示词要交代的是系统边界

让模型出清单，输入质量决定输出可用度。系统类型、技术栈与版本、部署形态（云主机、容器、无服务器）、数据敏感级别、团队规模、是否对公网开放，这几项交代清楚，它给的条目才会具体到「对象存储的桶策略」，而不是泛泛的「做好访问控制」。可以要求它同时输出三样东西：按阶段分组的检查项、每项的执行方式（自动或人工）、上线前的必查子集。

还要加一句约束：只基于给定信息，不要编造具体的漏洞编号和版本号。模型很容易补上看起来专业的编号，这类编号一旦写进正式清单，会误导执行的人。模型为什么会编出不存在的编号这件事值得在交付前过一遍，提示词里该放哪几类约束则决定了它输出的可核对程度。

哪些检查进流水线，哪些必须人看

依赖漏洞扫描、密钥泄露检测、配置基线核查、镜像层扫描，这四类适合放进流水线，每次提交自动跑。它们的判断标准确定，误报能靠规则收敛，单次成本也低。放到流水线之后，要配一条硬规则：高危项直接拦住合并，否则跑完没人处理的扫描等于没跑。

权限设计是否合理、日志字段该不该脱敏、这个接口是否真的需要对外，这类没有标准答案，取决于业务。把它们做成评审项，让改动的人写一句「为什么这样设计」，比让机器猜有效得多。

清单会腐烂，除非每次都补一条

清单最常见的死法是变成一次性的检查表：做完一次，归档，第二年拿出来照抄。真正管用的习惯只有一个——每次出事、每次渗透测试、每次外部审计发现问题，当场补一条，并写清是哪类场景漏的。补的时候别写「加强权限管理」这种无法执行的话，写成「服务账号默认只给只读权限，需要写权限时单独申请并留记录」。

另一个动作是删。技术栈换了、组件下线了，对应条目要跟着走。一份两百条、其中八十条已经不适用的清单，执行率一定低，因为执行的人知道里面有一半是废话。

它列得出条目，判不了你的风险

它摸不到你的现场：哪台机器最要紧、哪些历史例外是当年赶工期留下的，它都不知道。它给的是行业通用清单，通用清单能覆盖行业里常见的大类，覆盖不到你最脆弱的那一处。同一份清单放在交易系统和内部报表系统上，优先级应该完全不同，这个排序它做不了。

它同样验证不了执行结果。清单上写着「已关闭默认账号」，究竟关没关，要人去查配置、去试登录。让 AI 生成清单、让人核对结果，这个分工比较稳；反过来，让它判断「这样算不算加固到位」，得到的多半是一句听起来专业但没有依据的结论。

速查：一份能用的加固清单长什么样

• 按开发、部署、运行三段分组，每条有归属人
• 五类高发疏漏单列：权限、密钥、默认配置、日志字段、依赖版本
• 每条标注执行方式，流水线自动或人工评审
• 上线前只留十到十五条必查项，逐条附证据位置
• 出事当天补一条，技术栈下线时删一条