软件供应链是将“原材料”（代码）进行加工（修改、编译等）交付（分发或再分发）给用户的过程。
软件供应链安全指在软件设计与开发的各个阶段中来自本身的编码过程、工具、设备或供应链上游的代码、模块和服务的安全，以及软件交付渠道安全的总和。软件供应链因其复杂多样且攻击简单的特点，极易成为攻击者的攻击目标
使用开源本身并不存在风险。为了抵御开源的安全性和合规性风险，我们建议采取以下方法步骤
1、安全充分融入到SDLC的所有环节中—实施自动化流程，使用高度集成的SCA/AST工具追踪审计代码库中的开源组件及其已知的安全漏洞，并根据严重性确定补救缓解的优先级。
2、建立完善的“SBOM”体系—任何组织无法防御自己不知道的威胁。获取其代码库中已经在使用的开源组件“SBOM”至关重要
软件供应链安全防护一般需要遵守以下原则，供应商需要给出明确的软件物料清单（SBOM），SBOM描述了软件包依赖的一系列元数据，这些信息在分析软件安全漏洞时发挥着重要作用。同时在软件开发、交付、使用的所有阶段，需要最小限度暴漏软件的SBOM及其他详细信息，避免被攻击者有针对性的利用漏洞进行攻击，提高攻击者的攻击成本。随着新漏洞的出现，安全防护系统需要及时响应漏洞以应对新的威胁，定期监控组件的状态，如组件使用寿命即将耗尽或开源贡献者可能放弃组件并对其停止维护，在这些情况下，必须能够检测到组件风险状态的变化，确定风险严重程度的优先级，并在必要时关闭或维护组件。
3、建立与NVDs的合作体系—从NVD、CERT、平台级SRC获取开源软件漏洞披露信息是一种必要的手段和能力。同时这些信息的贡献者—安全公司/组织通常会更早提供详细的通知和修补建议。
4、漏洞监测伴随终身——即使您的开发过程已经结束，跟踪漏洞的工作也不会结束。只要你软件仍在使用，就需要持续监控新的威胁。
5、识别开源组件的许可证风险—没有遵守开源许可要求可能会使公司面临法律诉讼等重大风险。培训开发人员了解开源许可证及其义务，并让您的法律顾问参与其中。
6、商业估值应充分考虑开源问题—如果您正在进行收购/投资，如果软件资产是目标公司估值的重要部分，请不要犹豫的进行第三方开源代码审计。
许多企业/组织已经充分认识到使用开源组件所带来的风险，同时清楚的意识到事后补救远远比事前预防要花费更多的成本和时间。
那么良好实现DevOps的最后一步，既是将安全管理与合规性审计集成到开发和运营团队的日常工作中，从而使安全管理成为SDLC中所有环节的一部分，而不是将此任务局限在安全团队。在开发和运营团队已经应用的DevOps流程和工具中构建自动化安全举措，并且及时更新、反馈、总结和改进这种措施。
DevSecOps 是 Gartner在 2012 年就提出的概念，自2017年首次引入RSA大会，从DecOps的概念延伸和演变而来，其核心理念安全是整个IT团队（包括开发、运维及安全团队）每个人的责任，需要贯穿从开发和运营整个业务生命周期每一个环节才能提供有效保障。
2018 RSA大会提出了“Golden Pipeline“（黄金工作流）概念，强调自动化工具链支撑。是指一套通过稳定的、可落地的、安全的方式自动化地进行CI/CD的软件研发工作流。 其中，关键安全活动包括：“Golden-Gate”、AST应用安全测试、SCA第三方组件成分分析和RASP运行时应用自我保护。
相比复杂的双环模型，Golden Pipeline无疑是一种便于理解和落地的实现方式。
2019 RSA大会上，大量从业者意识到DevSecOps实施过程带来的文化冲突，并尝试解决这个问题，并提出了DevSecOps宣言（如下），强调DevSecOps融合文化的建立需要对组织重新设计，将安全人员融入每个开发团队，使得掌握安全能力的专家深入业务、开发、运维等各工作活动，让DevSecOps真正创造价值，避免成为效率瓶颈。
2020 RSA大会上，将风险管理、合规与治理融入DevSecOps的实践探索。研讨了企业如何向DevSecOps转型以及过程中可能所面临的障碍，如何从公司各层面上获得支持，包括DevSecOps人才招聘、培养也是需要考虑的重要方面。
1、优先将安全检测应用到现有的软件缺陷审计和安全事件调查中——首先将安全检测集成到已知的软件缺陷审计和安全事件调查流程中，目的是对已知问题充分进行安全方向上的根因分析，以防止再次出现同样的问题，并将经验更新到DevSecOps流程的Checklist中。
2、管理维护好自己的源代码共享资源库——所有团队应该使用经过安全认可的源代码库，除了代码本身是经过安全审计，企业级的代码共享库还应包含经过合规批准的框架、组件、许可证、管理工具等。
3、尽可能多的自动执行安全测试——可持续集成CI/CD中，并且与整个过程中的其他测试并行开展。目的是通过简单有效的反馈循环，以便开发和运营团队及时验证与处理。而不是等到SDLC结束以后，再进行耗时且昂贵的补救工作。使用可以与SDLC良好集成的商业工具已经成为普遍有效的实践
4、确保软件供应链的安全性——90%的现代应用都是由开源组件构成的，使其成为当今软件供应链的基础部分。我们继承开源代码功能的同时也意味着集成其漏洞和风险。因此先行检测其中已知的漏洞必须作为开发人员选择开源组件及版本的重要选项。
5、持续培训将DevSecOps作为一种良好的企业文化——“全面质量管理”和“大Q”早以成为企业的高层级文化建设之一，那么“全面安全管理”或是“大S”是否也应该被考虑提升高度是管理层值得关注的事情。
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流程中。
传统的DevOps往往对安全不够重视。过去Ops 通常在部署之前被排除在外，而Dev将其代码丢在无形的墙上，因而造成了消除开发和运营团队之间的一些传统冲突。同样的，如果Sec是孤立的，也会存在类似的问题。安全必须是软件开发流程中的“一等公民”，而并非最终步骤部署，或者更糟糕，只有在发生实际的安全事件后才受到重视。
DevSecOps 可以给研发效能提供诸多好处，主要表现在三个方面：
不过需要注意的：DevSecOps是将“安全”融入“研发活动过程”之中，将两者融合起来。缺乏合适的管理，流程制度，和相关的安全运营团队，最终依然是DevOps+Security，而不是DevSecOps。
后续，会逐步跟大家分享DevSecOps相关的工具和实践，具体解读上述关键词。
