适应开发优先的云原生应用安全模式

发布时间：2023-01-07 09:25 所属栏目：124 来源：互联网

导读：采用 CNAS 需要对我们保护应用程序和基础架构的方式进行重大改变。转变是一个旅程，每个组织都不相同，甚至同一组织的不同部分也不同。虽然选择正确的道路是由你的决定，但为了让它正确，模式和最佳实践已经开始出现。在本文中，我提出了几个可以考虑打破现

　　采用 CNAS 需要对我们保护应用程序和基础架构的方式进行重大改变。转变是一个旅程，每个组织都不相同，甚至同一组织的不同部分也不同。

　　虽然选择正确的道路是由你的决定，但为了让它正确，模式和最佳实践已经开始出现。在本文中，我提出了几个可以考虑打破现状的领域，以及如何打破现状。

　　重新思考工具

　　除了组织架构的改变，CNAS 和“开发优先”还需要重新评估你的工具包。鉴于这种新视角，你应该重新考虑在技术解决方案中寻找的最重要特征，以及你希望如何捆绑工具。

　　有很多方法可以重新评估工具，但我建议关注三个主要领域：开发工具采用、平台范围和治理方法。

　　开发人员工具口径

　　如果我们的目标是让开发人员在日常工作中能够构建安全性，我们需要确保为他们提供针对该目标进行优化的工具。如果你购买专为审计人员设计的解决方案并要求开发人员使用它们，那么你不太可能取得成功。

　　不出所料，开发人员习惯于使用开发人员惯用的工具。这些工具代表了整个行业，围绕着什么是优秀的开发者工具这一主题，已经在行业内发展了自己的最佳实践。为了帮助你选择开发人员将采用的安全解决方案，你应该根据开发者工具最佳实践评估这些工具，并了解它们的表现如何。

　　以下是优秀的开发者工具的一些常见特征：

　　成功的自助服务采用

　　实际上，所有成功的开发工具都具有出色的自助服务用法，包括轻松的上手培训、直观的工作流程和出色的文档。这是开发人员喜欢使用工具的方式，它迫使供应商确保他们的工具与开发人员相关，而无需销售人员推动它。除非你想成为向开发人员推广工具的销售人员，否则请寻找具有开发人员自助服务采用的良好记录的工具。

　　无缝集成到工作流程中

　　在大多数情况下，开发工具经常与开发人员打交道，而不是要求他们再打开另一个工具。它们优雅地集成到其 IDE、Git 和研发管道中，并在正确的时间点提供价值。集成不仅仅是技术钩子;他们需要适应工作流程和最佳实践，否则将被拒绝采用。

　　丰富的API和自动化友好

　　虽然需要固执己见的集成才能开始，但开发工具也必须是瑞士军刀。丰富的API和自动化友好的客户端（CLI/软件开发工具包[SDK]）是强制性的，既可以将该工具调整到每个管道，又允许社区在其上进行构建。如果你不能在工具上构建，它就不是一个伟大的开发工具。

　　开源和社区采用

　　开发人员希望其他开发人员来验证工具的可信度，而开源采用是最好的指标。看到开源项目集成了安全工具或基于此构建的开源项目，这些都是很好的开发人员社区验证。在检查安全工具时，检查它在开源中的采用情况并得出自己的结论。

　　这些只是众多开发工具最佳实践中的一小部分。如果你想了解更多关于开发优先安全性的特定安全建议，请继续往下看。此外，在评估任何工具时，请确保让实际的应用程序开发人员参与进来，以便从现实生活中了解它与周围环境的契合程度（如下图所示）。

　　适应开发优先的云原生应用安全模式

　　开发人员友好的安全工具示例

　　平台范围

　　当前主流的 AST 平台主要关注自定义代码，也许还有应用使用的开源库。工具套件主要由 SAST、DAST 和 IAST 组成，最近又添加了 SCA。当你拥抱更广泛的云原生应用程序范围时，请重新考虑平台的构成。

　　首先，让我们考虑一下哪些工具从成为单一平台的一部分中受益。它们可以分为下面几个部分：

　　共享用户：如果不同的工具是为不同的主要用户设计的，那么它们几乎不需要成为单个平台的一部分，因为它们无论如何都会单独使用。

　　共享工作流：如果以类似的方式使用多个工具并集成到用户工作流的类似点中，则可以通过组合它们来节省集成时间以及用户的时间和精力，而无需使用多个单独的工具。

　　共享优先级：如果来自不同工具的行动项应彼此优先排序，则共享积压工作可以提高效率和结果。

　　价值倍增：最后，工具共享平台的最强驱动力是当工具一起使用可以增强每个工具的价值。这个标准自然解释了为什么像SAST和SCA这样的技术非常适合单一平台。两者都为相同的开发人员用户提供服务，运行扫描并在相同的位置吸引用户，并共享同一开发人员需要优先考虑的安全漏洞的积压。在高级 SCA 解决方案中，SAST 技术可以指示你的自定义代码是否调用库中易受攻击的代码，从而提供更高的准确性，从而增加价值。

　　当你考虑将容器和 IaC 安全性添加到 SAST 和 SCA 的同一平台时，相同的逻辑也适用：

　　共享用户：容器和 IaC 现在由开发人员保护，就像 SAST 和 SCA 一样，他们宁愿没有多个不同的产品需要花时间学习和参与。

　　共享工作流：保护容器和 IaC 需要跨生命周期的集成，例如 IDE、Git 和构建集成，就像 SAST 和 SCA 一样。

　　共享优先级：同一个开发人员需要花费周期来修复容器或 IaC 漏洞，或者代码或库中的漏洞 —— 所有这些都是保护应用的积压工作。

　　价值倍增：保护这些组件有多种方式。扫描容器需要探索内部的应用程序，了解基础设施配置有助于确定代码和库的漏洞优先级，了解跨组件的流程有助于缓解问题；这正是你在对漏洞进行分类时所做的。

　　即使 CNAS 范围扩大，这种逻辑仍然有效，我鼓励你将 CNAS 工具视为一个平台。一个简单的准则是，Git 存储库中的任何内容都可能与其周围的文件相关，并遵循相同的开发工作流。因此，CNAS 平台应有助于保护存储库中的所有内容（整个云原生应用）。

　　DAST 和 IAST 在这样一个平台上是有点尴尬的参与者。尽管它们处理保护应用程序，但它们通常需要不同的工作流程。由于运行它们所花费的时间，很难将它们放入构建管道或 IDE 扫描中。在我看来，这是一个技术问题，而不是一个合乎逻辑的问题，一旦 IAST 和 DAST 解决方案发展到对管道更加友好，它有望得到解决。

　　治理和赋权方法

　　采用开发优先的安全方法需要不同类型的协作。我们需要的工具不是专注于广播和执行自上而下的任务，而是帮助我们协作构建安全应用程序的工具。

　　这听起来可能很明显，但在实践中，这与许多安全工具的工作方式有很大的不同。让我们深入研究一些具体的例子，以了解这意味着什么。

　　首先，开发人员需要有能力平衡业务需求与安全风险。这意味着，例如，允许他们决定不修复发现的漏洞并继续将其部署到生产环境。对某些人来说，这是一个可怕的命题，但这是实现独立团队的唯一方法。请注意，忽略漏洞仍应要求提供（且可审核）原因，并且某些约束应为硬杠杠（通常出于合规性原因），但作为默认立场，决策应留给开发人员。

　　其次，开发人员需要能够管理他们的安全风险，这需要看到他们项目中的所有漏洞。这不仅需要包括漏洞列表，还需要包括确定优先级所需的所有信息，例如可利用性和资产映射。对此类信息保持透明可能会带来一些风险，但这是扩展安全性的唯一方法；要赋予开发人员权力，你必须信任他们提供这些敏感数据。

　　第三，安全团队应该投资于跟踪和推动安全控制的采用，甚至超过他们的产出。开发团队应该管理其漏洞积压工作，但安全团队需要帮助他们成功做到这一点。开发优先安全治理意味着跟踪采用了哪些控件及其输出的处理情况，并与开发团队合作改进这些统计信息，而不是突出显示他们应该修复的漏洞。

　　这些只是评估治理工具和技术时要考虑的几个示例。关键是要拥抱平台心态；它的目标是帮助开发团队成功构建安全软件，而不是跟踪安全漏洞本身。

　　重新思考优先事项

　　最后但并非最不重要的一点是，CNAS 需要重新考虑应用程序安全优先级。如果开发人员需要保护整个云原生应用程序，你希望他们最关注哪些方面？

　　从历史上看，IT安全控制主导了更大的预算，并且比应用程序安全控制获得了更多 CISO 的关注。这种不平衡可能有历史原因，但归根结底，它代表了 CISO 关于如何最好地使用他们的资金来降低组织风险的观点。

　　换句话说，CISO 认为，由于未修补的服务器或配置错误的基础架构而导致的违规风险大于代码中的自定义漏洞的风险。这种看法有相当多的数据来支持它，显示了历史违规行为及其原因。此外，它很容易理解;对于攻击者来说，大规模运行已知的漏洞并寻找一扇敞开的门要比对应用程序进行逆向工程并找到自定义缺陷以使其通过要容易得多。

　　云不会减少这个等式；事实上，云加强了这个等式。采用云意味着使用更多的基础设施和更多的服务器，它们往往更容易公开访问，并且它们由不太熟悉管理它们的团队（开发人员）定义，并配备了不太成熟的工具。

　　然而，虽然以前的平衡是在IT安全预算和应用程序安全预算之间，但现在一切都在应用程序安全世界中。在构建云原生应用程序时，相同的开发人员需要保护其自定义代码，管理其开源使用中的漏洞，并使服务器和基础架构具有弹性。同一个应用程序安全团队需要帮助他们做到这一点，并在他们之间分配相同的预算。

　　因此，我们回到开场白：你希望如何分配宝贵的开发人员的时间和有限的CNAS预算？

　　丢掉开发人员自己的设备和应用程序安全预算并让开发人员的注意力集中在保护自定义代码上。应用程序安全成熟度模型、行业最佳实践以及团队中个人的个人体验都锚定在云前的世界中，其中自定义代码是开发人员必须保护的大部分内容。购买 SAST 和 DAST 等工具通常是应用程序安全新领导者名单上的第一件事，很少受到挑战。

　　但是，考虑到 CNAS 的范围，这仍然是你时间和金钱的最佳利用吗？由于已知漏洞或配置错误而导致的违规风险仍然高于自定义代码缺陷的风险，即使开发人员是配置它的人。如果你同意，难道不应该告诉你的开发人员和应用程序安全团队首先要专注于保护这些层，然后才能处理他们的自定义代码吗？

　　这不是一个容易回答的问题。我不会假设知道你的优先事项应该是什么，因为这些优先事项会因组织而异。但是，鉴于CNAS的范围更广，我强烈建议你在内部进行此对话并重新考虑你的优先事项。

　　结论

　　改变你处理应用程序安全性的方式不仅仅是一种思考练习。它具有非常真实的下游影响，包括人们的职业生涯，预算分配以及对保持组织安全的最佳方式的重新评估。它需要摆脱一些关于你过去如何做事的肌肉记忆，而不是在选择解决方案时回到第一原则，这需要宝贵的时间和精力。

　　好消息是，你不必一次完成所有操作。我在本文中概述的变化相互关联，但可以按照自己的节奏应用。我建议你选择与你最相关的那些内容，或者选择你认为更重要的其他变化，并让这些变化继续下去。你将逐步调整安全功能以适应云原生现实。

（编辑：ASP站长网）