为什么安全总是迟到：经济学、Zero-Day 与 攻击者数学
Source: Dev.to
我们都见过这些标题：又一次大规模数据泄露，又一次关键系统被攻破，又一次“我们非常重视安全”的声明。这提出了一个讽刺却关键的问题：为什么安全总是最后才被考虑？我们在网络安全上投入了数十亿美元，却总是被动应对——等房子被偷后才去买锁。这不仅是想象力或技术的缺失；更是由软件开发的经济学、复杂性的不可变法则以及攻防双方的不对称数学所驱动。
安全无法推动产品出货
商业经济迫使每个软件项目都进入与上市时间赛跑的竞争。公司专注于交付价值——解决问题、产生收入或吸引用户的功能。在这场高风险的竞争中，安全常被视为阻力而非特性。
- 缺乏演示吸引力 – 投资者对主要卖点是“今天没有被黑”的产品并不感兴趣。
- 增加复杂性 – 强身份验证、加密和输入验证会提升开发工作量，并可能降低用户体验。
- 成本‑收益谬误 – 在安全审计上花费5万美元感觉是亏损，而同等金额用于营销却被视为投资。
- 市场奖励 – 先发布的，而不是最安全的，才能赢得市场。
速度带来未知的漏洞
当速度成为主要衡量标准时，捷径不可避免，这会导致一种特定于安全的技术债务。
依赖问题
开发者高度依赖第三方库和开源包（例如 npm、pip）。一个应用的安全性只与链中最薄弱的环节一样——还记得 Log4j 事件吗？
配置漂移
为了快速上线，“够用” 的配置往往会变成永久设置。默认设置往往是为了易用性而非安全性而设计，若直接投入生产，就会为攻击者打开大门。
复杂性悖论
快速开发会增加系统的复杂度。随着组件和交互的增多，可能的攻击路径数量会呈指数级增长。每一行匆忙编写的代码都可能成为攻击者的邀请函。
防御者与攻击者不是公平的游戏
网络安全本质上是非对称的；数学并不偏向防御方。
防御者的困境
防御者必须防御未知且可能无限的威胁集合，且往往资源有限。
攻击者的优势
攻击者受益于有利的经济学：单个对手使用自动化工具扫描互联网几乎不产生成本，而防御一个系统可能需要一支高薪渗透测试团队，费用高达数十万美元。
安全总是滞后，因为防御者试图构建一堵完美的墙，而攻击者只需要一把梯子。
为什么“安全设计”在现实中很难实现
将安全左移——在软件开发生命周期（SDLC）的设计阶段就融入安全——在理论上是合理的，但实际执行起来异常困难。
- 从功能到威胁模型 – 架构师必须预判的不仅是用户行为，还有攻击者的行为。
- 从速度到审查 – 代码审查和架构分析会在一个急需加速的生态系统中引入必要的减速。
- 知识鸿沟 – 安全编码是一项专业技能，并未在所有计算机科学课程或训练营中普遍教授。
市场奖励的是“快速交付”，而不是“安全设计”。
为什么安全总是跟随失败
大多数安全支出是被动的，由失败事件触发。
零日漏洞——攻击者已知而防御者未知——在补丁可用之前就已存在。我们只能在病毒被识别后才能研发“疫苗”。这形成了一个悲剧循环：
- 新技术（物联网、云计算、人工智能）被快速构建并发布，安全被置于次要位置。
- 该技术获得广泛采用。
- 一次重大攻击成功，暴露出关键缺陷。
- 只有到那时，安全才获得所需的资金、关注和指令来“修复”问题。
这种模式反映了系统性地优先考虑即时价值而非长期稳定，而不是个别工程师的失误。
最终思考
安全并不是因为工程师粗心而迟到——它迟到是因为现实比假设移动得更快。