从事后修复到安全设计
ZDNET AI··作者 David Gewirtz
关键信息
文章区分了传统应用安全与“源头安全”方法：前者通常在发布后发现并修补漏洞，后者则 চেষ্টা在更早的开发阶段阻止缺陷产生。文章还强调，漏洞数量和工单关闭率等指标只能反映清理工作，并不能说明组织是否真的在减少重复缺陷和高风险默认配置。
资讯摘要
这篇文章主张，企业应该把应用安全重新定义为一种预防性学科，而不是发布后的清理工作。文章认为，安全必须尽早嵌入开发周期，并建立能够在漏洞和缺陷变成大问题之前就发现它们的工具与方法。传统应用安全通常是在发布后发现并修补漏洞，而“源头安全”则试图从一开始就避免这些缺陷出现。文章强调，单靠技术并不足以支撑企业级转型。要让安全设计真正落地，预防工作必须成为一种有预算、可管理、可重复的组织运营模式。
文章还指出，软件管理应从普通的部门管理问题，上升为董事会层面的关键议题，因为企业软件已经支撑客户体验、运营、身份、支付、分析和 AI 工作流等核心业务。文中提到，开发者确实拥有扫描器、仪表板以及 AI 增强工具，但这些工具无法替企业决定全局优先级、协调资源、解决部门职责冲突，或改变激励机制。文章把技术债务和安全债务类比为财务债务，认为二者都会带来未来维护成本、声誉损失和实际经济负担，即使这些成本不像资产负债表上的债务那样显眼。最后，文章引用了 CISA 的 Secure by Design 建议，包括指定高管负责、向董事会汇报、建立有效激励，以及创建安全设计委员会来协调预防工作。
资讯正文
企业正在聚焦能够改变网络安全结果的软件策略。挑战在于尽早把安全嵌入开发周期，并构建出能够在漏洞和缺陷变成大麻烦之前将其捕捉出来的工具与技术。本文将探讨，从被动响应转向主动预防，实际上是一项文化层面的要求，以及领导层必须如何把安全从“上线后修修补补”的做法，提升为“上线前设计内嵌”的策略。
传统的应用安全通常是在发布后发现并修补缺陷。源头安全则是一种战略性方法，试图从一开始就防止问题出现。但这种做法的内涵远不止于此，尤其是在企业层面。要让这项战略成为整个组织的硬性要求，预防就需要成为一种有资金支持、有人管理、可重复执行的运营模式。
软件安全作为领导责任
这正是软件管理从一线管理职责，转变为董事会层面必要事项的地方。当企业业务开发团队编写的代码承载着客户体验、运营、身份认证、支付、分析以及 AI 工作流时，安全设计就成为高级领导层一项关乎公司存亡的风险缓释优先事项。开发者负责开发，这已写在我们的基因里。我们有工具，如今又加入了 AI，可以把它们用作扫描器和仪表盘，来识别并跟踪问题。但无论是软件工具，还是我们有血有肉的工程团队，都无法决定全球优先级、分配企业范围内的工程产能、改变激励机制、解决部门之间的所有权冲突，或者把风险预防变成每个部门和事业部核心运行原则中的关键组成部分。另请参阅：Proton 首席执行官表示，AI 时代的隐私是可以实现的，但有一件事让他夜不能寐。
当一家公司发布季度或年度报告时，投资者、管理层和监管机构审视的关键指标之一是债务；债务在公司身上背负得越重，利益相关方就越担忧。但与资产负债表上的债务体现公司未来付款义务不同，技术债务和安全债务并不那么容易衡量。尽管如此，两者都反映了组织对未来维护和修复的义务。这种要求意味着机会成本、声誉成本、客户满意度成本，以及真实的金钱成本，有时甚至远远超过资产负债表上可见的数字。功能范围、交付期限、人员配置、外包、平台决策以及供应商选择，都会影响企业所创造的安全债务水平。与资产负债表债务不同，技术债务和安全债务往往没有被高级领导层充分看见。当然，漏洞指标和工单关闭率确实表明有一些动作，但它们只会突出并奖励清理活动。这些衡量方式并不能显示关键缺陷、重复性缺陷类别以及高风险默认设置是在减少还是在增加。
另请参阅：如何审计 ChatGPT 对你的了解程度——并重新掌控你的数据隐私。CISA（Cybersecurity and Infrastructure Security Agency，网络安全和基础设施安全局）的 Secure by Design 倡议建议各组织：指定一名高管担任 secure-by-design 负责人：赋予一位领导者对客户安全结果的权威。授权 secure-by-design 高管：让领导层能够影响产品投入和风险降低。在财务报告中纳入 secure-by-design 细节：把客户安全视为业务绩效问题。定期向董事会提交产品安全报告：让客户风险在治理层面可见。建立有实际意义的内部激励机制：奖励那些提升客户安全结果的团队。建立一个 secure-by-design 委员会：在业务团队和技术团队之间协调预防目标。创建并发展客户委员会：利用客户反馈改进产品安全。CISA 的重点在于与向客户交付产品相关的 secure-by-design。不过，你需要把这一做法进一步推进，使其不仅成为面向用户交付产品时的总体优先事项，也成为所有内部运营的总体优先事项。把应用安全纳入企业文化 企业文化是一种奇怪而模糊的东西。一方面，有政策手册和管理指令；另一方面，则是文化，它建立在公司各个层级所体现出来的口头和内在信号之上。我们已经讨论过如何把应用安全融入管理指令，但把应用安全融入企业文化同样重要，甚至更重要。另请参阅：关于软件开发者即将迎来末日的论点为何站不住脚。安全不能只是那个说“不”的团队。安全意识必须成为一种共享实践：产品经理会询问滥用场景，架构师会界定信任边界，开发者会采用更安全的模式，而安全团队则提供切实可行的指导。对于那些认为企业文化不可能迅速改变的人，我有一个亲身经历可以证明相反的情况。回到过去，我还是一名非常年轻的首席执行官。短短四个月里，我公司的规模翻了一倍。为了让一切更便于管理，我决定把团队划分为不同部门：销售、工程、制造等等。前一周，我们的结构还是几乎每个人都向我汇报，并且会主动帮忙处理公司需要完成的任何事情；到了下一周，部门之间就开始争夺地盘。一个部门的人拒绝帮助另一个部门的优先事项。那些前几天还乐于并肩工作的同样一批人，突然之间除非管理层明确要求，否则就拒绝帮忙。我对这种转变感到非常震惊。我只是想找到一种方式，让公司能稍微更快地响应，而不至于在每一个决策和指令上都完全依赖我的个人指导。结果我得到的却是一套新竖起的生产力壁垒，以及一个个“小封地”的诞生。这种变化只发生在一个周末。周五，我们还在一起协作；到了周一，就多了个以“D”开头的词（指 department，部门），每个人的行为都变了。
另见：这 4 个关键的 AI 漏洞正被利用，速度快到防御者来不及应对。虽然我的这个例子是一个关于企业文化迅速变化的反面案例，但我把它分享出来，是想把它作为一个说明组织如何在一夜之间发生变化的教训。当时我还太嫩，不明白有意识地设计文化变革有多重要，但你可以从我的错误中吸取经验。简短说一下后续：我后来禁止了那个以“D”开头的词，大家又回去一起协作了。人啊，真是这样。总之，如果你想把预防变成企业文化的核心，你就需要在一开始处理两个潜在难点：开发者摩擦和责任归属。另见：近半数网络安全专业人士想辞职——原因在这里。
在将应用安全融入企业文化时，也要关注沟通质量。如果问题报告以指责的方式落到开发者头上，描述含糊不清、要求无法承受，或者根本不考虑整体开发负荷，程序员就会抵制这种变化、固执己见，并把无所作为发挥成一种艺术。但如果安全细节以清晰的需求、可复用的组件、快速反馈和有用的指引发送给开发者，开发者就更会被鼓励去帮助并支持发布前的优化与缓解流程。决策总是必须做出的。开发者需要帮助来判断业务优先级。例如，开发者应当优先处理设计问题，还是优先推进一个新功能发布？来自销售和客户支持的压力会让人感觉像在拔河。扎实的发布前质量管理需要对设计决策、依赖项选择、密钥处理、构建流水线、部署批准以及漏洞响应有清晰的责任分工。必须建立一种管理结构，保护开发者和测试人员免受相互矛盾的信息传递，以及彼此冲突甚至争斗的部门经理的影响。
要记住，含糊不清和责任归属冲突会压倒对质量和安全的追求。正如我那次“D”字经历所展示的那样，文化绝不应该制造一种环境，让把事情做成他人的责任（无论“事情”究竟是什么）被视为可以接受的行为。将应用安全转变为一种运营模式。对商业模式这个概念做一个极端简化的理解，就是它关乎公司如何赚钱。同样，对运营模式这个概念做一个极端简化的理解，就是它关乎公司如何做它所做的事情来赚钱。运营模式描述的是一家公司如何向客户交付价值，以及它如何自我运转。许多公司和组织并没有被明确定义的运营模式。简单说，它们在做一些事，然后其他事就发生了。但一旦这些活动被有意识地转变为有意的、可重复的、可预测的、可调优的系统，运营模式就会成为真正的力量倍增器。咨询公司麦肯锡将运营模式定义为“任何组织的支柱”。
它概述了公司如何为客户创造价值、如何在日常运营中运作，以及如何实现其战略目标。该公司表示：“一个强大的运营模式为决策、资源分配、创新以及业务中许多其他关键活动和实践提供了指导性框架——这一切都是为了提高效率并实现可持续增长。”
在人工智能时代，你的企业不能犯错的5种安全战术——以及它们为何至关重要。由于当今的软件开发基础设施支撑着几乎所有组织中的几乎所有其他价值创造，为软件可靠性和安全性建立一个企业级运营模式完全合理。一旦高层组织领导者接受了将预防性安全和代码开发提前到生命周期更早阶段这一关键要求，组织就需要明确的角色、决策点、工作流程、激励机制、指标和升级路径，使早期应用安全流程成为正常组织运营的一部分。在定义预防性安全的运营模式时，可以回答这样一些问题：安全设计决策由谁负责？威胁建模何时进行？哪些功能需要安全审查？团队应该使用哪些安全模板或批准的组件？谁可以批准例外？如何处理依赖风险？哪些指标能显示预防是否奏效？董事会或高管团队如何衡量进展？这就是将“安全即设计”系统化。通过在所有层级、所有领域内嵌并实践一种运营模式，早期生命周期安全和代码可靠性可以被构建到每个阶段中：架构、编码、发布以及长期维护。
提升企业韧性。围绕早期阶段安全和可靠性的讨论很多，但我必须强调一件非常非常重要的事：并非一切都会按计划运行。不要以为只要遵循了最佳建议，就不会再出现需要慌忙修复的后期安全问题或漏洞问题。也不要以为所有代码离开你的网络时都会完美无缺、没有漏洞。也不要假设坏人不会突破你的网络，或者不会突破你客户的网络，因为你实践了“安全即设计”。生活是变化的。软件开发和生活中的混杂因素几乎是无限的。正如人们常说的，意外总会发生。这就是为什么我们倡导这些最佳实践。采用这些实践，你可以减少紧急情况的数量。你可以减少整体安全债务和技术债务（顺便说一句，这也可能减少你的实际债务）。这种方法可以帮助你减少可预防的缺陷，快速从事件中提炼理解，定义更安全的默认设置，做出更好的工程判断，并建立积极降低做出危险选择可能性的内部系统。另有：每两位安全负责人中就有一位表示他们还没为AI攻击做好准备——现在就采取的4项行动。综合来看，这些实践有助于提升企业韧性。
韧性有很多不同的定义。韦氏词典将其描述为：“从不幸或变化中恢复过来，或轻松适应的能力。”联合国减少灾害风险办公室将韧性定义为：“一个系统、社区或社会面对灾害时，抵抗、吸收、适应、转变并及时高效地从灾害影响中恢复的能力。”麦肯锡将其定义为：“不仅能从危机中迅速恢复，还能更强地反弹——甚至蓬勃发展。”美国国务院则将韧性描述为“从困难经历中重新振作起来的能力。”
来源与参考
收录于 2026-05-12