基本上，DevSecOps从一开始就是内置安全性的DevOps。这意味着将安全性纳入需求，设计，代码和部署阶段，简单来说，就是将其纳入整个DevOps管道。
较早的安全实践往往会降低开发团队的速度，并且每年上市时间越来越短时，软件开发团队必须找到一种在不影响安全性的前提下加快其软件开发过程的方法。这就是DevSecOps的启动方式。
企业最终目标是在安全团队和开发人员之间架起桥梁，同时确保快速，安全地交付代码。孤岛思维被不同团队之间的通信和应用程序安全性的共同责任所取代。
DevSecOps最佳实践和工具
组织如何将这些目标转化为实践？且可以自动化哪些特定的安全过程并将其集成到CI / CD管道的其余部分中，以及如何做到这一点？
让我们根据DevSecOps工具和实践的当前状态来探索这些问题并寻找一些答案。
1、漏洞扫描
扫描代码中的漏洞是保护产品安全的基本第一步。将漏洞扫描集成到CI / CD流程中是显而易见的开始实施DevSecOps的地方。
这意味着要确保在交付管道的每个主要阶段都检查代码是否存在漏洞-从编写代码到部署到生产中。为了达到这种集成水平，组织需要确保负责管道各个阶段的各方都具有他们所需的培训和工具，以检测代码中的漏洞。
相关技术包括用于检测专有代码中的漏洞的SAST和用于检测具有已知漏洞的开源组件的SCA工具。许多SAST和SCA供应商都提供与CI服务器，构建工具，存储库的集成，还提供与IDE的集成，以帮助开发人员尽早发现问题。
2.运行时保护
运行时保护是另一个至关重要的安全流程，应将其作为DevSecOps策略的一部分跨整个CI / CD管道进行集成。
运行时保护意味着保护软件免受应用程序开始运行时可能出现的威胁的影响。尽管有关运行时安全性的讨论传统上只在软件投入生产后才进行保护，但运行时威胁也可能在管道的早期阶段存在，在交付过程中尽早考虑运行时安全性也有助于确保当进行部署时，已经缓解了运行时威胁。这就是为什么应在CI/CD管道之间集成运行时安全性而不是仅限于生产环境的原因。
用于中是否存运行时检测的特定工具和策略将根据组织的特定需求而有所不同。但是，至少要确保正在监视应用程序在异常信号，这些异常信号可能表明存在违规行为。同样重要的是，组织应该知道哪些环境变量或配置设置可能会在运行时创建安全漏洞，并有适当的流程来识别那些风险。
3、云服务商
将安全性集成到应用程序交付过程中的另一个重要策略是利用云服务提供商提供的安全性功能。这些工具中的许多工具都位于DevOps链的部署和部署后末端，因此类似于更传统的事后安全服务。但是它们仍然是应用程序外部防御的一部分，起着重要的功能，并且由于它们是云基础架构的一部分，因此它们通常易于自动化和系统化。
请注意，组织的CSP安全性功能可能在默认情况下未启用，并且它们可能需要进行一些配置，因此组织需要采取有效措施以充分利用它们。
4、标准与政策
设置安全性标准和策略在很大程度上是一项需要实际操作的工作，组织虽然可以扫描源代码和基础结构中的漏洞，但是确定安全优先级以及如何实现这些优先级的过程仍然需要人员认真考虑。在设计和代码级别建立安全标准也是如此。
欧盟方面的《通用数据保护条例》（GDPR）的实施使得在设计级别明确制定和实施安全标准显得尤为重要。
另一方面，通过使用编排工具/服务网格功能（例如RBAC）来以高度粒度实施策略，可以在很大程度上自动化在运营级别上建立此类标准。基于角色的访问策略的设计应与应用程序源代码中的安全标准的设计一样受到重视，且它们都应被视为高优先级任务。
5、容器和服务管理
在部署大型的，基于容器的应用程序时，诸如Kubernetes之类的容器编排工具已成为必需品。可以与编排工具一起使用并管理诸如服务发现和访问以及用户，基于容器的应用程序和外部服务之间的关系之类的服务网格本身就变得越来越重要。
在部署级别，此类工具是DevSecOps的关键元素。它们充当容器和外部世界之间的高度可伸缩的隔离层（因此，用户和潜在的攻击者只能访问隐藏在代理之后的服务，而不能访问单个容器），并且它们可以处理诸如身份验证之类的任务、授权和加密。它们是专为自动化而设计的。
但是，除了使用CSP安全工具之外，您还需要了解编排工具和服务网格所提供的安全功能，并且需要启用（如有必要）并对其进行配置。例如，在大多数情况下，Kubernetes基于角色的访问配置（RBAC）应该是DevSecOps的关键元素，但默认情况下未启用它。
从DevOps大规模转换到DevSecOps
尽管DevOps应用程序在速度，规模和功能方面取得了飞速的发展，但它们通常缺乏可靠的安全性和合规性。因此，DevSecOps被引入到软件开发生命周期中，将开发，操作和安全性整合在一起。
DevSecOps将传统的安全参与促进到SDLC的活跃过程，引入持续集成（CI）和持续交付（CD）之类的流程可以确保在敏捷开发过程中主动测试和验证代码的正确性。同样，DevSecOps将主动安全审核和渗透测试注入敏捷开发，提倡将安全性内置到产品中，而不是应用于成品。
若组织需要实施DevSecOps则要对组织现有的IT资源和DevOps流程进行广泛的评估，然后建立将更强的安全性集成到其中的整体策略。
该模型共包含10个阶段，如下：
（1）Plan计划阶段
- 解决安全技术栈：需由安全人员评估以往安全设计中不完善的坑点，并给出解决方案
- 确定DevSec的衡量指标
- 威胁建模
- 安全工具培训：SDL所涉及的安全服务更多，但DevSecOps基本靠自动化，因此需要包含针对安全工具的使用培训
（2）Create生成（编码）阶段
- 编码过程中的安全问题：市面上几乎都是通过IDE安全插件的方式实现
（3）Verify验证（测试）阶段：SAST/DAST/IAST/SCA
（4）Preproduction预发布阶段
- Chaos Monkey（混沌工程）
- Fuzzing：与SAST/DAST/IAST等基于已知经验发现安全问题不同，fuzzing捕捉的是完全未知的安全问题
- 集成测试：单元测试风险较低，但联动后风险相对不可控，因此需要做集成测试
（5）Release发布阶段
- 软件签名：传输等过程中的防篡改
（6）Condifure配置阶段
- 签名验证、完整性测试、纵深防御
（7）Detect检测阶段
- RASP、UEBA、网络流量监控、渗透测试——即线上运维阶段
（8）Respond响应阶段
- 安全编排（基于发现的威胁作智能阻断，形成playbook）、基于RASP和WAF的安全防护、混淆
（9）Predict预测阶段
- 该阶段关注的重点是威胁情报——
- 漏洞情报：最新的漏洞及其利用方式
- TTPs的威胁情报：具体的攻击手法、攻击者画像等新型威胁情报对开发安全来说更有用，而不是传统的URL、IP、恶意文件等信息
（10）Adapt适应阶段
- 根据拦截结果调整开发安全过程，更改策略，对自身应急响应的方案、纵深防御体系等不断适配、调整、优化。
若有收获，就点个赞吧
0 人点赞
