DevSecOps 的好处包括：

• 各个 IT 团队之间，特别是开发人员、运维和安全团队以及其他利益相关者之间更好的沟通和协作。导致 更好的生产力 。
• 简化软件开发、交付和部署过程 —— 由于自动化，停机时间减少，发布时间加快，基础设施和运维成本降低，效率提高。
• 通过实施零信任来减少攻击面，这也限制了横向移动，从而防止攻击升级。具有现代行为预防能力的持续监控进一步促进了这一点。
• 安全优势。通过对每个请求的验证监控、警报和反馈机制来提高安全性，因为可观测性是代码。这些将在以下段落中详细描述。具体的能力包括：
  • a. 运行时：杀死恶意容器。
  • b. 反馈：由于一个错误的程序更新了代码并重新触发了管道，所以反馈到了正确的存储库。
  • c. 监测新的和终止的服务，并调整相关服务（如服务代理）。
  • d. 启用安全断言。不可绕过 —— 通过在同一空间执行的代理、安全会话、强大的认证和授权以及安全的状态转换。
• 启用持续授权操作（C-ATO），在本节末尾详细描述。 对每个请求的验证和上述的反馈机制将在下面进一步描述：
• 每个请求的验证。来自用户或客户端应用程序（服务）的每个请求都要经过验证和授权（使用 OPA 或任何外部授权引擎或 接纳控制器 等机制，它们是平台的组成部分）。授权引擎提供特定于应用域的策略执行，而接纳控制器则提供与特定平台的端点对象（如 Pod、部署、命名空间）相关的平台特定策略。具体来说，接纳控制器会进行突变和验证。突变的接纳控制器解析每个请求，并在将其向下转发之前对请求进行修改（突变）。一个例子是为没有被用户在请求中设置的规格设置默认值，以确保在集群上运行的工作负载是统一的，并遵循集群管理员定义的特定标准。另一个例子是为 Pod 添加特定的资源限制（如果资源限制没有为该 Pod 设置），然后向下转发（如果请求中没有这个字段，通过添加这个字段来突变请求）。通过这样做，集群中的所有 Pod 将始终有一个根据规范设置的资源限制，除非明确说明。验证接纳控制器会拒绝那些不遵循特定规范的请求。例如，没有一个 Pod 请求可以将安全上下文设置为以根用户身份运行。
• 反馈机制：
  • 一些在运行时发现的问题的补救措施可能需要在源代码中处理或修复。应该有一个流程，针对正确的代码库自动打开一个问题，以修复问题并重新触发 DevSecOps 管道。
  • 向应用程序托管平台提供反馈回路（例如，杀死包含恶意容器的 Pod 的通知）。
  • 通过监控应用程序的配置，提供主动的动态安全（例如，监控引入到应用程序的新荚 / 容器，并生成和注入代理以照顾其安全通信需求）。
  • 启用关于应用程序的几个安全断言：不可绕过（即在所有使用场景下始终执行的策略）、整个应用程序代码的受信任和不受信任部分、没有凭证和特权泄漏、受信任的通信路径和安全状态转换。
  • 启用关于性能参数的断言（例如，网络弹性参数，如在故障、冗余和可恢复性功能下继续运行）。
  • 总的来说，更快地吸收反馈意见，使软件得到更快的改进。