背景
我最近在做一次安全加固复盘，翻了过去半年的 WAF + SIEM 告警日志，一个数据让我很头疼：12,400 条告警里，人工确认是真实攻击的只有 87 条（0.7%）。安全运营同学已经出现了"告警疲劳"——凌晨 3 点收到第 40 条"SQL 注入尝试"，大概率是爬虫，直接忽略了。
但更让我担心的是：那 87 条真实攻击里，有 3 条是被埋在 200 条误报中间、差点被一起忽略的。如果那天值班的人更"麻木"一点，后果会怎样？
这就是我想抛出来的争点：安全告警的信噪比，到底该往哪个方向调？删规则（降噪）和加规则（提召回），哪个方向的风险更大？
常见分歧（我见过的三种做法）
做法 A：激进降噪派。 "误报就是噪音，删！"把触发阈值调高、把误报多的规则直接下线。好处是团队不会疲劳，真正的高危告警能被人认真对待。风险是：你删掉的那条规则，可能就是 3 个月后那个真实攻击的最后一道防线。安全告警的"删"是不可逆的——你删了，就不知道自己"不知道了什么"。
做法 B：全量保留 + 自动分级派。 所有规则都留着，但引入自动化分级：低风险自动归档不推送，中风险进日报，高风险才推实时告警。好处是不丢规则。风险是分级模型本身需要训练，而训练数据就是历史告警——如果历史告警里 99% 是误报，模型会学会"大部分都不重要"，真实攻击被降级成"中风险"的概率不低。
做法 C：场景化白名单派。 不删规则，但针对已知的安全流量（比如内部压测、安全扫描、CDN 回源）加白名单，把"确定性误报"过滤掉，保留"不确定性告警"。好处是误报降了但规则还在。风险是白名单本身成了新的攻击面——攻击者发现你的白名单规则后，可以伪造"安全扫描"特征来绕过。
我的倾向
我倾向于做法 C 的变体，但加一个硬约束：白名单必须带 TTL（有效期），且每次白名单命中都要留审计日志。
理由：
- 删规则是"减法"，加白名单是"标注"。删了你就不知道这条规则曾经拦过什么；标注了，你随时可以回看"这条白名单在过去 30 天命中了多少次、命中了什么"。
- TTL 是防"白名单腐烂"的关键。很多白名单是"当时为了解决一个误报加的"，但业务场景变了（比如压测下线了、CDN 切换了），白名单还在，就成了一个永久的绕过通道。
- 审计日志是"删规则"的安全网。如果你坚持要删规则（做法 A），至少把规则保留在"影子模式"——不告警、不拦截，但记录"如果这条规则还在，它会命中什么"。跑 30 天，如果影子日志里出现了真实攻击特征，再决定要不要恢复。
但我也承认，这个方案对小团队来说运维成本太高了。5 个人的团队，没有专职安全运营，维护 200 条规则的白名单 + 影子模式 + TTL，可能比误报本身还累。
想听大家在什么场景下怎么选
特别想听几个具体场景下的选择：
- 初创团队（<10 人，没有安全团队）：WAF 默认规则开了 200 条，每天 50 条告警，你删还是留？有没有"最小安全告警集"的概念？
- 中大型 SaaS（多租户）：租户 A 的正常业务行为触发了租户 B 的安全规则（比如批量 API 调用被当成 DDoS），你怎么处理这种"跨租户误报"？
- 合规驱动场景：审计要求"所有安全事件必须留痕"，但告警噪音大到没人看——你怎么向合规证明"我们确实关注了"？
- 你见过最离谱的误报来源是什么？（我见过 CDN 回源 IP 被当成扫描器，也见过内部 CI/CD 的 health check 被当成暴力破解……）
欢迎从你的实际场景出发，哪怕是"我们直接不管告警"也是一种真实答案。