[译苑雅集Vol. 48]为什么安全部门不是“否决部”：重新定义CISO的角色与未来路径
安全从来不是企业增长的障碍，也不是“部门的否决者”。本文系统拆解了安全与业务的真实关系，解释为何可见性、影响力、故事力和行为心理学将成为未来安全领导者的核心能力——尤其是在AI快速渗透的当下。
作者：Ross Haleliuk
时间：2025年06月04日
原文：
几乎每周我都会听到有人说，安全部门不能再当“否定之人”（Department of No），而是要成为“业务赋能者”（business enabler）。每次听到这种说法，我都忍不住想：这个观点到底是从哪来的？它又是怎么变得如此流行的？这篇文章里，我会解释：为什么安全从来不是、现在也不是、将来也不会是“否定之人”，它真正的角色是什么，以及未来可能会走向何方。
商业的本质就是在承担风险
在讨论安全之前，先要明确安全是在什么样的背景下运作的。为此，我们必须从商业的基本逻辑讲起。我知道政府、非营利组织和其他机构也需要安全保障，但由于安全行业主要还是围绕私营企业展开的，所以我们就以“商业公司”为背景来讨论。
毫不意外，商业的本质是“承担风险”。创始人把全部积蓄投在未经验证的想法上；投资人把有限合伙人的钱赌在前途未卜的市场上；整个行业都可能围绕一个最终可能失败的愿景在运转。公司从第一天起就面临着生死考验：想法可能不被市场接受；产品可能根本做不出来；做出来了可能不符合市场需求；市场可能根本不存在；竞争对手可能执行力更强；税收或贸易政策可能一夜之间变动让商业模式难以为继……潜在问题多得数不过来，而且高度依赖所处的环境，根本无法列出一个标准清单。
重要的是，对于任何公司来说，“活下来”不是默认状态，而是靠在业务各方面不断下注、算计、试错才换来的。无论你是初创公司还是市值数百亿的大企业，这一点都不会改变。看看 Kodak、Xerox、BlackBerry、Motorola、Yahoo、Enron、Compaq 的下场就明白了：任何公司都可能失败，而且失败的理由五花八门。
而在这一大堆风险中，安全风险只是其中一个维度。虽然它可能很严重，但通常并不会上升到“必须停下一切”的级别，除非真的“着火了”。回顾过去 100 年的商业史可以看出，安全问题的影响更多是财务层面，而非生死存亡层面。公司真正“死掉”的原因是：进入市场太早或太晚、增长过慢或过快、产品与市场脱节、内部政治斗争，等等——而不是安全问题。甚至可以说，安全事故更像是一种“滞后指标”，反映出的是文化问题、决策混乱或缺乏执行力。Adrian Sanabria 一直在统计因安全事故而直接倒闭的公司，到目前为止全球还不到 30 家，远远低于大众的直觉预期。
既然商业本质是不断冒险，那就不难理解：大多数公司并不把安全风险列为首要考虑因素。他们不会因为一个潜在的安全隐患，就推迟产品发布、延后关键功能上线、或者主动牺牲业务增长节奏。毕竟，如果一个公司能挺过产品风险、市场风险、竞争风险、执行风险和监管风险，它大概率也不会死在“安全流程太繁琐”这座山上，尤其当安全摩擦会拖慢增长的时候。
在大多数公司，安全部门根本不是“否决部”
这就引出了本文的核心主题：安全部门并不是所谓的“否决部”（Department of No）。要理解为什么这种说法会流行，我们得看看安全部门在什么时候有权说“不”，更重要的是，它在哪些关键时刻没有权力说“不”。这两者之间的反差，才揭示了安全在公司内部真实的权力结构。
安全通常活跃在边缘场景，比如：禁止对生产环境使用 SSH 登录、屏蔽一些有风险的浏览器插件、强制执行多因素认证（MFA）、或者标记轻微的合规违规行为。这些操作确实有意义，能帮公司避免一些最常见、最明显的攻击路径。但即便这些行为让安全团队有一种“我们掌控局面”的感觉，它们其实并不代表安全部门拥有巨大权力。
安全部门之所以能在这些领域“硬气”，是因为对业务的实际影响很小。这些都是“安全地带”：不影响收入，不影响产品上线，不影响大客户谈判，不影响整体业务节奏。换句话说，这些决策不会显著拖慢公司赚钱的速度。正是在这些有限场景里，“安全是闸门守卫”的神话得以延续。
但一旦影响升到关键层级，这幅图就完全变了：如果安全措施有可能影响关键功能上线时间、季度营收目标、或重要合作伙伴的集成交付，那安全部门基本就没资格说“不”了。
真正重大战略决策，掌握在产品、工程、市场和高管团队手里。在这些会议室里，安全充其量是个顾问，而不是有否决权的核心决策者。
所以，当人们说“安全要成为业务赋能者”时，其实他们的潜台词是：安全本来就没有权力去阻止业务做想做的事，只能在事后尽力为这些已定的路径打补丁、兜底风险——在既有的预算范围内，把事情尽量做得安全一些。
在极少数公司里，安全可以是“否决部”（但它本质上仍然不是）
虽然在大多数公司里，安全部门没有足够的权力配得上“否决部”这个称号，但确实有一些特殊场景例外。我们说的是那种安全或合规本身就是“生死级”风险的公司。
要让安全成为生死风险，公司得是攻击者的首要目标。最典型的例子就是头部加密货币交易所，例如 Coinbase 和 Binance，这些平台在黑客眼中价值巨大，和美国顶级银行属于同一级别的攻击目标。在这类公司中，安全确实拥有极大的权力，可以主导产品路线图、推迟关键功能或产品上线，甚至决定是否允许第三方集成他们的系统。
但矛盾的是，这些公司里的安全负责人反而最少滥用这份权力。他们的 CISO 往往是技术能力很强、又懂业务的高管，把安全当作产品和工程问题来处理，而不是当作“执法”来做。
第二类例外，是那些合规风险属于生死级别的公司。在高度监管的行业，比如医疗和金融，安全的角色跟“能不能向审计员和监管机构交差”高度相关。在这些公司里，衡量安全团队是否成功的标准是：审计能不能过、认证能不能保住、监管罚款能不能避免。
在这种环境下，安全确实有比较大的发言权（包括说“No”的权力），但这个权力往往是跟法务和合规团队共同分享的。
不管是哪一种例外情况，这类公司在整体企业群体中仍是极少数。所以我认为，可以很有把握地说：在绝大多数公司里，安全部门不是“否决部”。
可见性，是安全团队唯一能完全掌控的领域
尽管安全团队的职责是保护整个组织，但现实是：他们几乎无法真正控制自己应该保护的那些系统。安全团队通常不负责 IT 或基础设施，不执行身份与权限管理，不运营 CI/CD 流水线，也不管理产品路线图。他们无法调配预算，无法设定工程优先级，更无法影响谁能升职。换句话说，安全团队被要求在自己无法掌控的领域里达成结果，这让他们承担了巨大的责任，却没有实权。
这种权责失衡带来了真实的紧张关系。CISO 想推动变更，手里唯一的工具就是制定政策，而别人唯一愿意认真听的理由通常只有一个：合规。如果某项工作不是合规要求的一部分，那你基本很难让它真正落地。
最终就形成了这样一种局面：安全团队要保护一个自己无法控制的环境，他们的任务是找出哪些地方有问题，再去说服那些并不想“额外加班”的人做出改动。
当安全部门缺乏阻止风险被引入系统的权力时，它的角色自然会退化为两个方向：
提供对风险的可见性；
向业务讲清楚这些风险意味着什么。
这并不是安全团队的失败，而是现实的直接结果——当安全介入时，很多重要决策已经被做完了。在这种情况下，“提供可见性”就成了保底方案：如果安全无法改变方向，至少可以识别出风险，并把后果呈现出来。哪怕没人采纳，至少做到了“看见问题”。
可见性成为安全团队核心职能，本质上反映的是这个角色本身的复杂性。现在的安全团队要应对的是高速变化的产品路线图、分布式架构，以及不断增加的监管压力，而资源和权力都极其有限。在这种环境下，大多数组织中，安全唯一能做到的就是：尽量看清楚问题在哪。
对那些技术驱动、愿意在“主动防控”上投入更多的公司来说，情况可能稍好，但对绝大多数企业来说，安全工作的终点就是“风险可见性”。
问题是，如果没有改变现状的权力，很多安全团队就陷入了一个“扫描—派单”循环：
扫描系统 → 发现问题 → 建一个 Jira 工单 → 派给其他团队 → 结果可能被修，也可能被忽略。
需要强调的是：止步于可见性，并不是懒惰，也不是不负责任，而是一种应对机制。它让安全团队能持续参与、不成为业务的“绊脚石”；它能留下尽职记录，表明“我们尽力了”；它让安全团队继续保持在流程里，哪怕实际影响不大。
但这种方式，最终往往不是降低风险，而是风险递延：
Jira 工单就成了最终交付物，任务移交就被当作结案，而真正的解决动作（修补漏洞、修改配置、发布更新）很可能被无限期搁置。
意图是好的，努力也是真的，但结果往往与风险的紧迫性不匹配。安全团队的参与程度刚好够“避免被追责”，却未必足以改变结局。
这不是对安全团队的批评，而是对整个系统运行机制的揭示。
正如我最近在 LinkedIn 上说的那样：
“网络安全领域最大的秘密是：大多数安全事故并不是技术失败，而是业务决策。公司知道他们的身份系统很复杂，第三方接入泛滥，云环境配置一团糟——但修复这些问题太麻烦、太贵、或政治风险太高。于是他们选择接受风险，抱着侥幸心理，然后多买几个工具‘监控问题’，而不是真正去解决它。某种意义上，很多安全事故不只是可预测的，甚至是可以计算预算的。”
可见性确实有价值，但只有当它与影响力、跨团队协作、和管理层支持结合起来时才真正有意义。
安全的角色不该只是指出问题，更应该有权推动解决方案落地。
但在那一天到来之前，即便是最优秀的安全团队，也只能一手被绑着努力前行——尽最大努力把风险讲清楚，但却无力阻止风险真正落地。
成功的初创公司，其实反映的是当下安全行业的真实生态
面向 CISO 和安全团队卖产品的初创公司
如果你回顾过去几年那些在安全圈里获得市场关注、销售成功的初创公司，会发现它们大多数属于以下三类之一：
帮助公司合规、维持业务正常运行（如合规自动化）；
识别并应对生死级威胁（如勒索软件、能上新闻头条的攻击）；
提供全面的可见性（比如各种态势管理工具，能扫出一堆待办事项，大部分永远没人做）。
一旦某个安全工具会带来哪怕一点点“摩擦”，哪怕它能大幅提升安全性，也往往难以获得增长。
一个防止配置错误的工具，永远不如一个“可视化配置错误”的工具更受欢迎——即便从纯粹安全角度看，“预防”显然更有价值。
问题在于：预防，等于给了安全团队“说不”的工具。这正是很多安全人梦寐以求的事，但现实是，他们很少真正拥有足够的权力去执行“预防”措施。
这也就是为什么创业者在找 CISO 验证 idea 时要特别小心：CISO 觉得“好”的方案，和他们有权实际落地的方案，往往不是同一个。
一个工具如果会导致开发者错过产品上线、财报发布节奏等关键时间点，它大概率活不下来。
但如果一个工具允许开发者在必要时“跳过安全警报”，则可能获得市场生存机会。
我希望整个行业能开始从“只关注可见性”逐步走向“推动可执行的行动”。但这不只是靠创业者来完成（创业者并不是瓶颈），更需要：
安全负责人在企业内部有足够的影响力，能够不仅推动产品上线，还能帮助初创公司不断迭代和成熟。
正如之前的云计算、移动端、SaaS 等等，AI 正在迅速被集成进各种产品、业务流程、甚至商业模式——通常都没有清晰的安全策略。
为了快速落地、抢占价值、保持竞争力，安全团队又一次被动地去补救已经做出的决策。
AI 安全大概率也会走和历史上其他技术类似的路线图：
从治理和合规开始：确保满足新出台的监管要求；
然后进入态势管理阶段：识别 AI 系统当前存在的风险；
接着，等我们理解黑客如何攻击 AI 后，会出现检测和响应类产品；
最后，才会有人提出“预防”类愿景。
但在出现足够多的“头条级事故”之前，比如“因为 AI 缺乏控制，某公司损失数千万”，我们大概率只会听到很多关于 AI 安全重要性的讨论，而不会看到相应的实际投资。
面向“被安全团队甩锅”的执行团队卖产品的初创公司
安全市场的另一个新趋势是：有些初创公司不是把“安全成果”卖给安全团队，而是围绕安全提供“赋能工具”，卖给其他执行团队。这些公司看清了一个越来越明显的现实：
安全团队能识别风险，但没有资源、专业能力或权限去修复这些风险。
最终工作会被“甩锅”到开发、平台工程、DevOps 或 IT 团队那里，而真正的摩擦也正好出现在这些下游环节。
这些初创公司没有去给 CISO 推仪表盘或策略引擎，而是聚焦于让“真正要动手的人”活得更轻松。
Chainguard 就是这个趋势的典型代表。虽然很多 CISO 对它拍手叫好，但 Chainguard 真正卖的不是给他们。它卖的是给那些负责打补丁、维护和加固容器的工程团队——也就是那些经常被安全团队派工单要求“去处理一下”的人。
Chainguard 通过抽象掉一些痛苦的任务（比如构建安全的容器镜像），把原本麻烦的安全工作转化为“已经解决的问题”，交给真正负责实现的人。
这种模式之所以有效，是因为它让利益相关方的目标一致：
开发者并不是不在乎安全，他们只是不想被安全拖慢节奏，也不想被迫处理额外复杂的问题。
工程师对“风险可见性”没兴趣，但如果有工具能让他们不用再做安全团队让他们做的那些事，他们会非常开心。
所以在面对开发者销售时，真正能跑起来的产品，不是那些强调“我们能提升安全性”的工具，而是那些能减少安全摩擦、简化流程甚至让问题自动消失的工具。
为什么我觉得安全工作很像人力资源（HR）
从很多方面来看，安全团队让我联想到人力资源（HR）。这种对比不只是因为它们都被看作是“否决部门”，还远不止于此。
HR 是一个非常关键、极具价值且潜力巨大的职能。如果运用得当，它完全可以成为一家企业在盈利能力和长期发展上的关键杠杆。但现实是，大多数公司根本没有真正挖掘出 HR 的潜能。相反，HR 通常被当作“风险防火墙”：负责完成合规打勾、通过审计、降低法律风险。HR 的深层战略价值常常被忽略。
要改变这种局面，需要的是一个真正懂业务、愿意破局的领导者。这个人不把 HR 视为只负责制定没人会读的政策，或发没人在意的年度员工调查；而是把它视为推动信任与增长的引擎。
一旦你意识到这个类比，你就再也回不去了。就像 HR 一样，安全团队也经常在出事之后才被拉进来——不管是为了救火，还是为了执行某项政策。就像 HR 无法直接控制员工行为一样，安全团队也不能控制人们点不点钓鱼链接、设不设置强密码。他们能做的只有教育、引导、影响。
尽管如此，这两个角色都经常要为自己无法控制的结果“背锅”：HR 负责人可能会因为某员工的不当行为被炒掉，CISO 可能会因为一起社工攻击事件被问责，哪怕他们之前做对了所有的培训和防护。
这是一个有缺陷但又普遍存在的逻辑：我们要求 HR 和安全去“防止失败”，却不给他们控制失败根源的手段。
你可以建立很棒的公司文化，也可以推动非常强的安全意识培训，但只要出现一个行为恶劣的人，或一个操作失误的瞬间，一切都可能瞬间崩塌。而最终承担后果的，往往是那些被要求“防止无法防止之事”的人。
无论是 HR 还是安全，当他们被提前纳入战略讨论、而不是事后被动处理问题时，才会真正发挥出价值。可惜的是，在大多数公司里，这两个部门常常被当作成本中心和被动角色，直到有事发生。
当人力资源的员工走到你工位前时，很少有人感到开心——因为在一切正常运转的时候，HR 是“隐形的”。
安全团队也一样。
如果你曾在一家真正高效的公司待过，你就知道：当一个真正强大的人才与文化负责人把工作做好时，团队会像被施了魔法一样运转。
安全也是如此：当一个真正有领导力的安全负责人获得了公司“核心一席之地”时，所带来的影响是巨大的——
安全从“被动应对”转向“战略协同”，从“业务阻碍”转化为“业务加速器”，这就是“魔法时刻”的到来。
展望未来：改变安全的思维方式
当我思考安全行业和 CISO 职责的未来时，我非常清楚一点：接下来的路，必须建立在“无授权影响力（influence without authority）”这个理念之上。
这个概念并不新——每一个产品经理在职业生涯早期就会接触并学会它。作为一名 PM，多年来我必须设定方向并推动执行，但与我合作的人几乎都不向我汇报。产品经理能否成功，取决于是否能赢得信任、建立关系、让其他人愿意主动做“正确的事”，而不是靠权威命令对方去做（虽然有时候我确实希望是那样，但现实不是）。
如果“无授权影响力”对产品经理有效，我看不出为什么它对安全领导者就行不通。事实上，我一直很惊讶，这种简单而有力的方法还没有成为“安全领导力101”课程，在所有安全从业者、管理者和高管入行的第一天就开始传授。
我认为一个根本问题在于：很多安全人被“写政策文档”的技能误导了，他们以为只要把一项安全要求写进文档、并从上往下强制执行，就能实现持久变革。但现实中，根本不是这么运作的。
如果安全团队真的想带来长期改变、让企业更安全，他们需要：
花时间建立关系、赢得信任，
设法帮助公司实现业务目标，
持续不断地宣传和推广安全理念。
写文档本身，远远不够。
对安全从业者来说，还有两个关键技能是过去被忽视、但现在越来越重要的：
讲故事的能力（Storytelling）
行为心理学 / 决策科学（Behavioral Psychology / Decision Science）
这些技能传统上和安全没什么关系，但现在正变得不可或缺。有趣的是：它们从来就是优秀产品负责人成功的核心能力。
就像产品经理必须说服高管接受他们的产品路线图、从而争取资源一样，安全负责人也必须用有说服力的方式，让公司在“速度 vs 风险”的拉扯中优先考虑风险缓解。
讲故事，在产品和安全两个角色中都极为关键。尽管大家都在谈“数据驱动决策”，但现实中，人们很少真的只靠数据做决定。真正能打动团队、管理层和董事会的，是故事——那些能把问题讲得贴近现实、紧迫且具象的叙述方式。
无论在产品还是安全领域，最终赢得支持的，永远是那些能引发共鸣的想法，能让人看清风险、理解收益、或者想象未来路径。
一段讲得好的故事，远比一张表格或一个风险登记表更有凝聚力。
我们现在谈论很多事情：
安全要尽早嵌入开发流程、
用“铺好路”代替“设置闸门”、
自动化风险控制、
成为业务的赋能者……
但在做这些之前，我认为安全行业最需要学会的是三件事：
如何在没有权力的情况下影响他人；
如何讲出能打动人的故事；
如何理解人类是如何做决策的。