本文主要是关于应用程序安全性战略趋势、它们的影响以及如何最大限度地利用我们所面临的变化。

应用程序安全性正在发生巨大的变化，变化的速度如此之快，以至于 10 年前进入软件开发领域的人都几乎无法看清楚当前的状态。

对于开发人员来说，快速变化是一颗难以下咽的苦果。开发人员时刻面临着多方面的变化：新技术和框架、编程语言、工具、流程，等等。要与软件开发核心主题保持与时俱进是很困难的，更不用说像应用程序安全性这样的主题了。

关于应用程序安全性的主要趋势，有一件事我很清楚：好消息多于坏消息。我并没有低估了坏消息，实际上坏消息也有很多，但这枚硬币还有另外一面。

挑战为我们创造了机会。如果我们从大的角度来看，应用程序安全性正在为我们创造机会。有战略头脑的软件开发人员在解决问题和利用机会方面做得非常出色。本文将讨论一些这方面的东西。

在本文中，我们将介绍一些趋势：

• DevSecOps 和开发团队应用安全责任的融合；

• 代码内部和外部的攻击模式变化；

• 对开发人员友好的应用程序安全性测试；

• 软件供应链安全的兴起成为人们关注的焦点；

• 风险最大但人们却不怎么讨论的秘钥管理；

• 保护数据而不仅仅是代码；

• 认证授权的变革进展；

• 第三方对安全的依赖和影响；

• 改变用户对安全性的期望。

这是一篇涉及面很广的文章，几乎涵盖了应用程序安全的每一个领域。由于本文涉及的范围很广，因此本文的结构与典型的以公司为中心的分析略有不同。本文的目标是涵盖更多的领域，同时也将提供一些实用的想法。

让我们开始吧。

融合让开发人员对开发以外的东西也负起责任

影响

开发、安全性和运营的融合等于是将所有东西都直接转移到开发人员身上。传统上，软件开发是关于编写、测试和部署代码。现在，DevSecOps(更重要的是它背后的流程和工具)正在把更多的责任和控制权转移给开发人员。开发人员除了负责代码的部分，现在也要对基础设施、安全性等方面负责。

从表面上看，责任的增加看起来像是一件坏事。或许确实如此，但更重要的是要知道其中的原因。当你仔细地观察一个这个趋势，你会发现，是工具的改进促成了这种转变。

工具正在变得越来越好，让这些工作负载变得可管理——甚至可能是有利的。在安全性方面，许多新产品都是可组合的，它们为开发人员提供了一组原语和工作流来构建安全性，而不是为他们提供一刀刀的产品。

Persona 就是一个很好的例子，它是一组构建模块，开发人员可以用它们为客户构建特定的身份验证工作流。另一个是 Panther，开发人员可以用它基于一组日志管理和警报原语来构建高度定制的 SIEM。

有远见的安全软件公司将继续构建对开发者友好的工具。预计未来还会出现更多这样的东西。

想法

开发与安全性的融合将继续下去，所以请拥抱它吧。随着新模式(和新产品)的普及，这一趋势将会加速。

正如 Eleanor Roosevelt 所说的：“自由伴随着责任。”传统的安全观念通常是购买(理论上)能够解决一系列安全问题的产品，而融合和可组合性扭转了这一局面。

现在，我们有了一套很好的工具，我们可以用它们来为我们的安全问题构建解决方案。这是一个很好的转变，但很多人还没有准备好。

最后，开发团队应该有意识地采用开发过程和工具，不要让安全团队强加给你们这些，而应该在达成共识的基础上开展合作。这一趋势为重新定义开发和安全之间的关系(以及选择世界级的工具)带来了一个机会窗口，所以要充分利用它。

发生在应用程序之外的攻击

影响

攻击者的目标是你的客户和金钱，而利用应用程序只是实现这一目标的众多途径之一。不幸的是，攻击者总是在寻找新的和创造性的方法来实现他们的邪恶动机。攻击你的应用程序是一种可靠的方法，但最近的一些攻击已经渗透到软件工程的邻近领域。

例如，针对 DevOps 管道的攻击已经造成了包括 SolarWinds 在内的重大漏洞。InfoSec 社区非常重视代码安全，尽管如此，像 SolarWinds 这样的例子告诉我们，我工程流程的其他部分也正在成为攻击目标。

攻击可能来自各个方面，即使能够避免泄露，也会产生运营上的影响。Verizon 发布的 2021 年数据泄露调查报告显示，拒绝服务(DoS)攻击导致了不成比例的事故(但数据泄露不是很多)。不幸的是，我们现在需要留心遵循这种模式的稳定的攻击流(甚至是巨大的峰值)。

想法

将你的安全意识扩展到代码之外。攻击者正在寻找他们所能找到的任何方法来攻击你。我们必须调整自己的心态，将代码之外的区域纳入安全模型范围。

考虑使用 DoS 缓解策略和自动化程序管理等服务。虽然攻击无法完全消除，但可以降低其影响。像 Cloudflare 这样的服务通常可以降低大型攻击造成的危害，为我们的应用程序添加这一层保护是值得的。

将你的 DevOps 管道纳入威胁建模活动。CI/CD 工具、工件存储库和管道的其他部分现在都是需要保护的目标，就像我们的代码和基础设施一样。

基本的 Web 应用程序攻击仍占入侵总数的 26.1%

影响

Verizon 的 DBIR 报告显示，Web 应用程序攻击是第二常见的攻击模式(社会工程位居第一，百分比为 33.6%)。攻击者关注的不只是应用程序，但应用程序仍然会受到攻击，并以惊人的速度造成泄露。

“凭证填充”攻击的上升趋势正在形成一种新的攻击模式。Verizon 的 DBIR 报告显示，凭证填充(约占 80%)导致的事故远多于漏洞利用(约占 20%)。考虑到漏洞利用的可见程度和教育程度，这样的比例让许多人感到意外。

从过程和治理的角度来看，漏洞管理程序正在与应用程序安全性和风险管理融合在一起。过去，这些领域是分开对待的，漏洞管理侧重于打补丁，风险管理侧重于审计和合规性。但现在公司一般采用基于风险的方法进行漏洞管理，并在整个过程中管理应用程序安全漏洞。

想法

不止于手动测试和一次性静态代码扫描。现如今，在快速的迭代式软件开发过程中，基于时间点的扫描或人工评审无法跟上应用程序代码的变化速度。最理想的情况是在写代码时就做好保护。正如我们接下来将要讨论的，工具方面的一些改进为迭代式且对开发人员友好的开发方法带来了可能性。

使用服务来检测和防御凭证填充攻击。这种攻击模式仍然是针对应用程序的攻击，尽管它使用的方法与传统的漏洞利用不同。我们必须预料到对应用程序进行的凭证填充攻击会持续不断，包括在发生新的凭证泄露时偶尔会激增的攻击数量。

采用基于优先级和风险的方法来纠正漏洞。尽管我们很想关闭所有的漏洞，但目前来看，要让大多数公司在实践当中做到这样是不切实际的。基于风险的方法使纠正漏洞更易于管理。

应用程序安全测试正在变得对开发人员友好

影响

组织(和产品)终于开始迎合开发人员的需求。对于任何一个有经验的软件开发人员来说，这都是一个漫长的过程。尽管应用程序安全工单、延迟发布和最后时刻漏洞修复的痛苦记忆还没有完全消去，但已经取得了很大的进展。

主要的想法是在开发过程中将应用程序安全性测试向前移，并在开发和提交代码时执行代码扫描。“左移”这个词有点被过度使用，但其基本思想还是不错的。就像编写自动化测试并获得实时反馈一样，你也可以用类似的方式运行自动化安全测试。

一些公司，比如 Veracode 和 Snyk，已经在这方面处于领先地位。这两家公司都有可能在未来五年内通过 IPO 获得回报。他们的成功(以及庞大的开发者基础)印证了软件开发可以同时提高速度和安全性的观点——这两个目标并不是互斥的。

想法

有远见的工程团队痴迷于可以简化编写安全代码的过程。正如 Snyk 的创始人 Guy Podjarny 最近在一个“Human Layer Security”播客中所讨论的：“你不得不去操心一些事情，而你操的心比这些事情给你造成的负担要多得多。”这句话简明扼要地定义了一些产品（比如 Snyk）的价值。如果我们为开发人员简化安全性实施过程，他们就更有可能接受它。

Podjarny 还讨论了对应用程序安全性进行去中心化的想法。传统的模式是让信息安全团队完全负责应用程序安全测试。但随着软件继续吞噬世界，公司编写越来越多的代码，这种做法自然成为了瓶颈。现代应用程序安全工具提供了去中心化的可能性，并有助于将安全性转变为工程团队和安全团队之间的共同责任。

最后，在现代应用程序安全平台上进行投入。这一领域的主要进展是提供了众多工具，它们的采用成本出人意料地低，尤其是考虑到它们对公司安全状况的影响。

软件供应链安全不再隐匿于水面之下

影响

Log4j(Log4Shell)、NPM 库(colors/faker)和其他引人注目的漏洞让软件供应链安全在 2021 年受到了人们的关注。甚至连美国总统都在谈论它(并采取行动)。

事后看来，这种趋势的出现本应是显而易见的。多年来，我们一直在依赖开源软件包，相对平静和稳定的软件供应链安全不会永远持续下去——软件包成为攻击载体只是时间问题。

救兵正在路上。在过去两个季度里，新一代初创企业筹集了 1060 万美元资金，其中大部分是种子期融资。从 2021 年的漏洞攻击中吸取教训并思考采取哪些有效的行动，我们需要一段时间才能形成这种集体共识。不管怎样，创新和进步的步伐都将快速向前移动。

想法

首先，我们必须总结近期的教训：优先查找和修复应用程序中的漏洞。Snyk 或 Github Dependabot 等工具在这方面可以帮得上忙。尽可能自动化地查找易受攻击的软件包，然后以更自动化的方式高效地修复漏洞。

请关注这一领域的新兴公司。正如我之前所说的，救兵正在路上。Chainguard 公司最近获得了一笔融资，它的经验丰富的团队正在开发一款创新的产品。

最后，探索一些新兴的方法，比如 SLSA 和 Sigstore。这些项目还需要一些时间来演化并成为直接可操作的产品。不管怎样，花点时间关注一下最新的进展总是值得的，因为当它们被主流采用时，你已经做好了准备。

秘钥管理是最大的风险，但没有人关注

影响

人们讨论(和抱怨)密码安全问题，但很少有人花时间讨论管理其他类型的秘钥。API 密钥、证书和其他非密码形式的访问控制被置于聚光灯之外。对很多人来说，它们只是“开发人员使用的东西”。

在 2021 年的一项 1Password 调查中，80%的 IT/DevOps 组织承认没有很好地管理他们的秘钥。这可不是什么好事。这个问题比你想象的更普遍。在同一项调查中，65%的公司表示拥有超过 500 个秘钥，18%的公司拥有数不清的秘钥。

拥有超过 500 个秘钥(或者更多——谁知道呢，对吧？！)却没有很好地管理它们，这种情况显然是很糟糕的。有了秘钥，就可以获取对很多敏感信息的访问权限，就像我们最近看到的针对 GitHub 账户的令牌攻击一样。现在已经出现了保护秘钥的势头，攻击促使保护秘钥的想法变得更加突出。

想法

让保持秘钥卫生成为工程文化的一部分。如果我们不谈论保护和管理秘钥，就不能指望人们会保证它们的安全。秘钥需要成为安全讨论和行动的一部分。

解决办法之一是使用秘钥管理服务。现在已经有一些不错的产品，包括 CyberArk Conjur、HashiCorp Vault 和 1Password Secrets Automation。GitHub 也在 Actions 工作流中建立了基本的秘钥管理权限。

最后，在产品实施之前有效地发现秘钥的“藏身处”，这是很重要的一步。因为你无法保护你不知道的秘钥，完全发现它们比你想象的要困难得多。秘钥总是被嵌入到源代码或配置文件中。最好的方法是将秘钥发现作为一个项目，坦白交代你的发现，并保护好它们。

保护数据和保护代码同样重要

影响

很多常见的攻击模式会绕过应用程序，直接攻击数据存储。我们比以往任何时候都更需要考虑保护应用程序之外的数据。Verizon 的 DBIR 报告显示，攻击者的目标通常是获取凭证(用于特权升级)、个人数据、银行数据和内部机密数据。

隐私法规也为人为错误带来了惩戒。这提升了数据保护标准，确保只有需要访问权限的人才能访问数据。如果可以避免，就不应该让开发团队过多地访问生产数据。

如今，在设计应用程序时，需要将数据安全性纳入架构的考虑范围。如何保护敏感数据是整体解决方案的一部分，需要为其设计隐私保护。设计一个应用程序已经很困难了，但不管怎样，数据保护仍然是设计过程不可或缺的一部分。

想法

成为保护数据解决方案的一部分，不要把责任留给基础设施和安全团队。对于开发团队来说，编写安全的代码仍然很重要，但不能以完全忽略数据安全为代价。

探索可以帮助开发人员和数据科学家安全处理敏感数据的新兴方法和产品。来自 Y Combinator W22 项目的 JumpWire 和 Sarus 这两家公司正在解决这个问题。还有一篇关于 Evervault(另一家加密基础设施开发公司)的文章也很值得一读。我们离事实上的标准还有很长的路要走，但我对未来充满希望。

我们正处于认证和授权的黄金时代

影响

认真对待。目前可供开发人员使用的身份认证和授权解决方案数量惊人。它们一天比一天好。像 FusionAuth、Transmit Security、Stytch 等公司已经推出了世界级的、对开发者友好的认证产品，使用起来非常简单。

用户也越来越熟悉新的身份认证因子。我们离完全实现无密码机制还有很长一段时间，但对于处于不安全环境的人来说，像魔术链接这样的升级技术已经开始变得更加可行。这是一个很好的趋势，因为主流的采用为我们提供了比单独使用密码更好的选择。

最后，外部授权正在成为新一代产品的选择。这种趋势仍然是一个长期的过程，不过已经有一批公司正在开发可以让这项工作变得更容易的产品。

想法

我想再重申一遍：不要使用自己的身份认证机制。你的应用程序可能会因为多种原因受到攻击和破坏。构建自己的认证机制是在冒不必要的风险——这在 2022 年本质上是一种反模式。可以考虑使用外部服务或开源包，如 Devise(Ruby on Rails 社区在使用)。

在对应用程序进行身份认证时，需要为用户提供无密码或多因子身份验证(MFA)选项，使用外部身份认证平台可以更容易实现。用最小的努力为用户带来额外的安全好处，这么做是非常值得的。

最后，验证进行外部授权是否可行，但要小心谨慎。将授权交给第三方的风险比使用第三方标准身份认证机制的风险要大得多。但是，这总比在构建自己的授权机制时犯错要好。

安全性高度依赖于第三方

影响

在 SaaS 和云计算世界，安全型比以往任何时候都更依赖于第三方。我们将应用程序托管在大型的云供应商平台上。从 UI 框架到聊天，再到分析等，都依赖于第三方服务。我只是建议使用第三方认证机制，但现在都纠缠在一起了，安全性之间是互相依赖的。

当然，潜在风险和影响的程度和规模因服务而异。云服务的漏洞会对整个科技行业造成宏观风险和影响，Mailchimp 之类的服务则处于中位。他们有很多客户，但在最近的案例中，只出现了少数被攻击的情况。

其他解决方案的风险范围较小。有些对客户有潜在的影响(例如聊天服务的宕机)，有些只影响到员工。

我们仍然对安全负有重大责任，尽管在一定程度上超出了我们的可控范围。关键在于我们要意识到这一趋势已经发展到何种程度，以及我们对第三方的依赖程度。我们需要承认现实，这样才能确保采取正确的步骤来保护自己。

想法

理清楚你的应用程序正在使用哪些第三方服务。这与保护秘钥的想法类似——如果你不知道你用了哪些第三方服务，就无法保护它们。

将确保安全视为购买第三方服务的组成部分。在使用服务之前对安全进行评估要比在将其深深嵌入到应用程序中之后进行评估要容易得多。或者更糟的是，在第三方服务被攻击后，你要承担后果。

最后，第三方安全报告(如 SOC2)虽然有用，但你也要自己做好准备。指望审计人员发现每个安全问题是不现实的。对于很多第三方服务来说，你的场景也有可能超出其审计范围。

对于很多用户来说，安全是一个特性

影响

信任和安全正迅速成为产品设计的重要组成部分。关于数据泄露、选举安全、社交媒体等事件的新闻头条不断出现，将安全、隐私、信任和欺诈等问题暴露在公众的视野里。

如果一个应用程序涉及到用户生成的内容、金钱或敏感数据，人们对安全的期望会更高。处理应用程序不良事件，或直接阻止它们发生，这样的经验对许多人来说都非常重要。

想法

实施信任和安全流程，即使是最基本的措施，有总比没有好。但如果你的客户有更高的期望，你就应该准备构建更健壮的特性。

围绕安全和隐私拓展公司透明度的界限。像 Trustpage 和 Cinder 这样的公司正在构建一种新的信任和透明产品，如果实施得当，它就是一种可以让你的公司和产品变得与众不同的战略优势。

原文链接：

https://strategyofsecurity.com/what-developers-need-to-know-about-the-strategy-of-security/