代码审查漏报严重漏洞，往往不是因为团队没有安全规范，而是因为几百条检查项没有区分轻重。当格式问题、命名建议和高危注入规则混在同一张清单里，审查者的注意力会被大量低风险噪声消耗，真正致命的越权、SQL注入和命令执行反而容易被跳过。要解决这个问题，需要把安全规则库建成可分层、可度量、可强制执行的结构，并为每条规则赋予清晰的优先级。
安全规则库与优先级设计不是单纯增加检测工具，而是改变漏洞拦截的组织方式。本文结合漏洞分类、评分模型和流水线接入，说明如何让代码Review从“什么都查”转向“只拦高危、分级处理”。
一、为什么传统代码Review会漏掉严重Bug
人工审查的漏报首先来自认知负荷。一个包含几百行变更的PR，如果同时要求检查命名规范、空指针、性能、安全、日志格式，审查者很难持续保持对安全问题的敏感度。尤其是跨函数、跨文件的数据流问题，例如用户输入经过多个服务后进入SQL查询，人工逐行看很难还原完整攻击路径。
其次是规则没有分级。很多团队的安全检查清单只是罗列了“避免拼接SQL”“注意XSS”“不要硬编码密钥”等条目，但没有告诉审查者哪一条必须阻断合并、哪一条可以后续修复。当所有规则都一样重要时，它们就都不重要。告警列表一旦超过几十条，人的本能是快速略过，而高危漏洞恰恰藏在那些需要仔细追踪的少数路径里。
安全规则库与优先级设计正是针对这两个问题，把安全知识从个人经验转成团队资产，再用严重级别重新分配审查注意力。
二、构建安全规则库：从漏洞分类到可检索规则
规则库不能只写一句“注意注入”，而应当包含机器可执行或至少可检索的结构。通常可以从OWASP Top 10、CWE/SANS Top 25以及公司历史安全事件中提取规则。每条规则建议至少包含规则ID、漏洞类型、CWE编号、严重级别、检测模式、反面示例、正面示例、修复建议、适用语言或框架。
例如一条Java SQL注入规则可以这样描述：规则ID为SEC-JAVA-001，CWE为CWE-89，严重级别P0，检测模式为使用java.sql.Statement拼接用户输入后执行executeQuery。反面示例使用字符串拼接，正面示例使用PreparedStatement。这样无论人工审查还是静态分析工具接入，都能按同一标准执行。
下面是一个简化的规则配置示例，很多SAST工具支持类似YAML格式：
rules:
- id: SEC-JAVA-001
title: SQL注入-Statement拼接
cwe: CWE-89
severity: P0
description: 禁止使用Statement拼接用户输入构造SQL
message: 请改用PreparedStatement进行参数化查询
pattern: |
Statement $stmt = $conn.createStatement();
...
$stmt.executeQuery($query);
规则库还可以覆盖XSS、命令注入、路径遍历、硬编码密钥、不安全反序列化、越权引用等。每条规则至少需要一个反面示例和一个正面示例，方便开发人员理解为什么会触发、怎么改。
三、优先级设计：用风险评分替代平均用力
优先级不能只凭“感觉严重”。建议使用三个因子：可利用性、影响范围、业务上下文。可利用性衡量攻击是否容易实施，例如远程无需认证的漏洞比本地且需要高权限的漏洞更危险；影响范围衡量成功利用后的后果，例如远程代码执行和敏感数据泄露高于普通信息暴露；业务上下文则根据系统不同调整，例如涉及支付、用户隐私、身份认证的模块应提高权重。
风险评分可以用一个简单公式表示：风险值 = 可利用性 × 影响范围 × 业务上下文。根据分数把规则拆成P0到P3四个等级。P0是必须立即阻断的漏洞，例如SQL注入、命令注入、硬编码生产密钥、任意文件上传；P1是需要在本次迭代修复的问题，例如存储型XSS、越权访问、不安全反序列化；P2可以排入近期修复队列，例如反射型XSS、缺少安全响应头；P3属于加固建议，例如日志缺少审计字段、错误信息过于详细。
| 优先级 | 处理策略 | 典型漏洞 |
|---|---|---|
| P0 | PR自动阻断，禁止合并 | SQL注入、命令注入、硬编码密钥 |
| P1 | PR自动评论，要求修复 | 存储型XSS、越权访问、不安全反序列化 |
| P2 | 提示并创建任务 | 反射型XSS、缺失安全头 |
| P3 | 建议修复，不阻塞 | 审计日志不完整、错误信息过详 |
优先级模型要有业务调整空间。例如金融系统可以把越权类规则从P1提升到P0，因为横向越权可能直接造成资金风险；内容资讯类系统可能把存储型XSS提升到P0，因为它是主要攻击面。规则优先级不应该一成不变，而应随着业务变化和安全事件复盘持续修正。
四、接入CI/CD：让高危规则自动执行
规则库和优先级如果只停留在文档里，很快会失效。建议将规则配置纳入版本库，并在Pull Request阶段接入静态分析工具。对于P0规则，CI流水线应直接失败并阻止合并；P1规则可以在PR中自动评论并要求修复，但可以先不阻断，给团队一定的缓冲；P2和P3只生成提示或创建工单，避免开发人员被噪声淹没。
下面是一个简化的CI配置示例，语义是扫描结果中出现P0或P1漏洞时相应处理：
security_scan:
stage: test
script:
- semgrep --config security-rules.yml --json > scan.json
- python check_severity.py scan.json
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
# check_severity.py 中的简化判断
# P0 时返回exit 1阻断合并
# P1 时返回exit 0但自动评论要求修复
# P2、P3 仅记录
人工Review的重心也应该随之改变。机器已经负责P0和大部分P1的模式匹配，人工审查应该聚焦在权限链路是否完整、状态机是否可越权、加密逻辑是否自研、敏感数据是否脱敏等业务强相关问题上。不要在PR里重复检查SQL拼接，因为工具已经拦住；但要看一个用户是否能通过修改ID访问另一个用户的数据，这类越权问题通常需要结合业务才能判断。
五、持续运营与误报治理
规则库落地后第一周最常见的反馈是误报太多。需要建立反馈通道，让开发人员可以标记误报或建议调整规则。对于每条被标记的误报，安全负责人应定期复查，并修正规则模式或优先级。误报长期不处理会降低规则库可信度，最终开发团队会绕过检查或直接忽略告警。
同时建议每月统计漏洞逃逸率、告警噪声率和Review平均耗时。如果P0漏洞仍然在线上逃逸，说明规则库没有覆盖对应漏洞类型或工具接入不完整；如果噪声率高，说明规则粒度太粗，需要拆分或增加上下文条件。只有把规则库当作持续运营的产品，而不是一次性文档，才能长期降低严重Bug漏报率。