快速了解DevSecOps：构建安全软件开发的基石！

关键词

• 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”至关重要

「4、漏洞监测伴随终身」——即使您的开发过程已经结束，跟踪漏洞的工作也不会结束。只要你软件仍在使用，就需要持续监控新的威胁。

「5、识别开源组件的许可证风险」—没有遵守开源许可要求可能会使公司面临法律诉讼等重大风险。培训开发人员了解开源许可证及其义务，并让您的法律顾问参与其中。
「6、商业估值应充分考虑开源问题—」如果您正在进行收购/投资，如果软件资产是目标公司估值的重要部分，请不要犹豫的进行第三方开源代码审计。

实施DevSecOps缓解风险

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

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

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

实施DevSecOps的具体举措

「1、优先将安全检测应用到现有的软件缺陷审计和安全事件调查中」——首先将安全检测集成到已知的软件缺陷审计和安全事件调查流程中，目的是对已知问题充分进行安全方向上的根因分析，以防止再次出现同样的问题，并将经验更新到DevSecOps流程的Checklist中。

「2、管理维护好自己的源代码共享资源库」——所有团队应该使用经过安全认可的源代码库，除了代码本身是经过安全审计，企业级的代码共享库还应包含经过合规批准的框架、组件、许可证、管理工具等。

「3、尽可能多的自动执行安全测试」——可持续集成CI/CD中，并且与整个过程中的其他测试并行开展。目的是通过简单有效的反馈循环，以便开发和运营团队及时验证与处理。而不是等到SDLC结束以后，再进行耗时且昂贵的补救工作。使用可以与SDLC良好集成的商业工具已经成为普遍有效的实践

「4、确保软件供应链的安全性」——90%的现代应用都是由开源组件构成的，使其成为当今软件供应链的基础部分。我们继承开源代码功能的同时也意味着集成其漏洞和风险。因此先行检测其中已知的漏洞必须作为开发人员选择开源组件及版本的重要选项。

「5、持续培训将DevSecOps作为一种良好的企业文化」——“全面质量管理”和“大Q”早以成为企业的高层级文化建设之一，那么“全面安全管理”或是“大S”是否也应该被考虑提升高度是管理层值得关注的事情。

实现DevSecOps的关键工具

「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

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

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

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

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