关键词

• DevSecOps — 在不影响敏捷性的前提下，将安全充分融入到SDLC的所有环节中
• SDLC—软件交付生命周期
• SCA—软件组成分析-用于识别和检测软件中使用的开源/第三方组件的已知安全漏洞
• SAST—静态分析安全测试
• DAS—动态分析安全测试
• IAST—交互式分析安全测试
• SBOM— 在这里特指软件中使用开源组件的完整信息列表

开源带来的供应链风险

软件供应链是将“原材料”（代码）进行加工（修改、编译等）交付（分发或再分发）给用户的过程。 软件供应链安全指在软件设计与开发的各个阶段中来自本身的编码过程、工具、设备或供应链上游的代码、模块和服务的安全，以及软件交付渠道安全的总和。软件供应链因其复杂多样且攻击简单的特点，极易成为攻击者的攻击目标 。

• 超过90％的企业/组织在关键开发项目使用开源软件
• 超过90％的新代码库由开源软件构成
• 其中85％的对应开源软件社区超过两年没有或很少被维护
• 开源不等于不需要/不遵守licenses
• 超过80%的企业/组织不能清晰的掌握“SBOM”，更无法快速修补漏洞
• 2017年Equifax大规模数据泄露的主要诱因之一就是缺乏完整的“SBOM”
• 2018年AST漏洞的平均年龄为6岁，略高于2017，补救措施没有显着改善
• ”开源工具“的快速广泛普及，漏洞利用窗口时间从45天缩短到3天

开源治理的建议步骤

使用开源本身并不存在风险。为了抵御开源的安全性和合规性风险，我们建议采取以下方法步骤 1、安全充分融入到SDLC的所有环节中— 实施自动化流程，使用高度集成的SCA/AST工具追踪审计代码库中的开源组件及其已知的安全漏洞，并根据严重性确定补救缓解的优先级。 2、建立完善的“SBOM”体系— 任何组织无法防御自己不知道的威胁。获取其代码库中已经在使用的开源组件“SBOM”至关重要 软件供应链安全防护一般需要遵守以下原则，供应商需要给出明确的 软件物料清单（SBOM） ， SBOM描述了软件包依赖的一系列元数据 ，这些信息在分析软件安全漏洞时发挥着重要作用。同时在软件开发、交付、使用的所有阶段，需要最小限度暴漏软件的SBOM及其他详细信息，避免被攻击者有针对性的利用漏洞进行攻击，提高攻击者的攻击成本。随着新漏洞的出现，安全防护系统需要及时响应漏洞以应对新的威胁，定期监控组件的状态，如组件使用寿命即将耗尽或开源贡献者可能放弃组件并对其停止维护，在这些情况下，必须能够检测到组件风险状态的变化，确定风险严重程度的优先级，并在必要时关闭或维护组件。 3、建立与NVDs的合作体系— 从NVD、CERT、平台级SRC获取开源软件漏洞披露信息是一种必要的手段和能力。同时这些信息的贡献者—安全公司/组织通常会更早提供详细的通知和修补建议。 4、漏洞监测伴随终身 ——即使您的开发过程已经结束，跟踪漏洞的工作也不会结束。只要你软件仍在使用，就需要持续监控新的威胁。 5、识别开源组件的许可证风险 —没有遵守开源许可要求可能会使公司面临法律诉讼等重大风险。培训开发人员了解开源许可证及其义务，并让您的法律顾问参与其中。 6、商业估值应充分考虑开源问题— 如果您正在进行收购/投资，如果软件资产是目标公司估值的重要部分，请不要犹豫的进行第三方开源代码审计.

实施DevSecOps缓解风险

许多企业/组织已经充分认识到使用开源组件所带来的风险，同时清楚的意识到 事后补救远远比事前预防要花费更多的成本和时间 。 那么良好实现DevOps的最后一步，既是将安全管理与合规性审计集成到开发和运营团队的日常工作中，从而 使安全管理成为SDLC中所有环节的一部分 ，而不是将此任务局限在安全团队。在开发和运营团队已经应用的DevOps流程和工具中构建自动化安全举措，并且及时更新、反馈、总结和改进这种措施。 DevSecOps 是 Gartner在 2012 年就提出的概念 ，自2017年首次引入RSA大会，从DecOps的概念延伸和演变而来，其核心理念安全是整个IT团队（包括开发、运维及安全团队）每个人的责任，需要贯穿从开发和运营整个业务生命周期每一个环节才能提供有效保障。 2018 RSA大会提出了“Golden Pipeline“（黄金工作流）概念， 强调自动化工具链支撑。是指一套通过稳定的、可落地的、安全的方式自动化地进行CI/CD的软件研发工作流。 其中，关键安全活动包括：“Golden-Gate”、AST应用安全测试、SCA第三方组件成分分析和RASP运行时应用自我保护.

• Golden-Gate黄金门，目的是制定安全阈值，也是软件可以接受的最低安全标准，应该也是采用威胁分析和安全建模得到需要后续流程中应该进行达到的安全设计、安全实现、安全测试验证需要达到的目标。
• AST应用安全测试，则包括了SAST、DAST和IAST三类安全测试技术。通过在DevOps流水线的不同阶段，分别从静态代码分析，动态应用测试以及交互式应用安全检测三个方面引入合适的工具。
• SCA则是针对软件中的开源软件（OSS）和第三方库软件锁涉及到的框架、组件、库等，识别软件成分清单并识别其中的已知漏洞。
• RASP则主要是在运营中进行安全检测和安全阻断。

相比复杂的双环模型，Golden Pipeline无疑是一种便于理解和落地的实现方式。 2019 RSA大会上，大量从业者意识到DevSecOps实施过程带来的文化冲突，并尝试解决这个问题，并提出了 DevSecOps宣言 （如下），强调DevSecOps融合文化的建立需要对组织重新设计，将安全人员融入每个开发团队，使得掌握安全能力的专家深入业务、开发、运维等各工作活动，让DevSecOps真正创造价值，避免成为效率瓶颈.

• 建立安全而不仅仅是依赖安全
• 依赖赋能的工程团队而不仅仅是安全专家
• 安全的实现功能而不仅仅是安全功能
• 持续学习而不是闭门造车
• 采用一些专用或常用的最佳实践而不是“伪”全面的措施
• 以文化变革为基础而不仅仅依赖规章制度

2020 RSA大会上， 将风险管理、合规与治理融入DevSecOps的实践探索 。研讨了企业如何向DevSecOps转型以及过程中可能所面临的障碍，如何从公司各层面上获得支持，包括DevSecOps人才招聘、培养也是需要考虑的重要方面.

实施DevSecOps的具体举措

1、优先将安全检测应用到现有的软件缺陷审计和安全事件调查中 ——首先将安全检测集成到已知的软件缺陷审计和安全事件调查流程中，目的是对已知问题充分进行安全方向上的根因分析，以防止再次出现同样的问题，并将经验更新到DevSecOps流程的Checklist中。 2、管理维护好自己的源代码共享资源库 ——所有团队应该使用经过安全认可的源代码库，除了代码本身是经过安全审计，企业级的代码共享库还应包含经过合规批准的框架、组件、许可证、管理工具等。 3、尽可能多的自动执行安全测试 ——可持续集成CI/CD中，并且与整个过程中的其他测试并行开展。目的是通过简单有效的反馈循环，以便开发和运营团队及时验证与处理。而不是等到SDLC结束以后，再进行耗时且昂贵的补救工作。使用可以与SDLC良好集成的商业工具已经成为普遍有效的实践 4、确保软件供应链的安全性 ——90%的现代应用都是由开源组件构成的，使其成为当今软件供应链的基础部分。我们继承开源代码功能的同时也意味着集成其漏洞和风险。因此先行检测其中已知的漏洞必须作为开发人员选择开源组件及版本的重要选项。 5、持续培训将DevSecOps作为一种良好的企业文化 ——“全面质量管理”和“大Q”早以成为企业的高层级文化建设之一，那么“全面安全管理”或是“大S”是否也应该被考虑提升高度是管理层值得关注的事情.

实现DevSecOps的关键工具

1、SAST(静态分析安全测试)—— 在编程和/或测试软件生命周期（SLC）阶段分析源代码的安全漏洞，在发布前修复它们。将自动化的SAST解决方案集成到SDLC中，持续识别潜在的安全问题非常重要。优秀的SAST工具还能提供准确的高可操作性修复指导，使开发人员能够在早期处理安全问题.

2、DAST(动态分析安全测试)—— 在测试或运行阶段分析软件在运行状态下应对攻击的反馈，又称为黑盒测试，大多数DAST只针对web的应用。虽然DAST工具可能比SAST更容易使用，但它不能精确地定位软件代码中的特定弱点.

3、IAST(交互式安全测试)—— IAST交互式安全测试是新一代“灰盒”代码审计、安全测试工具，是近年来兴起的一项新技术，其融合了SAST和DAST技术的优点，无需源码，支持对字节码的检测，可良好的适用于敏捷开发和DevOps，可以在软件的开发和测试阶段无缝集成现有开发流程.

4、SCA（软件组成分析） ——类似于SAST，软件组成分析(SCA)识别应用程序中的开源代码组件并检测其安全漏洞。通常单凭SAST很难识别这些开源漏洞，因为有太多的开源组件被直接调用且非常复杂，准确的识别检测并给出可操作的修补建议是评价SCA解决方案良好的重要指标。与SAST一样，SCA工具应该能很容易地集成到DevOps流程中.

Building Security Into DevOps Process

传统的DevOps往往对安全不够重视。过去Ops 通常在部署之前被排除在外，而Dev将其代码丢在无形的墙上，因而造成了消除开发和运营团队之间的一些传统冲突。同样的，如果Sec是孤立的，也会存在类似的问题。 安全必须是软件开发流程中的“一等公民”，而并非最终步骤部署，或者更糟糕，只有在发生实际的安全事件后才受到重视 。 DevSecOps 可以给研发效能提供诸多好处，主要表现在三个方面:

• 更快 - DevSecOps 通过自动化安全工具扫描，无感地左移了部分传统模式中在上线前最后阶段进行的安全扫描工作，使得整个交付周期变得更短，交付速度因此变得更快。
• 控制风险 - DevSecOps 减少了开发团队对安全部门/团队的依赖，通过安全左移让开发团队具备发现和修正部分安全隐患和漏洞的能力。
• 节省成本 - DevSecOps 由于在 SDLC 前期阶段发现并且修正安全隐患和漏洞，避免了传统模式中在上线前最后阶段进行安全扫描发现高危安全漏洞后进行的返工，从而从流程上节省了成本

不过需要注意的： DevSecOps是将“安全”融入“研发活动过程”之中，将两者融合起来。 缺乏合适的管理，流程制度，和相关的安全运营团队，最终依然是DevOps+Security，而不是DevSecOps.

• 例如对开发人员、测试人员的安全意识培训、制定安全编码规范并实施培训，安全人员介入需求梳理、源代码审计、上线前安全审查等，实现了软件安全保障工作的左移。
• 安全工具不是 “DevSecOps” 的全部，更不是“银弹”，缺乏安全团队的监管和运营，安全工具只是“摆设”
• 加强“研发过程数据”的关联，有助于“安全”风险的跟踪和追溯

后续，会逐步跟大家分享DevSecOps相关的工具和实践，具体解读上述关键词.

RSA 2022: A Roadmap for Building Enterprise-Scale DevSecOps 。

最后此篇关于快速了解DevSecOps：构建安全软件开发的基石！的文章就讲到这里了,如果你想了解更多关于快速了解DevSecOps：构建安全软件开发的基石！的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。