安全加固清单：哪些是"非协商底线"，哪些可以分阶段补？

先说背景：做了 5 年安全，我发现一个特别普遍的纠结——安全加固清单列出来总是几十项，从 TLS 版本、密钥轮换、日志脱敏，到默认账号清理、依赖漏洞扫描、限流熔断，每一项单看都对，可业务排期就那么多。于是经常看到两种极端：一种是"全都要，全都要，上线先等等"，最后项目黄了；另一种是"先上线再说，加固排到下季度"，结果真出了事才追悔莫及。

打个比方：这就像装修房子。你不可能要求每面墙都同时刷完漆、装好插座、贴好瓷砖才能住，但你也不可能把承重墙拆了先住进去、回头再补。问题不在"做不做"，而在"哪些是承重墙，哪些是软装"。

我观察下来，常见的分歧大概有这么几种做法：

做法一：一视同仁，全量加固。 安全团队给一份 50 项 checklist，业务方照着一条一条做。优点是简单、不漏；缺点是耗时极长，且很多项（比如"日志保留 180 天"）和"默认 admin 密码没改"根本不是一个风险等级，混在一起反而稀释了真正要命的问题。

做法二：按风险等级分层。 把加固项分成 P0（不修就裸奔，如弱口令、明文密钥、未授权接口）、P1（有明确攻击路径，如依赖高危 CVE、缺少限流）、P2（纵深防御，如日志脱敏、审计完善）。P0 上线前必须清零，P1 一周内补，P2 排进迭代。这个思路我比较认同，但落地时大家往往对"怎么定等级"吵半天。

做法三：只盯"攻击面"，不盯"合规项"。 只关心"攻击者能不能从外网打进来"，内部治理、合规审计之类一概后置。短期见效快，但容易漏掉供应链、内部威胁这些慢变量。

我自己的倾向是做法二，再加一条原则：P0 的判定标准不是"专家觉得重要"，而是"假设明天就有人攻击，这条不修会不会直接被打穿"。用这个标准筛，大部分 P0 项其实就三五个：默认凭据、明文存储的密钥、未授权的高危接口、未修补的已知 RCE。剩下的都可以谈。

但我也很想知道大家实际是怎么选的：

1. 你所在团队的安全加固，是"一票否决"（P0 不过就不让上线）还是"风险签认"（业务方签字承担风险就能上）？签认制真的管用吗，还是走个形式？
2. 有没有遇到过"加固项之间互相打架"的情况？比如只读文件系统加固后 Java 服务崩了（我看到站里有人问过这个），最后是怎么妥协的？
3. 如果是你给一个 3 人小团队做安全基线，只能挑 5 项，你会挑哪 5 项？为什么？

欢迎把你们的"承重墙"清单和踩过的坑都聊聊，这个话题我估计能吵出很多干货。