别只靠 checklist 补安全：把安全做进脚手架的"默认值"能推多深？

先说背景。做了 5 年安全加固，我复盘过不少团队的现状：安全做得好不好，几乎完全取决于"有没有人记得去做"。checklist 列得再全，也架不住赶上线时"这条先跳过，下个月补"；review 做得再细，也架不住换了个新人、换了个仓库就失效。我越来越觉得，靠"事后补 + 靠人记性"的安全加固，本质上是在跟熵做斗争，长期必然败。

所以想抛一个开放问题：与其事后打补丁，不如把安全做进脚手架、模板、框架的"默认值"里（secure by default），让人"不做也对"。这个思路能推多深、代价是什么？

我看到社区里有三种典型做法，分歧也挺大：

• 做法 A：纯 checklist + 人工 review。 优点灵活、按需裁剪；缺点是强依赖人的自觉，人员流动/仓库增多就崩。
• 做法 B：脚手架/项目模板内建默认安全。 新服务直接带上默认 TLS、日志脱敏、最小权限、依赖基线，开箱即安全。好处是可复制、不依赖个人；代价是模板要有人长期维护，默认值一旦"一刀切"就可能误伤特殊场景。
• 做法 C：框架/中间件层强制默认。 比如默认开 mTLS、默认拒绝跨域、默认密钥不落明文、默认最小权限。最彻底，但也最难推——谁有权定默认值？默认错了谁来兜底？

真正的分歧点，我认为是这三件事：

1. "默认安全"会不会变成"默认过度"？ 强制的默认值牺牲了灵活性和启动速度，某些场景（如内网调试、性能敏感链路）确实需要"关掉默认"，可一旦能关，就等于没强制。
2. 谁来维护默认值？ 模板/框架默认值是有寿命的，CVE 在演进、基线在变，没人维护的"默认安全"会变成"默认陈旧"，反而制造虚假安全感。
3. 边界在哪？ 哪些该做成"不可绕过的默认"，哪些该留给 checklist 人工决策？

我的倾向（仅供参考，想听大家不同场景的选择）：

• 分层处理——把"不可协商底线"（如密钥不落明文、默认最小权限、高危依赖阻断）做成工具链/框架层不可绕过的默认；把"可选增强"（如字段级加密、更细的审计）留给 checklist 和人工决策。
• 默认值要"可观测"——默认安全不能是黑盒，得能在审计里看到"哪个服务靠默认值满足了哪条基线"，否则一旦默认值本身出洞，你根本不知道波及面。
• 宁可默认偏严 + 显式豁免，也不要默认偏松 + 事后补——"显式豁免"留下了决策记录，"事后补"往往就没下文了。

想听听大家的真实经验：

• 你们团队里，哪些安全项已经做成了"默认值"、哪些还停在 checklist？
• 有没有"默认安全"反被特殊场景坑到的案例（比如内网、性能、调试）？
• 你们是怎么处理"默认值谁来维护、多久更新一次"的？

欢迎拿具体场景来聊，别泛泛谈理念。