二十多年前，Nelson Repenning 和 John Sterman 在 IEEE《Engineering Management Review》上发表了一篇文章——《没人会因为解决了“没发生的问题”而被认可：如何打造并维持流程改进》。读完你就会发现，安全行业并不是独自面对这些难题；相反，我们往往会把其他行业共有的挑战放大，加上行业特有的复杂性，让事情变得更难处理。
这篇文章里，我聚焦其中最贴近安全领域的关键观点。首先，也是最核心的一点：没人会因为阻止了一场“没发生的安全事故”而得到赞赏。 这一现实对安全团队和创业者影响深远，它基本决定了哪些安全项目（或产品）从一开始就注定困难重重。
而这也解释了许多现象：
为什么我们更容易责怪“人”而不是“流程”；
为什么大家习惯用更努力代替更聪明的方式；
为什么我们明知捷径的长期危害，却仍然一次次选择它。
这是安全行业的结构性困境，也是我们不断循环的根源。
“更努力” vs. “更聪明”
IEEE 那篇文章的作者 Nelson 和 John，用非常直白的方式解释了为什么安全团队——和很多职能一样——会陷入永无止境的救火循环。
逻辑并不复杂：安全团队整天忙着处理事故、工单、告警——这些每天都在吞噬精力的活儿。火到处在烧，任务堆到天花板，团队永远没有空余时间去做更战略、更根本的建设。因为长期被这些重复、低价值的事务拖住，团队始终无法投入资源去做基础卫生、架构改造、韧性建设。结果就是一个恶性循环：救火越多，系统越脆弱；系统越脆弱，就越得救火才能维持不崩盘。
Nelson 和 John 指出核心原因：“更努力”能带来立竿见影的效果。
你投入越多时间和精力，短期结果确实更好；而且改善是即时可见、容易衡量的。但问题是：这种收益非常短暂。你投入得越多，真正用于改进流程的时间越少，团队的能力就会悄悄下降，最后走到一个靠“更努力”已经无法拉回来局面的临界点。
这就是他们说的“先好后坏（better before worse）”。
“更聪明”则相反。
当团队决定优先推进一些更大规模的改进计划——比如架构重构、流程重建或整体成熟度提升——短期来看，效率一定下降。大家被这些改进分散了注意力，日常任务必然会放慢。这就是“先坏后好（worse before better）”。
但随着时间推移，能力和成熟度的大幅提升不仅弥补了短期损失，还会让安全团队真正跑得更快、更稳、更高效。
现实中我们天天能看到这种情况：
资产盘点、IAM 重构、网络分区重设计、架构文档化、Zero Trust 改造……一开始都让事情变慢，也很难马上看到“减少事件”的效果。
但正是这些基础工程，最终赋予安全团队真正的“超能力”：
长期更强、效率更高、成本更低、韧性更好。
问题在于——大多数人无法接受“先变慢”的焦虑。
于是他们更愿意投向那些“马上见效”的动作，即使这些动作长期来看效果更差。
这就是为什么我们总是在重复同样的圈。
捷径，是好安全的天敌
真正毁掉安全的，不只是业务团队走的捷径，安全团队自己走的捷径，同样杀伤巨大。
当安全团队被逼着“更快、更少资源做更多”，唯一能牺牲的，就是那些“不紧急但重要”的事：改进项目、文档、维护、根因分析。这在短期内似乎说得通——少做这些“看不见产出”的事，就能在其他领域推进更多日常工作。
但长期代价惊人。
跳过威胁建模、不完全打补丁、忽视 IaC 配置风险、不清理 IAM 例外、延后基础工程……这些不可见的风险会悄悄累积，最终以灾难性的方式爆炸。
文章作者这样解释这个现象（核心意思提炼如下）：
捷径之所以诱人，是因为“后果延迟”。
当你偷工减料时，短期往往是“无痛”的。
主管延后预防性维护，短期享受“产出更高、成本更低”；
但设备老化后，停机、故障、成本才开始反噬。
软件工程师为了赶进度不写文档，短期看不见问题；
直到几周或几个月后回头修 bug，才意识到自己挖的坑有多深。
安全亦如此。
捷径让你先爽，后苦；安全让你先苦，后稳。
但在短期压力驱动下，人类的本能永远是选择前者。
归因偏差：安全行业的放大器
安全行业几乎是“基本归因错误”（fundamental attribution error）的教科书级例子。文章作者是这样解释这个心理机制的：当你面对业绩不达标，你通常会认为问题要么来自“人”（不够努力、不够自律）、要么来自“系统能力不足”（流程差、工具差、架构差）。但人类的大脑有几个天然偏好：
认为因果必须发生在时间上和空间上都非常接近；
习惯把问题归为单一原因；
低估延迟；
忽视系统中的反馈循环。
于是，当主管看到某位机器操作员产出了异常高的次品率，最直观的判断就是“你干得不好”。因为这个员工与“次品”在时间和空间上最近，也最容易被联想到“原因”。而真正的原因，可能是几周前的培训不到位、数月前的维护流程不完善、或是年初就积累的系统性问题。它们隐藏得更深、发生得更早，因此很少被看到。
安全领域每天都在上演同样的戏码。
安全部门喜欢归咎用户：“用户不懂安全、不看政策、爱乱点链接。”
而忽略了系统本身的问题：流程过载、体验糟糕、治理混乱、环境复杂导致“错误是必然结果”。
公司高层喜欢归咎安全团队：“安全做得不好、团队不够强。”
而不承认真正的系统性根源：多年技术债、长期缺乏投入、架构复杂性失控、操作全靠手工。
这是典型的“看得见的人被归因，看不见的系统被忽略”。
而安全行业的复杂性、延迟效应、反馈链条，都让这种归因偏差更加严重。最终，问题不断重复，而真正的系统性原因却从未被正面处理。
救火循环，会催生英雄文化
安全团队长期陷在救火模式里，只有极少数团队能争取到一点空间，把重点放在“更聪明而不是更努力”的长期建设上。这种结构性困境会带来非常严重的后果。
当一个组织越来越依赖救火、依赖“更努力”来弥补流程能力不足时，那些靠英雄式冲刺把项目救回来的人，会被奖励、被提拔。
组织自然开始奖励最后一刻的奇迹，而不是那些真正能避免危机的学习、培训和改进。
正如某位工程师说的：
“没有人会因为解决了一个‘没发生的问题’而得到认可。”
时间久了，高层会被这些“战斗英雄”占据，他们也更愿意提拔与自己类似、同样能“硬扛”的人。某项目负责人也承认：“我们公司奖励英雄文化。我能走到今天，就是因为我能在压力最大的时刻硬着头皮把事情交付出来，而这也正是公司奖励的能力。”
读到这里你会发现：虽然安全不是唯一一个争不到时间做改进的行业，但绝对是这一现象的典型代表。
现实中，很少有安全团队在组织里拥有足够权力去推行预防性措施、把问题扼杀在源头。
预防意味着摩擦。
所以不仅“没人会因为避免事故而获奖”，更现实的是：没人有资本在组织里引入摩擦。
在缺乏权力、资源和支持的环境里，安全团队陷入英雄文化几乎是不可避免的。
也很难责怪任何人：大多数安全从业者都在有限支持下尽最大努力。
如果你对安全行业里的英雄文化感兴趣，可以去读我和 Kymberlee Price 的那篇文章《网络安全的英雄文化：起源、影响，以及为什么必须打破这个循环》。
剧透一下——今天仍然完全适用。
把所有线索汇总在一起
Venture in Security 的读者 Michael A. Davis 曾在我另一篇文章下面留下过一条评论，把我这篇讨论的核心，用一句话讲得比我更透。他写道：
“如果这些现象不仅存在于网络安全，而是所有组织在‘预防 vs. 反应’上的通病呢？制造业（质量控制）、医疗（预防医学）、基建（维护 vs. 故障抢修）里，都有一样的动态。
整体模式大概是这样：
1.组织被困在救火模式里，因为救火是可见的，也是被奖励的。
2.先行者试图让整个组织相信，应该为‘明天的问题’投入资源，而当下的团队已经在今天的危机里喘不过气。
3.只有外部冲击，例如重大安全事故或强制合规要求，才能逼组织跳出这个循环。
4.第二批进入者赶到时，市场已经从‘理论风险’转向‘紧急需求’。”
这总结得非常准。我只想补充一点：
历史上，预防型安全产品确实比检测与响应（也就是“救火”）类产品更难获得认可，但过去几年，预防端的势头正在变强。
我们不仅看到新一代的预防类创业公司出现，比如 BforeAI、Aryon、R6 Security，连 Gartner 都开始正式提出“预防式安全（preemptive cybersecurity）”的概念。能不能真正克服组织在预防领域的惯性还有待观察，但通常当大量聪明、固执的人一起押注某件事时，往往说明方向是对的。
这并不仅仅是为了给 Gartner 多造一个“预防安全”的新分类。
更重要的是：
让安全团队获得正当性与授权，去优先选择“更聪明地工作”，而不是无休止地救火。
让他们能提前规划、提前治理、提前消减风险，
找到时间去做那些每个安全团队都想做、但从来挤不出时间的大规模工程——
资产卫生、架构治理、流程现代化、基础能力提升。
这本质上关乎安全的“卫生观”和“预防心态”，
远远超越具体产品或技术类别。
面向未来
距离 Nelson Repenning 和 John Sterman 发表那篇文章已经过去 20 多年了。他们当时指出：没人会因为解决了那些“本来没有发生的问题”而获得认可。他们讨论的是企业在整体决策层面的行为方式。虽然文章本身与安全无关，但我们这个行业往往放大了其他商业领域中早已存在的问题。
在未来的几年里，我希望越来越多的安全领导者能够获得足够的信任与组织内部的政治资本，从而主张并推动“更聪明地工作”这一理念。我见过太多试图做正确事情的 CISO，却受困于内部阻力与现实掣肘，这也让我不得不保持乐观，相信情况终会改善。
我同样期待在未来看到更多的新创企业，能够真正重构老问题、探索现代化解决方案，而不是只是把我们过去那些低效的方式自动化、流程化。正如 Tomer Weingarten 在我们最近一期 Inside the Network 节目中所描述的那样：行业长期存在的最大挑战，是思维局限于增量式改进。
我们整个行业都应当、也完全有能力做得更好。
我对此深信不疑。
原文链接：
https://ventureinsecurity.net/p/nobody-ever-gets-credit-for-fixing
声明：本文来自安全喵喵站，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
