DevSecOps的六大支柱协作与集成

1．成功的 DevSecOps 协作和集成的指导原则

DevSecOps 是一种将安全性集成到 DevOps 流程中的方法。这确保了软件从开发过程的一开始就是安全、可靠和高效的。“左移”（Shift Left）是一个经常用来描述这种集成的术语。 要成功实施 DevSecOps，建立协作、沟通和持续改进的文化非常重要。领导层、产品、项目、开发人员、安全专业人员和运营团队无缝协作，确保业务连续性、IT 安全性，并创建和部署安全软件。以下是为 DevSecOps 打造有效的跨团队协作和集成文化的一些技巧。

1.1 领导层主动和有效的沟通

为了有效，文化转变必须自上而下进行。领导层的大力支持将促进实施DevSecOps 文化所需的协作。领导层最终负责制定业务连续性目标并将其传达给组织的其他部门。这反过来又会推动组织的资金和努力，以帮助实现领导层设定的这些目标 确保面对网络事件时业务连续性的规划至关重要，实施安全第一的架构需要多个团队之间的协作，以了解企业面临的各种内部和外部网络威胁，以及这些威胁对业务的影响。一旦充分理解了威胁模型，团队就需要制定策略，确定如何识别和保护组织资产、持续监控和检测网络威胁，以及在发现网络漏洞时响应和恢复业务资产。使用 DevSecOps 原则将安全性集成到整个IT 生命周期是保护和检测功能的关键。

1.2 没有孤岛

DevSecOps 的目的是将安全性作为一项共同责任整合到整个IT 生命周期中。这需要业务所有领域之间完全透明，愿意从开发过程的一开始就嵌入安全性，并坚信安全与质量一样，不是一个团队或个人的唯一职责，而是由组织的所有部门共同承担。领导层应努力确保有一个持续的安全反馈循环，并鼓励团队之间公开、频繁的沟通，努力将安全性完全集成到业务流程中。工程、安全和运营应携手合作，共同拥有 DevSecOps 流程的成果。获得最大投资回报的方法之一是最大程度地实现安全自动化。工程团队和安全团队之间的合作是确保这些自动化正常运行并正确实施的好方法。

1.3 自动化

利用工具在软件开发生命周期（SDLC）2 中实现安全优先设计的自动化可以节省时间并实时提供安全反馈。自动化可用于各种与安全相关的活动，例如：资产识别、持续安全监控、代码分析、漏洞扫描、渗透测试、事件响应和恢复以及在简化网络入侵期间的通信。

1.4 以人为本的方法

由于 DevSecOps 文化只有在许多不同团队的充分参与下才能成功，因此必须关注人员方面。持续学习的文化是确保您的团队能够保持DevSecOps 技术和流程前沿的最佳方式。 需要创造衡量成功的标准，需要庆祝取得的成就！这应该在人员、学习以及技术方面实施。团队的学习目标可以包括培训和认证，这些目标应包含在绩效计划和员工评审中。请记住，您需要为这些学习计划的实施提供时间和激励。还应该庆祝技术里程碑，以保持团队的积极性并确保 DevSecOps 计划步入正轨。技术成功衡量的一些示例包括交付时间、部署频率、可用性以及安全漏洞或攻击的频率。

1.5 组织背景的理解

各行各业的组织都是独一无二的，每个组织都有其独特的文化、结构和特点和运行的方法。因此，DevSecOps 方法的采用需要根据每个组织的具体情况进行精心定制。这不仅涉及采用合适的工具，更重要的是培养符合DevSecOps 原则的文化。围绕 DevSecOps 转型的讨论，过度关注工具选择和实施是很常见的。然而，为了让组织获得 DevSecOps 的真正好处，重点应该放在其基本原则上。

1.6 明确的所有权和责任

对于成功的 DevSecOps 计划，需要有明确的利益相关者RACI（责任分配矩阵）。对于每项任务，需要明确利益相关者对谁负责该任务，哪些团队负责完成任务，以及需要咨询哪些利益相关者并告知任务进度和完成情况。例如，软件工程师负责处置在其应用程序或产品的应用层发现的风险。基础设施工程师负责操作系统层面发现的风险的处置等。

2．基于角色的安全培训项目的原因和计划

安全是一项团队运动。每个组的成员都需要根据他们的角色进行培训。世界是一个复杂多样的地方，人们有各种各样的能力、技能和态度。在公司中，这种多样性通常被用来创建利用这些不同能力和技能的特定角色。DevSecOps 包含了一个多维度的方法，适用于组织和其产品提供的多个层次。鉴于个体在组织中有不同的角色，因此必须不断提供与他们的特定职责和职责相一致的培训。

2.1 安全培训计划的实施

在作为路线图的一部分推出安全计划时，必须记住，很多人可能没有足够的时间专注于安全。因此，确定您的计划目标是至关重要的。例如，该计划可以让产品所有者在新产品功能的发现阶段内置威胁建模。 一旦这些目标到位，建立组织的基线培训就至关重要。这将使成员熟悉安全和平台团队引入的工具和流程。可以发送定期的电子邮件通信或内部新闻简讯，介绍影响公司的最新安全趋势，以保持组织的更新。 预测某些团队成员会寻求更深入的见解，并主动提问或提出关于安全主题的改进建议。接受并视每个查询都来自“安全客户”至关重要。接受DevSecOps 意味着赋予开发人员安全地发布他们的工作的能力，而不是阻碍他们。对于那些希望深入研究的安全爱好者或“冠军”，可以考虑组成一个专门的工作小组。使用公司的协作工具来促进关于安全相关主题的频繁讨论，并至少每季度安排定期的内部研讨会或聚会。

2.2 如何获得安全培训计划的认可和支持

从多元化的业务负责人那里获得支持可能会很有挑战性，尤其是在很少有员工有专门时间处理他们组织内部的安全问题的情况下。然而，这不应该翻译成独立的努力。强调对领导层的必要性，即定期解决安全问题并与其他技术债务一起解决，以防止重大的安全事件发生。应向领导层强调，网络攻击可能对组织产生的数据丢失，客户流失，业务停机等影响。为获得安全培训计划的领导批准，向领导展示安全培训计划在减少组织中的网络事件方面的影响，这是通过网络意识的劳动力，健全的 devsecops 计划，以及组织应对网络攻击的更好准备。另一个挑战在于保持员工对安全培训计划的参与。一种经过验证的方法是定期举办安全会议，并每月留出 30 分钟与每个安全冠军进行1 对1 的互动。这些时刻提供了公开承认安全冠军贡献的机会，并在他们的角色的其他方面提供支持，例如让他们参与关键的安全决策，例如选择和实施新的工具，流程或政策。

2.3 如何衡量安全培训计划的成功

衡量培训计划成功的一个直接方法是跟踪完成安全培训的参与者数量，以及测量与新闻简讯的互动。此外，您可以进行现场和线下的安全测验，桌面演练和模拟培训课程，在这些课程中您可以评估他们的知识以及参与者在这种情况下会如何行动或思考。

3．交付流水线中的协作和集成

每个阶段都需要利益相关者之间保持沟通与协作，以帮助实现该阶段的目标。本节将逐一介绍每个具体阶段，并针对每个阶段确定参与该阶段的关键利益相关者，以及这些利益相关者之间为确保成功执行所需的必要沟通和协作。安全开发生命周期：策略、标准、控制和最佳实践，虽然这种视觉效果给人一种从一个阶段到另一个阶段的线性流动的印象，但阶段之间存在双向反馈循环。

3.1 安全设计和架构阶段

这个阶段是产品团队和架构师之间的跨团队协作，其中包括系统和安全架构师、开发人员和项目团队。 架构师和开发人员合作，将产品团队开发的产品愿景和产品需求文档 (PRD) 作为输入，并生成理想的系统高级设计(HLD)。实现理想的系统高级设计的步骤还应包括系统的渗透测试、红队、蓝队和紫队练习的计划工作。 架构师和开发人员在此阶段合作评估各种设计选择，并提出理想的设计来满足各种功能和非功能要求。 安全架构师为系统开发威胁模型，以了解每种设计选择的威胁向量、攻击面、安全风险和暴露半径。安全架构师还评估并考虑重用组织中其他团队成功使用的现有安全设计模式。

3.2 安全编码阶段

在此阶段，项目经理和开发人员合作，确保项目包含从安全设计和架构阶段实现理想架构所需的高级里程碑。 开发团队使用敏捷开发方法将这些里程碑分解为史诗、用户故事和任务。 每日站会和项目回顾确保开发步入正轨并向前推进，并且团队成员保持一致。 在代码开发过程中，开发人员使用安全编码实践、OWASP 等安全标准、组织编码标准和代码审查流程来协作和开发安全代码。 早期阶段的系统高级设计用于开发身份验证、授权、审计以及与构建系统、混沌测试、安全测试和监控工具集成的代码。

3.3 持续构建、集成和测试

在此阶段，开发人员、安全测试人员、质量保证测试人员、运营和架构团队协作开发测试自动化并将其集成到系统 CI 流水线中，以便持续测试系统的性能、质量、可用性、可用性和安全性 作为构建周期的一部分。开发团队使用来自代码覆盖率分析、QA 测试、SAST、DAST、IAST、容器镜像扫描、混沌测试、可扩展性和压力测试以及渗透测试的反馈和测试结果来解决代码和设计中的差距。 由于这些不同的测试练习而在系统设计中发现的任何差距都需要开发人员和架构师在系统高级设计中协作进行设计调整和修改。敏捷用于让产品和项目团队随时了解所需的任何其他设计变更和错误修复。

3.4 持续交付和部署

在此阶段，开发人员和运营人员协作为项目开发持续部署(CD) 流水线，并将其集成到组织使用的持续部署工具中。 团队共同努力，为系统设置持续监控和监控仪表板，以跟踪关键绩效指标 (KPI) 和警报。该团队还合作开发项目事件响应手册，以确保项目与事件响应平台集成，并制定第2 天支持的待命时间表。

3.5 运行时防御和监控

在这个阶段，开发人员和运营团队协作，确保系统在第二天的生产中顺利运行。运营和开发团队始终掌握项目 KPI 仪表板和安全事件，并共同解决系统警报和安全事件。运营团队通常是事件发生时的第一道防线。如果无法解决问题，事件将上报给开发团队。 事件发生后，通常会有一个事件的事后分析过程，架构、开发和运营团队聚集在一起，向高层领导简要介绍事件的根因分析(RCA)、事件的详细信息以及这一事件是否可以避免。 然后，此事件的事后处理是否需要修复系统中的设计和编码差距提供反馈。

4.新收购项目与 DevSecOps 交付流水线的集成过程

当一家新公司被收购时，安全团队需要了解其软件开发流程。这一点很重要，有两个原因：一是衡量其流程的成熟度，二是学习如何将其最佳地集成到现有流程中。收购方可以采取以下步骤。

4.1 收购后 60 天内

1. 编制一份所有源代码管理平台（Bitbucket、GitHub、GitLab、Subversion等）的列表。包括这些系统的管理员的名称。 2. 列出所有活跃的代码存储库 URL。整理每个代码存储库支持的每个应用程序和其他工件。包括像适用于每个应用程序和产品的产品经理和工程师负责人。 3. 列出被收购组织使用的编程语言及其比例。这有助于识别控制（扫描、代码审查等）方面的差距。 4. 确定使用了哪些工具/流程（如有）。5. 列出所有云帐户（AWS、Azure、GCP 等）和内部部署环境资源相应的所有者，以便与收购方的组织共享。 6. 安置必要的设备，将所有安全扫描结果和可用日志作为新的数据源添加，发送到收购方机构的安全运营中心（SOC）。 7. 与被收购方的高管、产品经理和软件工程师讨论，从工作优先级的角度来看，如何处理安全问题。 是否在每次冲刺中都分配了时间、金钱和人员来满足安全和架构现代化 © 2025 云安全联盟大中华区版权所有 23要求？ 根据上述信息，确定与收购方流程和优先级方面的差距。注：现阶段，不应对被收购方现有的软件开发流程进行任何变更，除非该现有流程的风险超过收购方的风险偏好。

4.2 收购后 180 天内

1. 使用 DevSecOps 成熟度模型来衡量被收购方的各方面。应使用与收购方相同的模型。流行的 DevSecOps 成熟度模型如下： OWASP DevSecOps 成熟度模型  云原生计算基础成熟度模型  软件保证成熟度模型 2. 根据成熟度模型的结果来制定计划，纳入收购方的DevSecOps 计划并促其达成。

4.3 至少每年一次

1. 评估并继续完善整个组织的 DevSecOps 计划。每个团队都处于不同的成熟度水平，并有独特的途径来改进其DevSecOps 实践。改变现有的软件开发过程应该在每个团队的实际基础上进行探索。 2. 评估和报告不同的 DevSecOps 成熟度水平（团队、产品、部门等）。

编辑：999感冒灵