《2024DevSecOps建立合规方案.docx》由会员分享，可在线阅读，更多相关《2024DevSecOps建立合规方案.docx（33页珍藏版）》请在三一办公上搜索。
1、DeVSeCOPS建立合规方案目录前言81简介91.1 目标101.2 读者群体102评估112.1 与云服务提供商的共担责任112.2 即时评估和持续评估133心态151.1 使用价值流映射的合规性151.2 合规目标转化为安全措施184 .工具224.1 拥抱即代码as-Code模型224.2 拥抱DevSecOps方法进行测试244.3 追踪开源风险274.4 安全护栏294.5 模式和模板335 .总结35参考文献37词汇表40缩略语41支柱1：集体责任（2020.02.20发布）2支柱2：培训和流程整合支柱3：实用的实施支柱4:建立合规与发展的桥梁（2022.02.03发布）支柱5：
2、自动化（2022.07.06发布）3支柱6：度量、监控、报告和行动1简介鉴于软件开发范式和实践的快速发展，整体安全合规活动与软件开发过程的结合已成为一项挑战。合规团队已经习惯于依靠流程和控制到位来证明（安全性）。然而，大多数认同DeVOPS观点的工程师认为证明应在代码中，而不在流程或文档内。DevSecOps实践旨在结合合规性与开发，需要安全团队和软件开发人员之间的协作（集体责任4）努力。DevSecOps模式中的合规性目标是提高应用程序或环境的整体安全性，同时减少验证系统达到安全目标及合规性的所需工作量。本文探讨的方法允许DevSecOps团队将安全性和合规性要求转化融合到开发周期中，达到以
3、下目标： 软件开发人员可操作性 客观可度量 实用性的降低风险本文还探讨了安全和开发团队进行系统性协作的要求、方法和建议，分为三个部分，如图1所示。合规性和开发功能（特性）应考虑以下要素： 评估：一种划分和评估的方法，对运营影响最小 思维方式：关于如何把合规性设计并实施到应用程序中的思想和实践转变 工具：安全工具的不同实践，可以为合规性要求提供保证本文和图1中对利益相关者的引用有两个角色，“合规”和“开发”： “合规”被确定为对监管或行业合规标准的管理，这些标准被下发到信息安全一以及法律、风险和审计一等团队，以形成塑造组织业务运营的要求和政策。 “开发”是对应用程序的设计、配置和构建有影响的工程
4、师和产品团队成员（包括开发人员、平台工程师、架构师和业务分析师）。开发软件工程师平台工程师测试人员业务分析师评估：L与云服务提供商共同承担责任2 .时点评估与持续评估思维方式：3 .价值流映射（VSM）4 .确定合规目标5 .将合规目标转化为安全措施工具：7 .采用“ as code 模型8 .采用DeVSeCoPS方法进行测试9 .跟踪开源风险10 .安全护栏11 .模式和模版信息安全DevSecOps 实践审计法务风险图1.连接合规与开发的框架1.1 目标本文提供了一些指导，即确保通过识别合规性目标，将它们转化成适当的安全措施，并通过将安全控制措施以自动化测量测试等方式清晰透明、易于理解地
5、嵌入到软件开发生命周期中的关键节点，以弥合合规性与开发之间的差距。本白皮书未确定合规性目标的来源，且不比较DevSecOps的标准或指南。（说明：合规性可以来自企业内部也可以来自企业外部）1.2 读者群体本文的目标读者包括涉及安全风险、信息安全和信息技术的管理和运营岗位工作人员。包括CIS0、CIO,尤其是涉及以下职能领域的个人：自动化、DevOps,质量保证、信息安全、治理、风险管理、内部审计和合规。2评估评估通常是测量DeVSeCoPS流程和控制的成熟度和有效性的第一步。组织评估其应用程序和DeVSeCoPS应用情况的主要考虑因素是： 与云服务提供商的共担责任：确定风险转移的位置，明确云客
6、户应在何处应用控制或寻求保障。 即时评估与持续评估：确定适当评估的方法，研究如何实现自动进行持续审查以提高调查结果的准确性。2.1与云服务提供商的共担责任在大多数应用程序的部署使用中，云环境的设计和操作都对DevOps和站点可靠性工程(SiteReliabilityEngineering)至关重要。云安全取决于基础设施，因此云安全控制和责任共担管理在DeVSeCOPS实践中势在必行。当企业将合规性目标映射到安全要求时，了解云客户在选择解决方案和技术时的责任非常关键。安全工具和解决方案必须与技术保持一致，如容器化工作负载、虚拟机、云原生平台服务的配置状态。云服务提供商(CSP)和云服务客户(CS
7、C)应在服务级别协议(SLA)中同意并记录共同责任，这样CSC能够明确了解CSP的服务条款、优势和缺陷。CSP通常会公开提供此信息。图2中的通用模型展示了CSC和CSP之间从本地部署到SaaS的职责划分范围。本地/公有云私有云基础设施即服务平台即服务软件即服务(IaaS)(PaaS)(SaaS)操作系统虚拟网络虚拟化层服务器物理网络云服务客P(CSC)责任云服务蠢商(CSP)R壬图2混合云中的责任共担5DevSecOps活动应反映出图2中的责任共担模型。例如，提供IaaS服务的CSP可以确保堆栈较低层(例如，hypervisor及以下)的安全，而较高层(例如，网络层及以上)的安全则由CSC负责
8、。一旦组织能够识别他们所使用的服务和不同的云部署模型，他们就可以开始考虑“下一步”的安全活动。2.1.1下一步在大多数情况下，云客户负责应用程序安全控制和云环境的管理。开发团队应该传达他们对使用云服务的应用程序的需求应该确定依赖CSP的控制、可以评估CSC要求，并将其打包加入补救的活动/迭代阶段中。如果责任属于CSP，CSC应获取第三方对CSP的评估保证，如SOC26报告或CSASTAR认证。云客户应审视CSP提供的保证，以确定控制和流程的适当性，并在需要时实施补偿控制。安全和合规职能团队应与开发团队合作，根据云部署模型准确地识别职责。安全控制和流程应该由安全和合规职能团队根据现有的组织策略、
9、安全框架、检查表和模板周期性开展审查。如果责任属于CSP,合规团队可以审查Sc)C2报告或CSASTAR,以确定CSP采取了的适当控制措施。2.2即时评估和持续评估评估是所有组织用于理解当前控制措施和流程的成熟度和有效性的通用方法。然而，伴随着敏捷或DeVOPS方法中快速的变化和部署速度，人们对评估的频率和相关性的提出了疑问。即时评估7可能很慢，可能需要几个星期甚至几个月。从开始评估到完成报告的期间开发和部署环境可能不断变化。与此同时，即时评估可以提供一个应用程序及其基础设施安全状况的整体视图，并可以与其他活动，例如渗透测试和隐私数据审查等相结合。为应用程序和基础设施引入安全开发人员工具可以帮
10、助对组件进行分类，以便单独审查,在开发和部署阶段就可以识别和纠正问题，这消除了对即时评估的依赖。以下工具的使用，举例说明了如何为持续评估对应用程序进行分类和扫描： 软件组成分析：识别、报告、修复和标准化高风险开源工具使用的机会。这可以在构建阶段进行应用及处理，并在即时评估之前达到合规要求。 静态分析：一个扫描源代码的弱点和漏洞的机会。这将帮助开发人员在构建阶段编写安全的代码，并对大型代码库扫描发现的问题进行补救。 基础设施即代码（IaC）分析：提供了根据云合规标准扫描代码的云构建（codedcloudbuilds）的机会。这有助于工程师在构建阶段解决云上的安全性问题，而不是依赖即时评估。 云态
11、势管理：一种针对行业标准和指南，全面而持续地对云构建和环境进行扫描的通用方法。云态势管理甚至可以取代即时评估。要在构建时进行扫描和执行整体评估之间取得合适的平衡，取决于团队如何在不影响部署速度的情况下快速地完成完整扫描。代码扫描（例如，IaC分析）对于在构建阶段对实体（应用程序/平台/基础设施）的审查是很有效的，并且可以降低漏洞和安全弱点被写入代码的可能性。这将帮助组织实现安全左移，减少部署后的安全补救工作。然而，需要理解的是，与部署后扫描（例如，云态势管理）相比，在构建时进行扫描并不总能得到完整和全面的发现。一个说明代码扫描完整性的例子是Bridgecrew（一家IaC供应商）对其开源IaC
12、分析工具“Checkov”的研究。Bridgecrew透露，只有大约一半的行业云安全基准控制（由互联网安全中心（CIS）推荐）在IaC分析中得到了解决（见图3）0这并非反映“Checkov”的质量，而是反映了主要CSP在构建阶段的安全问题规模以及评估的完整性。Ch9ckov1.0Checkov2.0图3.CheckovCIS基准测试覆盖率8代码扫描的分类并不能取代对即时评估的需求；然而，这确实减少了对即时评估的依赖。组织现在可以在构建时解决问题，比在部署到生产环境前评估中发现的严重安全问题更为有利。当组织应用方法来执行持续的DeVSeCoPS评估时，可以利用即时评估提供完整的、统一的、完全集成
13、的审查，同时知道在构建过程中已经解决了大量安全问题。3心态组织可以通过工具直接快速地解决风险，但是他们很容易忽略适当的心态（思维模式）在DeVSeCOPS转型中的重要性。心态是一种方法，以一组活动的形式由安全和产品的利益相关方（例如，软件开发人员）所采用，通常可以使两个孤立的团队更紧密地联系在一起。有助于弥合安全和软件开发之间价值冲突的关键考虑因素有： 价值流映射（VSM）：确定团队、交付时间和处理时间，以了解工作流如何从想法变成客户输出。这提供了一个通过手动或自动化来识别安全参与的机会。 将合规目标转换为安全措施：如何将目标打包成供开发人员使用的安全措施。 流水线监控：在不妨碍生产力的情况下
14、对开发人员活动的控制措施进行监控和维护。3.1 使用价值流映射的合规性虽然合规和开发活动可以在它们的安全目标上保持一致，但传统的合规方式一一冗长的即时评估一严重依赖于文档。传统方式与DevSecOps的快速、敏捷工作和持续交付的特性不能很好匹配。因此，在考虑应用安全控制之前，了解工作在应用程序开发生命周期中的工作流程非常重要。价值流映射（VSM）是一项用于理解应用程序上下文的有用技术。如图4所示，VSM可以包括以下组件： 利益相关方：负责的团队和个人。 活动：在某阶段执行的通用活动。 交付时间：从一个工序接收一件工作到把该工作交给下一个下游工序的时间。 处理时间：指完成一项工作所需的时间，前提
15、是执行这项工作的人拥有完成这项工作所需的所有必要信息和资源，并且可以不间断地工作。 准确完成百分比（C/A）：上游流程接收到可以使用且无需返工的内容的百分比。顾客 发布规划与估计设计与分析开发与开发测试（包括测试自动化）设计批准0展示和用户验收成果变更批准图4.VSM示意9通过了解VSM过程中应用程序的构建和部署活动，组织可以开始识别和规划适当的安全活动和工具。DeVSeCoPS是一种共同承担的责任】。，建立在将安全实践集成到整个构建阶段和部署流水线的概念之上（如下图5所示）。安全开发生命周期：政策、标准、控制和最佳实践虽然这个图像给人种从个阶段到另个阶段的线性流动的感觉，但各阶段之间存在双向
16、反馈机制阶段触发叁安全活动安全设计和架构应用或功能设计威胁建模安全基线和评估控制安全编码代码拉取、克隆或提交SAST薛态应用安全IDE插件集成SASTSCA软件组成分源代码审查持续集成对源代码库实开发者代码持续构建、集成和测试构建和集成SAST 打包容器和镜像扫描模糊测试DAST动态应用程序安全IAST交互式应用程序阶段和测试测试安全测忒持续交付和部署发布构件和镜像库.镜像扫描签名 持续的工件和镜像库扫描运行时防御和监控实例化基础设施持续地系统、容器和网络漏洞扫描系统、容器和网络应用程序测试和模糊测试海洞监控RASP运行时应用程序自我保护渗透测试管理手动执行在开发人员和操作人员所用丁自动评估安
17、全发现安全治理、报告和KPI.选择的工具中，根据情况和缓解的遥测技术和仪向他们提供即时反馈.图5.CSA的DeVSeCOPS交付流程U通常安全和合规性活动是手动进行的，并形成安全质量门禁，这使得过程繁重并有可能影响到交付时间。为了应对这一挑战，合规性必须是“持续的”，这样才能不断审查安全性并将其集成到代码中。作为交付流水线的一部分，证明符合共识的安全要求的能力将安全性集成到整个开发过程中。（注：短语“organizedintogates”指的是软件开发中的一种做法，即将安全和合规性活动作为检查点或“门禁”进行组织，开发项目必须通过这些门才能进入下一个开发阶段。）VSM的过程可以借助测量每个安全
18、措施的工作量和运营影响，来实现这一目标。通过识别VSM中的端到端流程，组织可以将合规性/安全性要求包含在需要改进、进一步控制和自动化的领域。一旦价值流映射得到优化，组织就可以开始使用静态分析、策略即代码和依赖性检查等方法来实现自动化合规。本文探讨了将自主安全措施嵌入在交付流程中的不同方法，这可以帮助弥合合规和开发之间的鸿沟。DeVSeeOPS交付流程本身是将安全应用于产品的基础。组织应该寻求在图5的“安全活动”部分建立实践，持续支持架构工件（如加固指南和模式），以提供评估的参考点。3.2 合规目标转化为安全措施DevSecOps的一个目标是“左移”安全，如将关键的安全控制作为应用程序开发过程的
19、一个组成部分，而不是采取在交付点进行回顾性的审计活动的传统方法。合规性的目标、政策、流程和控制通常源于合规框架、治理、风险和信息安全团队。对于大多数将合规与行业指南（例如S270012l或NlSTCSF13）相匹配的具有成熟安全功能的组织来说，并不是新鲜事。从传统的合规性过渡到更加动态的方法，需要打破安全合规和软件开发团队之间的隔阂（包括采用DeVOPS和网站可靠性工程的团队），将对DeVSeCoPS的理解作为一种新的方法论融入文化和技术】，安全和合规利益相关者（例如信息安全）、架构和软件开发团队应紧密合作，定义明确的合规目标。在实践安全活动和达成合规目标的控制之间应有精确的映射。这些应被整合
20、到交付流程中，并考虑生成自动和公开的报告。可以让安全和合规性利益相关者参与到正在进行项目的迭代会议实现安全目标到安全措施的转化： 计划会议以确定整个应用开发过程中的必要工具和安全要求/控制； 提供对安全/控制变化迭代的更新建议，以帮助将合规要求引入应用程序的设计和构建中； 确定应用程序是否需要额外的安全措施。为软件开发人员建立安全合规迭代和用户需求是将安全纳入软件开发的有效方法。现有的安全合规要求、组织政策、行业准则和标准可以作为参考，这需要项目利益相关者之间的合作才能实现。类似INVEST这样的方法可以帮助创建用户安全需求和任务，这些任务应该是： 独立：应该是自成一体的 可商议：应该留有讨论
21、空间 有价值：必须为利益相关者提供价值。 可估计,应该能够估计规模。 足够小：能够确定计划、任务和优先级 可演!试：应该能够被测试。通过内部审计和治理，可以更好地向业务利益相关者展示安全合规用户需求、迭代和任务被设计到代码并配置到组织批准的安全控件中。你好,Gustav.从现在开始.所有的用户需求都必须满足INVEST的标准，经理图6.1NVEST用户需求16在合规性和开发人员之间建立的桥梁不应该是单向的。安全策略应该映射到开发人员和操作人员可以完成的原子级技术需求。软件开发人员、架构师和DevOps工程师应及时提供完成状态的反馈，以便编写信息安全策略的安全合规团队能够了解SDLC当前阶段或迭
22、代的安全态势。创建安全模式和加固指引将有力支持安全合规活动。（注：INVEST用户需求指的是应用敏捷用户故事的方法针对用户提出的需求，在进行需求梳理时需要左移考虑安全的问题。）3.2.1 流水线监测软件开发人员组可以在短时间内生成大量代码和应用程序更新，并迅速将它们提交到生产环境。这些活动为经常部署软件功能的组织创造了巨大的业务优势，通常分类如下： 持续集成（ci）：频繁提交和合并新代码和代码更改到编码存储库，这些存储库通过创建构建并针对该构建运行自动化测试来验证。 持续部署（CD）：将代码自动部署到环境中的过程，包括自动扫描、测试和构建活动。尽管执行DeVOPS的开发团队间独立自主和责任分担
23、为质量和速度方面带来了益处，但如果缺乏对角色的控制则会带来安全风险。例如连续的快节奏活动增加了人为错误和恶意内部攻击的风险，例如，糟糕的编码实践或可利用的逻辑漏洞。这就是为什么CI/CD流水线应该包括所有操作的清晰和不可变更的审计跟踪。审计跟踪通常在CSP环境中本地提供。在部署代码并嵌入度量以确保不可抵赖性时，证明操作的痕迹是至关重要的。组织的目标应该是实现对应用程序和CI/CD流水线上的操作的监控。可以包括以下步骤/操作： 在构建和集成时，应建立接入控制，以防止未经授权合并到主分支或生产环境。用户不应有权限修改或覆盖接入控制策略。部署应该只引用被批准的主分支。 应商定并实施日志保留、轮换、存
24、档和删除的策略C在可能的情况下，日志应归档在不同的环境中以便出于法律目的保留。 为了简化审查和管理审计跟踪，应根据事件标记日志并集中汇总，以减少人为错误并提高审查日志的速度。标签是根据事件的修改、部署和相关环境创建的。 为维护日志完整性，访问日志数据的用户账户应为只读且防篡改，并根据具体情况授予人员访问权限。识别和监控可以防止识别篡改日志的恶意活动。这也可以通过使用一次写入多次读取(WORM)兼容的存储机制来实现，该机制可以防止数据被删除或覆盖。4工具工具通常是在应用安全控制和措施时发挥价值的。工具可以帮助引入安全检查、扫描和数据管理，并在部署流水线中使用触发器实现自动化一一这些工具可以是专有
25、的或开源的。工具采购时可以考虑以下关键因素： 采用“as-Code”模型； 采用DevSecOps方法进行测试； 跟踪开源风险； 安全护栏； 模式和模板。4.1 拥抱即代码as-Code模型代码质量不仅仅与软件开发人员有关；可以使用工具来提高质量并将策略检查应用于集成开发环境（IDE）中的代码，这些代码可以应用于源代码和基础设施即代码（IaC）o基础设施即代码（IaC）消除了通过控制台和手动任务提供的传统基础设施，而是通过代码提供基础设施。IaC可通过云服务提供商（CSP）（例如AWSCIOUdFOrmatiOn）的原生工具或独立第三方供应商IaC功能（例如Chef、AnsibleTerraf
26、orm）实现。IaC的使用包括自动化、版本控制和治理。此外，当与合规性即代码（CaC）/政策即代码（PaC）相结合时，组织可以将其合规性要求直接融入其IaC模板和清单中。这些合规性要求可能来自适用的监管框架、组织安全策略或两者的组合。随着云部署变得愈发自动化和灵活，使用TerraformPUPPet和Chef等工具，在IaC上针对云的“合规即代码”实践已成为部署云资源的实际方法。如图7所示，IaC是使用可编程基础设施大规模自主构建云和本地环境的过程。可以将IaC代码视如源代码一样，这样它就可以在存储库中进行版本控制、测试和管理。基础架构即代码图7.作为代码的基础设施工作操作流17作为代码的合规
27、性可以使用IaC的工具和插件来实现，其中云资源在脚本中配置并部署在多个环境中。IaC安全插件可以识别基础设施（例如Chef、Puppet、TerraformAnsible）并部署相应的安全分析以促进正确的编码语法和安全代码（例如ansible-lintcfn.nag,cookstyleFoodcriticpuppet-lintCheckovTerrascan）。IaC的开放策略代理（OPA）用于创建和修改云环境，并为OPA期望基础设施即代码的行为方式定义了一组策略。OPA中设置的策略为软件开发人员、DevOps/DevSecOps工程师和架构师提供了机会，以证明云上的代码符合记录的息安全策略（
28、即，有机会在代码中执行自动检查而不是手动审查）。通过将合规性构建到DeVoPS流水线中，产品团队可以提高灵活性，同时减少重复工作以提供对合规性违规的持续检测和补救叫CaC/PaC也可以通过集成开发环境（IDE）在源代码级别实现。IDE可以通过Iintingv实现这一点使用静态代码分析工具来标记编程错误使用SOnarLint、DeVSkim、OWASPFindSecurityBugs和PumaScan等工具。尽管在IDE中，组织的信息安全策略并不完全适用于检测工具，但在开发人员编写代码时，检测确实会执行质量审查并识别潜在的错误和重复。IDE安全插件旨在识别源代码开发过程中的安全漏洞和修复程序，让
29、安全性向软件开发人员左移。图4-2表示IDE安全控制的门控方法，以及如何建立、审查功能分支（重史代码文件）并将其合并到主分支以进行部署。在这一点上，代码中的安全错误可以在开发的早期识别出来，而不是在它们更临近影响发布的时间窗口。图8.IDE插件19采用PaC/CaC有助于从开发生命周期一开始就引入合规性，实施安全护栏可确保基础设施和源代码是合规和安全的。这种方法还使开发人员和运营人员协作使合规活动更有效，进一步促进了DeVSeCoPS的概念。4.2 拥抱DevSecOps方法进行测试DeVSeCOPS的连续性一一持续测试一一要求测试以比传统应用程序更加分段和频繁的方式执行。测试不再仅仅是应用程
30、序发布到生产环境时的勾选项。测试适用于应用程序的功能，通常被分解为需求。保持与应用程序的更改和部署致的测试频率非常重要。提交到仓库的代码通常在持续集成(CI)工具中运行，并接受自动化测试。充分的自动化测试可以降低与部署新代码变更相关的风险，并减低代码回归或引入新缺陷的可能。DoRA2。研究小组的四个关键指标表明，部署频率和变更准备时间与自动化测试套件的有效性相关。 部署频率(DePlOymemFreqUenCy)：组织成功发布到生产环境中的频率 变更的提前期(LeadTimefOrChangeS)：提交到生产环境所需的时间 变更失败率(ChangeFaiiUreRate)：导致生产环境失败的部
31、署百分比 服务恢复时间(TimetoRestoreService)：从生产环境中故障恢复时间测试自动化提高了频率并缩短了变更的交付时间，这有助于降低回归缺陷的风险，并通过对攻击地图和发现漏洞威胁的更快响应来降低风险。下表4-1中的方法和用例通常在软件开发中被考虑测试类型I阶段频率安全冒烟和单元在开发应用程序时，对源代码的小单元和应用开发人员审查和测试代码的持续活测试集成部分进行测试，从而更早地发现缺陷，并动。要求、迭代和任务应该分配时间以更低的成本进行补救。通常由开发人员作为来执行安全冒烟测试和单元测试。一项活动执行，因为代码是在部署前生成。静态应用程序安一种通常由工具支持并集成到构建流水线中
32、在通过IDE进行开发期间，并在每次全测试(SAST)的方法，旨在在编译成最终二进制文件之前，构建或部署时，进行持续的自动化活分析应用的源代码找出可被利用的漏洞和脆动。弱性动态应用程序安自动化方法通常由工具支持并集成到构建流每次部署都会持续自动启动测试，这全测试(DAST)水线中，用来分析编译后的应用程序，识别可被利用的安全漏洞或脆弱性通常是在非高峰时段的耗时扫描。可以作为非开发人员的互动“右移”，并在集成大部分应用程序组件后作为夜间扫描执行交互式应用程序安全测试(IAST)将DAST的元素和代码可见性结合起来，它作为测试运行时环境中的代理实现，以测试攻击操作并识别漏洞。每次构建或部署以及应用程
33、序的执行期间持续化的自动化运行。可以作为非开发人员的互动“右移”，并在集成大部分应用程序组件后作为夜间扫描执行故障注入一种混沌工程方法，通过对应用程序注入在生产中可能面临的故障和依赖性中断。故障注入是将故障引入应用程序设计，以验证其健壮性和错误处理能力。通常需要所有应用程序相关方合作的计划活动(自动和手动)。需求、迭代和任务应该专门用于故障注入。渗透测试从内部或外部，使用白盒或黑盒的方法测试应用程序，以发现应用程序配置和设计上的脆弱性。通常测试由专业渗透测试人员在发布前实施应用程序的可发布版本的计划活动。需求、迭代和任务应专门用于渗透测试。表1：测试类型阶段和测试频率表1展示了具有手动和自动活
34、动的应用程序的理想测试参数。这些通常应在构建和部署阶段引入，并可以映射和对齐图5中的CSADevSecOps交付流水线。阶段触发暑安全活动安全设计和架构 应用或功能设计威胁建模安全基线和评估控制安全编码拉取、克隆或提交SAST静态应用安全IDE插件集成SAST代码SCA软件组成分源代码审杳持续集成对源代码库实持续构建、集成和测试持续交付和部署运行时防御和监控系统、容器和网络漏洞监控SAST容器和镜像扫描DAST动态应用程序安全测试镜像扫描工件和镜像库扫描系统、容器和网络漏洞扫描管理模糊测试IAST交互式应用程序安全测试应用程序测试和模糊测试RASP运行时应用程序自我保护渗透测试手动执行在开发人
35、员和操作人员所用于自动评估安全发现安全治理、报告和KPI 1选择的工具中，根据情况和缓解的遥测技术和仪向他们提供即时反馈。图5.CSADevSecOps交付流水线4.3追踪开源风险组织越来越多地采用开源代码和库作为其环境和软件开发活动的一部分。虽然开源社区代表了巨大的价值和创新潜力，但也伴随着相关的风险和顾虑。组织应审查连接到其代码库和环境的所有开源软件和组件，以确保它们不会引入不必要的风险和漏洞。开源工具和依赖关系的识别往往被忽视。依赖不明开源工具的应用程序将具有未知的供应链安全度量，如图4-3所示：图9.依赖风险示意图所有现代数字基础设施现代数字基础设 施一个23年的 项目，被一群随机 来
36、自内布拉斯加 州的人吃力不讨 好的维护者。外部组件存在风险，应当被适当地审查。这可以通过以下流程和工具方法来实现： 流程：组织应确保存在引入开源库的真正需求或业务案例。不必要的库可能会导致攻击面和暴露面增加。开源工具更新、发布和贡献率是衡量开源风险的指标。 工具：组织机构应利用软件组成分析（SCA）工具扫描代码、项目和代码库，在技术方面寻找第三方库。SCA可以帮助清点应用程序中使用的开源组件，并识别漏洞。使用这种方法并不能消除风险，但考虑到开源软件和组件的广泛使用，它确实有助于限制攻击面。图4-4说明了第3阶段SCA可以适合AWS基础设施的阶段。图10还说明了在代码构建/安全编码阶段可以放置S
37、CA的位置。SCA是-种安全左移的有效方法，因为SCA是部署前构建阶段的安全控制。部署代码流程提交分期用户I 旗+代码提交代码均建测试代码部署代码构建测试代码部署生产(SCASAST)(OAST)SAST静态应用安全测试SCA软件组成分析DAST动态应用安全测试图IOCOUd23上的代码构建引入SCA234.4安全护栏安全护栏（GUardraiIS）是集成工具，在最好的情况下，在软件开发过程中实现自动化，以确保与组织的目标和目的保持一致，包括合规性。安全护栏建立了一个可以持续监控部署的基线。这些基线可以表示为检测和预防策略的组高级规则。安全护栏可以作为合规性报告的一种方式（例如，在当前批准的镜
38、像列表中运行操作系统的机器数量）或作为一组强制/自动修复的控制措施（例如，运行任何非批准的操作系统的设备自动关闭）。专注于DeVOPS流水线内的内联安全护栏和反馈一一通过紧密集成的工具和流程实现一一可以将合规性方法从时间点转变为持续。必须考虑确保工具和技术的实施与商定的合规目标保持一致。必须很容易地产生证据，以通过内部和外部治理实现对这些控制的外部验证。“DevSecOps的六大支柱：自动化“讨论了”安全自动化和程序化执行框架的实施以及安全控制的监控，以识别、保护、检测、响应和从网络威胁中恢复24,因为它涉及保护代码，应用程序和环境。这些自动化流程的输出应用于提供满足合规目标所需的证据。在De
39、VSeCoPS中，部署流水线可以使用甚至构建与合规性目标相一致的环境。这可能是监视和执行控制的组合，并且可能会因环境、数据分类和业务风险（即开发与生产）而有所不同。通过在代码、模板和安全护栏中定义目标状态，安全目标应尽可能直接集成到部署流水线中。目标应该是一个易于审查的自动审计跟踪，以及相关的安全指标，供DevOps团队和合规团队持续审查以推动安全决策。下面的图11显示了如何将安全护栏应用于云环境的示例。在构建和配置账户和环境之前应用（检测和预防）云约束。图ILCiSCO的AWSGUardraiIS示例25安全护栏可以根据组织的合规要求和风险偏好进行定制。安全护栏的成功标准依赖于以下确定的三个
40、基本原则，并由表2中的一组示例控制类别提供支持。对于一组较低级别的云安全控制，请参阅云控制矩阵（CSACCM）v426组织应该： 了解信息/反馈、漏洞报告或跟踪基础设施部署的合规性偏差（例如，使用经批准的VM镜像）到强制/阻止（阻止未经批准的VM镜像运行的安全护栏）的不同程度的保证。这有助于根据上下文（即开发或生产环境）和相关风险偏好在安全性和开发人员灵活性之间取得平衡。 定义所需的目标安全状态/关键绩效指标（KPI）,例如补丁、服务水平协议（SLA）.漏洞评估和补救时间。所需的目标状态将取决于组织的安全和风险偏好、其云环境和应用程序环境以及监管要求。“支柱6测量、监控、报告和行动文件”将更详
41、细地定义所需的目标安全状态。 为生产环境建立职责分离（SOD）,其中至少需要有两个人对应用程序的关键功能进行更改，以防止欺诈和错误。对于执行概念验证（即开发和测试）的环境，可以删除SOD控制，以允许开发人员自由创建功能，减少可能抑制生产力的安全控制。这种开发者自由来自这样一个假设：相关的环境不能访问生产数据。SoD的实施可以从预生产和质量保证环境开始，以确保安全控制和应用程序功能按预期工作。应用程序所有者还需要确保在发生事件时可以使用SoD方法恢复应用程序的可用性。控制类别安全护栏控制数据保护信息分类和保护是自动化的。静态数据已加密。传输中的数据已加密。对数据进行分类以识别敏感信息（SPlI）
42、和个人身份信息（PII）信息。IT系统按处理的信息类型和业务关键性分类。云存储选项默认配置为“私有”。将存储配置为“公共”是一个例外。密钥和秘密应在密钥库中存储和管理。治理制定政策来管理云环境的安全性。 适当地配置管理和库存。 定义了适当的指标来跟踪合规性以及关键绩效指标（KPI）和关键风险指标（KRI）0 进行控制测试审查。访问控制 访问是根据最小特权原则授予的。 实施了基于角色的控制访问（RBAC） 应用程序已指定负责访问控制的所有者。 特权访问（即具有升级权限的访问，例如root）应保存在安全数据库中，并且仅在例外情况卜.获得批准后才授予访问权限。 集中管理对关键系统的访问（即安全运营或
43、DeVOPS团队）。物理环境安全 内部网络使用VPN或VPC来隔离和保护内部环境。 使用零信任27安全模型。 Web应用程序防火墙和反DDoS解决方案已到位。 服务器、应用程序依赖项和容器经常打补丁并更新到最新版本。 应验证第三方软件组件的使用。 必须进行持续地漏洞扫描。 环境分离到位（生产、暂存、开发、沙盒）。应用程序变更 更改通过集中管理的CI/CD流水线进行。 镜像和库集中管理和批准。 新镜像经过加密签名。 更改在部署前进行安全扫描。 主要版本经过安全测试（请参阅“提高代码保证级别”一章）。 更改经过代码审查、安全冒烟或单元测试。弹性 环境具有内置的弹性，基于服务的价值和关键性（即故障转
44、移、备份）。 负载平衡到位以确保流量管理。 执行定期备份以促进分配的服务级别协议内的可恢复性。 高可用性环境和备份均已到位。 业务连续性练习和故障注入（请参阅“提高代码保证级别”章）包括生产环境。 测试了备份的可恢复性。监控 环境监测和基于事件的警报到位。 警报规则是可配置的。 关键事件和相关操作的日志记录到位。 针对异常和新出现的威胁进行事件威胁检测。 出于取证目的对端点进行远程调查。 应根据保留政策保留日志，并应防篡改。表2.安全护栏类别和控制像AWS等云服务提供商，可以通过在其环境中提供建议的护栏控制措施来提供帮助28。但是，在实施之前，建议执行识别与组织相关的控制的练习，如表2所示。4
45、.5模式和模板模式（部署和处理资源的标准化方法）和模板（已批准的供使用的资源构建）的使用可以协助构建安全的活动；因此，开发人员有权创建或消耗安全资源。模式可以是创建用于支持护栏控制的文档。文档可以支持如何在云上创建资源的示例，如存储、虚拟私有云、计算服务和容器管理。模式可以用在开发人员自主创建和管理自己的资源。模式是将安全策略和合规要求映射到云资源的设计和配置的有效手段。它们可以作为开发人员和安全团队之间的共享责任项目，甚至可以属于安全的拥护者。反模式使用（部署和处理资源的不良做法和方法）也是一个值得关注的点,然而，反模式有一个显著的缺点，即在识别、创建、维护和使用上的耗时，而且验证云资源或代码提取是否包含不良实践也是一个挑战。模板是经过打包和认可的资源，如镜像、容器和IaC代码。模板可以在部署阶段生成，但在一个持续开发模型中，它是被设计为在构建期间中使用。开发人员创建的应用程序组件将利用用于编排托管基础设施（云）的模板，并知道该模板已被扫描和安全地配置。在创建模板（例如，d。Cker镜像、容器和IaC脚本）时，需要考虑的关键因素如下：镜像（ImageS） 识别可能用于每个组件的镜像需求和类型。这将有助于为每个用例生成单独的模板，并有助于加固操作，如有些组件可能需要docker写入权限。 扫描资源中存在的漏洞并修复，包括常见漏洞和暴露（CVES）亦或采用特定版本的软件如操作系统
