DevSecOps 战略指南 ： 平衡速度和安全性

DevSecOps战略指南： 平衡速度和安全性 随着现代软件彻底改变了业务运营和市场竞争，满足积极的上市时间要求的压力从未如此之大。对有效安全措施和可靠软件的需求随着快速生产的需求而增长。但是，快速的开发和发布周期以及日益复杂的网络攻击的结合暴露了一个核心挑战：如何在不牺牲安全性的情况下大规模开发和交付高质量的软件。 关键是将应用程序安全测试(AST)纳入软件开发生命周期(SDLC)和DevOps工作流程的所有阶段。这听起来很简单，但挑战仍然存在 ，包括管理大量的压倒性或冗余的发现，不必要的测试，可能会减慢管道，对风险的主观评估，以及跨团队的各种级别的安全意识和安全能力。 安全、开发和DevOps团队的贡献者都必须明确定义角色，以保护他们创建、摄取和推动他们的管道的数字资产。这样做可以随着组织的发展而扩展，从而使您能够在未来蓬勃发展，但它需要一种协调一致的应用程序安全性方法（AppSec）。传统的AppSec方法“坚持”测试，分类和对开发的补救，无法满足现代网络犯罪分子带来的危险，也无法满足现代DevOps的工作流程需求。 |synopys.com|2 |synopys.com|3 在不影响安全性的情况下保持发展速度。 履行DevSecOps承诺：快速安全 需要一种新的AppSec方法-一种在不阻碍公司增长的情况下处理业务风险的方法，消除速度和安全性之间的神话权衡，并实现DevSecOps承诺。为了实现这一愿景，组织必须创建一个高效、有效的DevSecOps战略，其中包含三个关键思想。 •跨SDLC和CI管道建立应用程序安全性以进行连续测试 •在不损害安全性的情况下保持开发速度 •优化工作流以提高团队的风险意识和安全能力 这允许将安全机制集成到每个级别的SDLC中，并提供对统一DevSecOps至关重要的可见性和控制。它还使安全和开发团队能够对风险和补救优先级进行客观评估，并告知跨工具和角色平稳运行的工作流。 首先，让我们研究将安全性集成到DevOps中的最大挑战之一：每个团队使用的各种工具和系统。 到处转移安全性：持续快速测试 从智能手机上的应用程序到为组织，行业和政府提供动力的系统，软件已成为我们日常生活中必不可少的一部分。但是软件不是单一的；它是通过协议和系统链接在一起的组件的集合，可以实现操作和数据传输的统一执行。 贵公司的软件，无论是内部使用还是外部提供给客户和合作伙伴，都是由您制作的代码、您借用的软件和您购买的软件组成的。第一个是由开发人员构建的，以满足公司的独特和个性化需求，第二个是由开发人员用来加速开发的资产组成。第二组组件由开源软件和第三方库组成，可以根据许可限制使用、更新和分发。最后，组织从外部供应商购买第三方许可的软件二进制文件，以纳入或与他们的项目和系统一起运行。 这些软件类别中的每一个都可以使用各种框架和技术来构建，这些框架和技术将代码和组件转换为操作程序。包括用于划分软件功能元素的容器、用于敏捷扩展的微服务、用于定义云资源设置的基础设施代码(IaC)模板、API协议和其他功能。 随着每种新技术的发展，建立软件安全性变得越来越复杂，因为测试和风险分析的机制因技术而异。因此，保持高生产率和快速发布周期变得更加微妙的平衡，每个额外的测试周期都附加到DevOps工作流程中。对于大多数组织来说，AST都有一个基线，它应该构成DevSecOps战略的基础。 •检测专有代码中的弱或不安全的编码实践，并在开发人员桌面上尽早这样做，以加速补救并避免将问题推向下游 •识别开源组件中的已知漏洞，包括构建期间可能在不知情的情况下添加到项目中的可传递依赖项 •在运行时验证数据和应用程序函数的安全性，并检测正在运行的编译资产中的潜在恶意活动 这些AST机制中的每一个都可以识别不同技术中的风险，并为DevSecOps的贡献者提供关键级别的洞察力。但是，风险检测仅是建立安全性所需的一半-您还需要有效的风险补救。从历史上看，风险检测被降级为AppSec团队，而补救则被降级为开发团队。 然而，在协同的DevSecOps计划中，这些职责相互关联，AST成为一个持续的事件，促进开发、安全和DevOps团队之间的闭环通信，因为问题被优先考虑补救并通过新的或修改的代码解决。有效地做到这一点需要将每种测试技术和安全机制纳入SDLC、CI管道和其他DevOps工作流程。这种集成的完成程度将影响每个有贡献的团队的绩效和成功指标。 消除摩擦：统一DevSecOps的集成和自动化 为了完全实现DevSecOps，每个测试都需要集成到已建立的工作流程中，以确保触发相关测试，同时避免可能延迟软件交付的不必要测试。有效的DevSecOps还需要基于客观安全标准自动执行基于风险的策略。这提供了一些关键功能，包括 •集成安全门，可识别源头或附近的风险 •安全保障措施可识别风险，因为它们从无关或非法的工作流程和管道进入主要项目 •快速、清晰地将优先的风险分析直接传达给开发人员以进行补救 •与组织一起发展的灵活且可扩展的DevSecOps 自动化是DevSecOps流程的重要组成部分。它的核心是允许AppSec、开发和DevOps团队以最少的人工干预来执行日常和必要的任务。对于DevSecOps，自动化必须基于深思熟虑的、知情的策略、风险容忍度阈值和专门构建的安全门，这些安全门既能满足安全团队的需求，也能满足开发团队的需求（例如。Procedre、检测时间、补救时间、代码发货截止日期)。正确定义的AppSec策略是实现您的目标并使集成的自动化DevSecOps成为可能的基本机制。 由于每个团队在结合安全标准定义策略方面都发挥着独特的作用，因此即使参与方不参与项目或冲刺(sprint)，DevSecOps计划也将反映一致、统一的组织愿景。违反策略的行为会警告利益相关者项目或工作流的某个部分存在问题，并提醒他们必须执行预定义的操作。 建立策略和标准后，您可以跨SDLC和CI管道集成AppSec。从这个意义上讲，“集成”应定义为将AppSec工具连接到现有的开发、安全和DevOps系统和工作流。这包括 •根据管道活动、代码更改或检查到源代码管理(SCM)和二进制存储库中的新资产触发AST扫描，以加快风险检测 •通过问题管理工作流程和工具提供优先风险分析和修复指导，以加快补救速度 •利用DevOps工具（例如GitHub操作、GitLab模板）中内置的功能，支持自动化测试、注释和修复拉取请求 •阻止脆弱资产的推广或破坏违反安全策略的管道构建，以防止下游出现问题 通过将这些类型的安全性和DevSecOps措施集成到现有开发和DevOps工具、流程和软件之上，您可以使开发人员更高效地工作，更快地解决问题，避免后期重构代码，并提供更安全、更高质量的软件，从而最大限度地降低组织的风险。 当然，鼓励开发人员接受新的工具和平台可能具有挑战性，特别是当这些工具可能被视为与开发人员的日常任务无关时，许多AppSec测试工具可能就是这种情况。利用集成，使安全团队能够无缝地分析软件，作为现有开发工作流程的一部分，并在其IDE，协作工具和问题管理工作流程中直接向开发人员提供漏洞信息，大大减少了作为DevOps一部分建立安全性的障碍，并消除了关键贡献者之间的摩擦。 获取PolarisbySynopsys的免费试用版现在尝试 |synopys.com|4 满足开发人员的需求：培养安全能力 开发人员被期望快速工作，他们中的大多数已经定制了他们的IDE和工作流程以满足他们的个人需求。尽管增加了DevSecOps程序的复杂性，但这些细致入微的开发环境和管道都有一个共同的因素，可以帮助建立更统一的安全原则：与之互动的开发人员。 如上所述，在SDLC和CI管道中集成自动化AST的机制有助于建立安全门和制衡系统，以识别尽可能接近其起源的潜在安全问题，无论其进入点如何。但是，您可以通过培养开发人员的安全能力来大大提高组织保护其数字资产的能力，因为开发人员通常具有不同的安全编码技能。2023年SANS报告显示，近21%的组织认为 ，如果他们有一个结构化的开发人员安全培训计划，他们对开发人员的安全培训是不够的。然而，只有31％的人认为开发人员安全培训计划是成功的DevSecOps计划的关键成功因素。 简而言之，您可以通过在开发人员之间建立更高的安全性标准来阻止新问题的引入，并加快对现有问题的补救，这些标准将其作为日常任务的一部分来实现。 •作为开发人员工作流程的一部分，访问清晰、优先的安全风险洞察，确定要解决的最紧迫问题及其在源代码和文件系统中的位置 •详细的补救指导，告知开发人员解决检测到的问题的最有效和最有效的方法，即使他们缺乏安全知识或经验 •实时风险意识和修复建议，作为开发人员在其首选IDE中的代码，提供“安全拼写检查”体验，以帮助开发人员在合并或构建之前编写更安全的代码 安全意识和安全能力的结合将集成的DevSecOps计划从自动触发的安全门系统提升为敏捷风险检测和快速解决方案的协调方法，随着时间的推移变得更加高效。 •相关的开发人员安全培训和安全编码教育，与开发人员的项目、技术和更大的业务需求保持一致，培养随着业务发展的安全能力 安全意识和安全能力的结合将集成的DevSecOps计划从自动触发的安全门系统提升为敏捷风险检测和快速解决方案的协调方法，随着时间的推移变得更加高效。基于为您 的组织、技术和法规标准量身定制的最佳实践的安全功能有助于用跨项目和团队的更客观的评估来取代开发人员对“安全”的主观评估。 当检测到问题时，开发人员应该收到有关如何解决此类问题的明确建议。这不仅有助于解决这个问题，而且建立了开发人员将来可以遵守的标准。这应该通过适用于每个开发人员使用的技术、语言和框架的规定安全培训来加强，最大限度地提高对开发人员学习工作的影响。此培训应作为现有开发工作流程的一部分使用，与安全测试相关的主题学习轻松使用，并通过与问题管理工具和IDE的集成直接访问，例如。 最后，重要的是在开发人员编写代码时激活这些安全功能，并实时通知他们在IDE中引入的新问题。您可以通过在开发人员终端上本地进行的安全测试来实现这一点。他们的代码可以审查编码的弱点(例如Procedre，跨站点脚本错误，没有定义的超时）以及包含具有已知漏洞的开源组件或库。 此本地测试不应取代AppSec团队的基于管道的测试或集中式安全测试。相反，它应该作为一种机制来提高开发人员对问题的认识，这些问题通常在开发早期更容易解决，并且可能在下游应用程序安全测试期间延迟或分散安全团队的注意力。因此，好处是双重的：您可以加快修复时间并减轻AppSec团队的负担，而无需偏离已建立的开发工作流程。 实现DevSecOps：人员、流程和规划 DevSecOps依赖于组织内各种角色的成功协作和合作。虽然AppSec团队可能会继续拥有组织软件的安全风险状况，但他们实施安全措施和解决检测到的问题的能力取决于开发和DevOps团队。许多组织在构建DevSecOps策略时停滞不前，因为他们无法识别和纳入对每个贡献团队都很重要的成功标准和性能指标。 对于大多数人来说，跨团队讨论将产生类似于以下内容的标准和性能指标列表： •检测的时间 •补救时间 •AppSec测试中的误报 •补救成本 对于现代DevSecOps，此列表并未提供对安全计划状态的可操作见解，也没有考虑到集成的AppSec计划与组织一起发展的固有需求。对速度的担忧可以通过在SDLC中扩展AppSec集成的广度和深度来解决，并通过实施基于策略的自动化来解决。假阳性率取决于所使用的AST工具和此类测试的发生点。补救成本的成本可能会受到修复与问题根源的接近程度或负责问题的开发团队的熟练程度的影响。 考虑到所有这些，确定每个有贡献的团队的成功标准以及可能影响这些标准的DevSecOps机制非常重要。通常，无论每个团队评估的关键因素是什么，任何给定贡献者评估DevSecOps计划的状