上一篇文章的侧重点主要在讲如何 Secure DevOps Environments，而这一篇则更注重于如何在 DevOps 流程中融入安全属性。

当一个新的应用被创建的时候，大部分情况下都会默认包含一些稳定性的特性，例如限流、熔断、缓存、可弹性调度与部署，唯独少了安全。

安全应该是应用的内生属性，在应用创建的时候就应该具备的属性，Security By Default && Security By Design。

在这本小书中，作者提出了 6 个 TIPS 尝试将安全融入到 DevOps 的流程中，将安全变为一种默认就存在的属性。

原文链接：https://www.sogeti.com/explore/reports/6-tips-security-devops-white-paper/

TIP 1: Build A Security-first Culture Across The Business

在 DevOps 流程中，融入安全并不是简单的插入一些流程卡点或者自动化的工具检测。

应该是与开发、运维、测试等等团队一起共享信息，联合起来，才能让整个团队去 “拥抱” DevSecOps。

就像在有些开发团队会去讲一些“极客”文化，DevSecOps 也应该作为一种文化给所有的相关方去宣传，将这个概念深入到每个人的心里，才能有效的推动 DevSecOps 继续落实。

引用原文的一段话：

DevSecOps starts with the people. You do not “implement” DevSecOps, you embrace it. And for that to happen, your organization needs to adopt a DevSecOps culture while “living and breathing” it, via executive buy-in. For success, you’ll need the entire organization, not just the IT people, product teams, and project managers.

Revitalize Your Training Efforts

培训的主要目的是让各方人员明白其在 DevSecOps 中扮演的角色以及需要配合事情，并提高所有相关方的安全意识。

DevSecOps 的推行需要时间发展，无法做到立竿见影，所以最好取得技术管理层的支持，从上至下的去推动发展。

可以选取一些意向程度高的团队合作，产出一个样板团队，在其中配备一个接口人，及时判断业务中是否存在安全风险并与安全团队进行沟通。

Kickstart A Strong InnerSource Community

说实话这部分内容没太看明白，根据自己的理解记录一下。

除了通过培训让员工建立安全意识是远远不够的，需要一个类似“安全社区”一样的地方，可以让员工共享、交流各类安全体系架构、安全修复代码等内容。

有点像在公司内部建立一个技术论坛之类的系统，用于员工之间交流技术。

TIP 2: Integrate Security In The Early Stages Of The Development Lifecycle

这一部分的核心观点是老生常谈的“安全左移”，尽量将安全能力集成到软件开发的早期，而不是等到系统上线后再进行各种安全测试。

网络上关于安全左移的资料也非常多，这部分内容不再赘述了。

作者在这里提出两个方案，简单讲一下。

Move From Batch Scanning To Continuous Assessments And Compliance Checks

这一点目前稍微大一些的公司应该都是这种模式，将传统的事后批量扫描，移动到开发、测试过程中，将一次性的扫描变为持续性的常规扫描。

作者在这里列举了几个扫描时应该注意的地方：

• Find common vulnerabilities and exposures (CVEs)：常规漏洞检查
• Expand your scans for compliance：合规检查
• Manage by the metrics：生成报告，评估安全水位
• Detect early, fix early：发现越早修复越早
• Automate processes：自动化流程
• Improve the traceability：确保流水线中每一步的产出都可用于审计或数据分析
• Use quality gates to ensure compliance：若检出漏洞或风险，需修复后才能继续构建部署

其中有一点 “Improve the traceability” 比较有趣。目前很多公司的流程或是实践中，在这一部分其实没有特别多的要求，基本思路都是检出漏洞或风险，分配到研发人员修复。

有意思的是，检测工具产出的基本都是漏洞或风险，并没有其他的额外数据了。然而无论是对于白盒 SAST 还是黑盒 DAST 而言，都可以产出除了漏洞以外其他更有价值的数据，并将这些数据整理入库存储，就像供应链安全的漏洞库或资产库一样。

目前看起来大部分公司的安全团队似乎都没有意识到这一点，仍然将黑白盒当做传统的检测工具在使用，反而是在国外的一些创业乙方公司有看到类似的产品。

Evaluate Code Quality And Harden Security With Continuous Static And Dynamic Analysis

关于持续扫描这部分作者介绍的比较精炼，但是实际上 SDL 中的检测部分完全可以写一本小书来说明相关的内容。

这部分的核心思想还是构建一套完整的工具集对代码与系统进行持续性的扫描。作者提出了一些需要考虑的点：

• Scan for vulnerabilities daily
• Incorporate a dependency checker
• Search your container images
• Remember to scan infrastructure
• Form a comprehensive analysis

TIP 3: Monitor And Observe Continuously With Purpose

这部分用白话来讲，就是记录好各种系统产生的日志，并持续运营日志，从中发现可能存在的威胁。

这里作者对成功有效的监控有4项要求，下面展开讲讲

Form A Complete Picture With Structured Data

这部分主要观点是：全量收集各种日志数据往往是不够的，还需要进一步对这些日志进行整理。

这里提到的整理比较宽泛，包括：剔除冗余数据，标准化日志结构等等。

在必要的时候可以引入机器学习等手段自动化整理日志。

Leverage Machine Driven Monitoring For Analysis And Reporting

这部分作者提出了 “Machine Driven Monitoring” 的概念，尝试用白话解释一下。

我们在上一个步骤中，已经获取了大量的系统日志，然而这些日志仅仅依靠人肉来识别是完全不可能的。

这时就需要通过各种方法聚合、筛选、分析日志中可能包含的风险信息，例如日志分析程序发现了三个单独均不会引发告警的事件，但是当这三个事件同时出现的时候，就有可能需要告警出一个大的风险。

这里就可以引入各种机器学习、AI等方法，协助从海量的告警信息中发现有用的数据。

Combine Actionable Alerts With Threat Intelligence To Enable Proactive Security

作者提到，企业可以结合威胁情报来衡量潜在的安全风险和已记录的风险，然而这一项可能对国内大多数企业而言要求都太高了。

通过与威胁情报相结合，可以补充日志中不存在的信息，例如 IOCs、TTPs 等等，尽可能的提前发现威胁来源并做出针对性的响应。

Incorporate A Robust Toolchain Built For Modern Threats

这部分看起来似乎是在给 Azure 安全产品、工具集引流。作者主要想阐述在企业内需要一套可靠的安全产品集、工具链等等。这部分内容就不再展开讲述了。

TIP 4: Embrace Everything-as-code

将一切都视为代码。看起来可能非常不可思议，然而应用安全越做体会越深。

随着开发人员变更配置、变更基础设施等任务变得越来越频繁的时候，会逐步的将一切用类似代码的形式体现出来，固化出流程，这些从某些意义上来说，就是一种代码，只不过不是用我们常见熟悉的编程语言实现的而已。

Start Your Transformation With Infrastructure-as-code

基础设施即代码是一个很好的开始，很多企业都会逐步通过 IaC 替换研发人员的手工管理基础设施的情况。

当企业实现了 IaC 之后，很多基础设施的安全问题都可以通过自动化的扫描工具发现，例如 OSS 的配置问题，如果没有 IaC，需要研发人员针对每一个 Bucket 逐一排查，而 IaC 之后，就可以批量实时的扫描 OSS 配置以及变更了。

Adopt Immutable Infrastructure

作者提出在实践 IaC 之后仍然会存在其他的问题，例如随着时间推移，会发生配置漂移的情况。

简单来说，当应用创建部署后，当时的配置项是安全的，但是随着时间推移，配置项、基础设施等可能会因为各种原因被人为修改。这也意味着每次重新部署后，各种配置项或基础设施需要重新配置。

对于这种情况，作者提出了使用不可变基础设施的方案，即每次配置变更不是推送到 VM 中，而是创建一个包含新配置的 VM 替换原有的 VM。这样每次在部署的时候可以针对 VM 进行完整的安全检测。

除此之外还有两个好处：

• 对安全审计非常有帮助，当出现新的 CVE 时，安全人员可以重建一个新的基础镜像，并将其推送到新的集群中；（需要考虑稳定性问题）
• 安全人员可以追踪这些基础镜像或基础设施是如何一步步变更的，可以看到每一次的更改；

Store Code In A Secure Version Control System

这部分比较简单明了，不再赘述了。

Setup Configuration-as-code

配置文件即代码，作者提到了一种方案，将配置检查与 Ansible 的自动化功能相结合，每当发生部署填充配置的时候，就可以自动化的检查配置项中的各类安全风险。

Implement Pipeline-as-code

这一点个人感觉有点硬蹭的意思。主要观点是将发布过程的流水线也作为代码存储起来，这样安全团队可以追踪、插入各种安全活动到流水线中。

保证每次开发人员进行发布的时候，使用的都是含有安全检查、安全加固等功能的流水线。

TIP 5: Realize Compliancy With Policy Automation

略。

TIP 6: Secure And Visualize Your Software Supply Chain

依然是供应链问题，作者提到了两点，放在一起来说

Act On Insights Gathered By Dependency Tree Visualization

Grow Transparency With A Software Bill Of Material (SBOM)

这里提到了要将供应链的数据可视化，方便快速从数据中挖掘信息。关于这一点其实有些仁者见仁智者见智的味道，是否可视化、怎么可视化、可视化展示什么数据，都需要根据实际的分析项目决定。

与可视化相比，更重要的还是将供应链的数据完整保存起来，将每个项目的供应链透明出来，一来方便与开发团队沟通，二来无论是可视化分析还是做其他的检查，都可以做到信手拈来。