如今，从头到尾确保软件开发生命周期的安全需要组织部署、维护和掌握各种不和谐的工具，这些工具往往会造成不和谐，而不是为 DevSecOps 流程带来和谐。原因很简单：用于保护软件供应链安全的每种工具都会独立运行扫描并生成缺乏上下文、通常是冗余的或完全相互矛盾的警报。
当然，支持这些应用程序的开发人员和软件工程师应该将稳定的警报流关联起来并解决漏洞，以满足将版本传播到上游环境所需的安全阈值。现实情况是，并非所有被标记为高危和严重的漏洞都需要修复，团队也不可能解决所有漏洞。平均而言，开发团队有足够的带宽来解决任何给定月份内 10% 的积压漏洞。如果我们要为这些开发团队提供成功改善安全状况的机会，就必须根据影响而不是严重性来确定漏洞积压的优先级。
持续不断的警报风暴还会导致疲劳，并带来漏报的真正风险。逃走了的那一个！

今天的 DevSecOps 工作流程只不过是一个没有乐谱的管弦乐队的各个部分，期望某种持续锁定软件供应链的方法会神奇地显现出来。
显然缺少的是一个编排框架，该框架可以触发安全工作流程以响应 SDLC 内的更改。理想情况下，它与 CI/CD 工作流程无缝协作，但不依赖它们，从而创建一个能够为组织提供更好安全状态的交响乐。

DevSecOps 的麻烦

在云原生、基于微服务的应用程序开发环境中，团队可以使用多种技术进行开发，每种技术都针对提供某种服务进行了优化。每种技术可能都需要某种专门的扫描工具——而这只是代码；当我们将二进制文件、基础设施管道、数据和身份添加到组合中时，您最终会得到大量的工具和大量的策略，每个更改都需要根据它们进行评估。
是的，您可以在部署到生产环境之前定期扫描容器，如果您每月部署一个版本，这可能没问题。然而，即使如此，您也可能会说，当漏洞被发现时，已经太晚了，您已经输掉了效率之战。
采用基于微服务的架构的真正原因是它易于扩展并且可以快速构建和部署。理想情况下，您希望为客户快速发布功能。这意味着非常高程度的变化，反过来又意味着您所做的时间点评估根本不适合保护您的资产。每一次提交都有可能暴露新的风险，如果留给时间点评估，最终可能会发现得太晚。
相反，如果通过跨 CI/CD 管道的与工具无关的接口无缝、异步地协调安全性，提供从第一次提交到生产部署及以后保护数字资产所需的结果，那么您就真正采用了 DevOps。在这种情况下，每项变更都会被实时评估，其影响将被预测到开发、运营和安全，并有明确的行动号召。
这种方法还为组织在 DevSecOps 采用过程中不断前进提供了一个更具可扩展性和可伸缩性的框架。

概括

没有开发团队故意构建和部署不安全的应用程序。如此频繁地部署具有已知漏洞的应用程序的原因是，与发现和修复这些漏洞相关的认知负担太高。普通开发人员只能分配 10% 到 20% 的时间来修复漏洞。他们的其余时间要么用于编写新代码，要么用于维护用于编写该代码的应用程序开发环境。如果组织想要更安全的应用程序，他们需要找到方法，使开发人员能够在识别漏洞时轻松关联、优先排序和关联。大多数时候，当开发人员被告知在他们的代码中发现了漏洞时，他们早已失去了上下文。
需要在编写代码、创建构建和发出拉取请求时立即识别漏洞，并以可操作的方式识别漏洞。否则，该漏洞可能会被抛在开发人员希望有一天有时间解决的大量技术债务之上。
目前，世界各国政府迟早会颁布立法，要求组织对其构建和部署的软件的安全承担更多责任。精明的 DevSecOps 团队已经认识到，需要改进管理 DevSecOps 工作流程的现有方法才能满足这些要求。现在的挑战和机遇是建立一个可扩展的安全编排框架，消除 DevSecOps 工作流程中的摩擦并通过实时评估提高效率，确保您的软件在默认情况下是安全的。