从历史上看，许多信任专业人员（即网络安全、审计、治理、风险和隐私专业人员）并不总是直接或普遍参与软件开发。当然，这是就总体而言，也有例外。毕竟，一些组织拥有高度复杂的应用程序安全计划和对产品安全的深刻理解。他们将隐私和安全性融入软件中，并与开发人员和工程师紧密合作。但公平而言，这些少数的幸运者是例外而非常态。

我之所以提出这个问题是因为，在许多组织中都存在一种宏观趋势：软件开发和发布流程的加速和自动化。我认为，从业人员应该提高警惕，关注这一趋势，并在必要时改变我们做事的方式。我们都知道，有时可能会出现商业动态和市场力量发生冲突并产生拐点的情况，此时，根据我们应对挑战的方式，可能会产生新的风险。虽然它们可能会产生风险，如果应对得当，这些相同的拐点往往会带来降低风险的机遇。我们这些身处信任行业时间足够长的人已经看到，大约十年前随着虚拟化和虚拟数据中心的兴起，这种情况已经发生了。就在几年前，我们在云上再次体验过它。我相信我们现在正处于一个全新领域的转折点：软件开发。我指的是近年来出现的几种不同（但相关）的技术和范式，它们正在努力改变软件开发的方式。这些趋势的累积效应可能会对企业和信任专业人士产生巨大的变革性影响。从组织的角度来看，这些新兴技术改变了一些最关键和最敏感的业务流程。

同时，对于从业者的我们来说，它们有可能极大地改变我们保证和确保这些过程的输出的方式，以及过程本身。

要理解我想表达的内容，请花点时间思考一下软件开发中的一些新的和新兴的趋势。在过去的几年里，您可能已经注意到开发方法充满了变化，包括：

人们可能很容易将这些变化统统归于DevOps之下，或者单独关注这些变化，而不是承认聚合的趋势。然而，这些趋势中的每一个都与其他趋势有一些共同点，直接适用于我们处理一般应用程序安全的核心，以及与软件输出相关的具体风险。虽然这很微妙，但我认为了解这些趋势的核心内容对我们如何实现应用程序安全、避免应用程序风险和提供应用程序保证具有巨大的影响。

如果这听起来很夸张，让我来解释一下我的观点，并引出这些变化加在一起意味着什么。我认为，所有变化一起发生后，我们绝对需要更严格、更彻底、更全面地处理应用程序安全和产品安全。

要开始阐明这个观点，我将从机会成本的概念，以及我们如何选择处理我们的安全、审计、治理、风险和/或隐私计划入手。如果您熟悉与金融投资相关的机会成本，您会知道我想表达的意思。如果没有，请允许我解释一下。在金融或投资方面，机会成本是指如果您的资金被用于其他地方，您可能会错过的潜在机会。举个例子，假设我有1000美元要投资。考虑到可用的选项，我决定将这些资金存入一张三年期存款凭证（CD），收益率为6%。

鉴于目前三年期CD的平均收益率约为5%，这似乎是一项相当不错的投资。但是，当我的朋友在从银行回家的路上打电话告诉我一项投资与CD风险相同，但回报率为10%而不是6%时，会发生什么？这听起来不错，只是我的钱在未来三年被绑在CD上，所以我不能进行新的投资。此场景说明了机会成本的概念。

机会成本代表了我们本来可以做但没有做的事情，因为我们选择了做其他事情。在这个例子中，我错过了更好的收益，因为我已经投资了CD。对于我们这些处理风险的人来说，同样的事情每天都在我们的工作中发生。任何时候我们做任何事情，我们都会做出选择。通过将资源应用于A区，我们就没有资源投资于B区。当然，财务资源也是如此，但我们的时间、员工的时间、我们的注意力、行政人员的注意力和许多其他事情也是如此。我们所做的任何事情，都是以牺牲某事或某人为代价的。

当然，这对我们如何选择控件有影响。部署控件意味着我们可用于其他项目的资源更少。我们收回的任何时间或金钱都有可能让我们利用这些资源在新的地方抵消风险。它同样适用于我们可能选择部署的控件类型。

例如，假设一个客户服务中心，该中心可以访问包含客户个人身份信息 (PII) 的客户数据记录，例如他们的社会安全号码或其他国家/地区标识符。如果我们想确保客服代表不会意外地向未经授权的人员提供敏感详细信息，那么有几种选择可用于此。其中一种选择是，我们可以培训代表避免这样做。我们可以定期向他们发送提醒，进行入职和进修培训，以确保将其铭刻在他们的记忆中，进行演习和模拟练习，帮助员工保持对社会工程的抵抗力，并定期测试他们以确保课程坚持下去。

但这是最有效的选择吗？另一种选择是更改底层系统，以便客户服务人员在没有经理提供覆盖和签字的情况下无法访问敏感数据。在这种情况下，客服代表实际上无法向社会工程师提供信息。即使他们完全被社会工程师的借口（社会工程师使用的诡计）欺骗了，他们也无法按照那些谎言去访问敏感数据，因为他们无法访问所请求的底层数据。

回到机会成本的概念，在第一种场景（培训）中，机会成本从金钱的角度看比较低，但从时间的角度看，机会成本较高。这意味着，创建培训活动、发送提醒、开发培训、更新培训和进行模拟所花费的时间本可以投入到其他地方，但现在却被全部用于控制操作。同样，在第二种场景（更新应用程序）中，金钱角度的机会成本较高（代表更新应用程序所需的投资），但我们节约了时间。

我并不是说一种方法更好，另一种方法更糟。哪种方法更好显然取决于环境和背景。实际上，我只是指出，这两种方法的经济情况是不同的，即使它们的结果相似。它们有何不同？一方面，培训控制代表了长期的持续成本。由于员工流失、人类记忆的易错性和人性等因素，需要定期重复培训和相关措施以保持有效性。这就意味着第四年或第五年的控制运作成本将与第一年或第二年的成本相似。相比之下，更改应用程序的方法具有较低的维护开销，但初始开销较高（可能高得多），因为它需要更改或自定义正在使用的应用程序。

即使您同意上述所有内容，您也可能会挠头，想知道这些与软件开发或我们如何在软件开发生命周期 (SDLC) 中处理风险有什么关系。而且，从历史上看，答案可能是“没有那么多”。直到最近，作为灵活管理的原则，我们可能已经认识到此类控制措施的相对权衡，并根据可用的资源和我们想要投资的地方为我们的组织做出最佳选择。在某些情况下，我们可能倾向于自动化方法（前期成本较高），而在其他情况下，我们可能倾向于手动方法（间接成本较高，但引导成本较低）。选择哪个的决定可以基于任意数量的背景因素。

然而，今天，至少在软件的创建方式方面，我认为，由于软件的开发方式，我们几乎没有选择。回想一下，我刚才请你考虑一份新的软件开发趋势清单，以及它们有什么共同点。我认为，这些趋势的主要“贯穿线”可以归结为一件事：减少软件开发所花费的时间。从抽象的角度来看，它们都有助于节省时间。有些缩短了上市时间，有些降低了迭代节奏，有些支持自动化方法，从而减少了单个工程师所需的时间，有些提高了敏捷性（从而减少了发布所需的时间和摩擦）等等。

从机会成本的角度来看，有一件事变得很清楚。我们正在失去对选择自动化（以更高的前期成本和较低的持续维护成本）还是选择实施手动控制（以较低的初始成本和更高的持续维护成本）的选择权。相反，我们必须自动化我们的安全控制以保持相关性。并且我们可以使用的任何需要高度手动干预的方法或控制都将失去应用场景，因为与软件开发的发展方式根本不兼容。

考虑历史上应用于应用程序安全的控制措施：静态应用程序安全测试 (SAST)、动态应用程序安全测试 (DAST)、威胁建模、应用程序渗透测试、漏洞扫描、软件组合 (SCA) 、安全代码培训等。

想一想这些控件的维护需要多少手动成本。SAST 和 DAST 都需要手动干预才能消除大量误报。威胁建模通常是一个高度手动的过程，需要创建图表和手动分析组件交互点。应用程序渗透测试需要人类工程师才能获得最大价值，而培训需要开发人员的时间，以及管理安全和合规性团队的时间。重点是什么？我们可用的方法与软件开发机制直接冲突。这不是一个好兆头。而且，坦率地说，随着人工智能 (AI) 技术的不断发展并进一步简化软件开发，情况可能会变得更糟。

向企业领导者解释为什么与产品开发、内部应用程序部署和创新相关的重要目标必须因为保证或安全原因而放慢速度，这是徒劳的。同样，仅仅为了安全和风险管理的考虑而坚持使用手动技术也是次优的。这种立场会消耗政治资本，并削弱其他团队（例如开发、运营、工程等）与我们合作的意愿。

那么，我们能做些什么呢？有几件事，其中大部分行动在我们刚开始采取的时候可能会令人感到不舒服，因为它们的发展方向历来受到挑战。首先并且最重要的是，我认为我们需要深入细节，从软件开发的角度来了解“香肠是如何制作出来的”。重要的是要了解应用程序是如何开发的，采用了什么方法来开发应用程序，开发人员和运营团队的工具集及其目标。由于这些因素既不是静态的，也不是安全和保障团队历来接触过的领域，因此培养这些理解可能需要新的技能和协同努力。

建立这种理解的一部分是帮助建立信任，只有当你知道你在说什么时，你才能做到这一点。寻求知识将有助于确定自动化安全控制操作的方法。这就是我们正在努力的目标。我们需要新的自动化方法，因为我们过去20年采用的自动化方法在现代化发展的需求下正在快速地失去效力。我们应该非常仔细地研究安全控制，以及我们如何自动化我们所做的工作。我们是否可以使用 IaC 来自动生成用于威胁建模的数据流图？我们可以在构建结束时自动化运行DAST吗？我们能否将软件组合和/或 SAST 集成到源代码管理存档中，以便自动触发评估？机制会因业务而异，但思维过程应该是相同的：我们可以自动化什么以及在哪里自动化？

此外，我们需要进一步了解开发人员越来越依赖的特定工具和趋势，因为从安全和保证的角度来看，其中许多技术可以提供直接价值。当出于安全目的利用 IaC 等技术时，可以证明非常有价值，创建软件物料清单 (SBOM)、容器化等策略也是如此。当创造性地应用时，所有这些都对我们非常有用。因此，了解它们的工作原理势在必行。

此外，我们需要与开发和运营团队中的利益相关者建立关系，这些利益相关者与执行工作联系最紧密。联系 DevOps 团队、生产运营团队、开发人员和测试人员，让他们站在您这边。向他们展示价值，因为他们对证明你在未来实现自动化控制的努力和保持你提供的数字信任服务有助于开发人员和运营团队的工作至关重要。归根结底，这些团队将始终比信任专业人员更了解他们所做的工作。通过公开传达您的目标并灵活地实现这些目标来争取他们为您提供帮助。

我们说规则能够支持信任，规则的目的是赋能业务，这样的说法难免苍白无力。尽管我们都这么说，但一个经常被忽视的重要因素是我们走出舒适区来实现这一目标的意愿。如今，软件和业务同等重要。我们越能加强一个，就越能支持另一个。

作者：ED MOYLE, CISSP, 目前担任Drake Software 的软件和系统安全总监。