大刘 简单说说

《DevSecOps敏捷安全》读书笔记三

简介：读《DevSecOps敏捷安全》整理的读书笔记。
 学习笔记/读书  3131  7 分钟

前言

继续这本《DevSecOps敏捷安全》的读书笔记整理出来，本次是关于落地实践，上两篇的内容可以查看下面的链接：

  1. 第一篇：https://daliu.net/posts/20250228/
  2. 第二篇：https://daliu.net/posts/20250301/

DevSecOps落地实践

1. 设计参考

落地的挑战

前提是需要有意境具备了一定的DevOps基础，否则后续等于无，比如是否开发人员对用户体验负责，代码可以部署到生产以及开发人员也有监控和运营工具

组织文化、流程管控、技术工具
  1. 要解决组织和文化层面的问题：安全人员和开发能够打破壁垒，安全团队也能够迭代学习，对新技术架构的安全能力。
  2. 把安全管控集成到DevOps中，以减少过多安全卡口带来的人工干预影响了SDL
  3. 随着容器化、微服务架构、多实例共享、三方开源组件等带来的安全风险的不可控，加之安全技术的同步发展，DevSecOps也是在需要不断变化，来实现效益最大化。

设计参考

考虑四个方面：安全组织与文化、安全流程、安全技术和工具，安全度量和持续改进 同时落实几个原则：

  1. 尽可能自动化取代人工
  2. 采用连贯的通用性工具
  3. 支持敏捷
  4. 完整周期的监控
  5. 量化风险
  6. 基础设置不变，减少配置负担，保持环境一致性。
1. 安全组织文化

一方面提高高层认知、同时保持良好的沟通、汇报，贯彻理念，需要达成整体的共识。

一步步的将可以融入的自动化任务迭代并连接在一起，最终建立DevSecOps的能力，而实现自动化过程，并发展为持续集成、交付、部署、运行，监控，实现DevSecOps的迭代。

2. 安全流程

实践方法：

  1. 从易于自动化的开始
  2. 从一个持续构建的流水线开始，逐步加入AST和SCA工具
  3. 不同阶段中加入安全活动

2

安全活动应该包含在整个闭环的各个环节：

  • 计划：安全分析与计划
  • 开发：编码，组件引入，代码质量审查，加固、混淆
  • 构建：SAST工具跟踪缺陷
  • 测试：合规性测试，隐私保护，安全测试，IAST，SAST，DAST，镜像容器检测，等等
  • 发布：安全分析工具（漏扫、渗透等）
  • 运行：运行时防护，RASP
  • 监控：安全事件日志，态势感知，数据库安全等
3. 技术和工具
  • 威胁建模工具、自动化安全分析工具
  • IDE安全插件、安全组件库
  • AST类工具（SAST、IAST、DAST、MAST、TAST）
  • 开源风险治理类工具
  • 安全扫描类工具
  • 数据库安全检查类工具
  • 安全评估类工具
  • 基础环境安全检查类工具
  • 安全监控类工具
  • 安全防护类工具
  • 安全管理平台
  • 安全度量平台
4. 度量和持续改进

通过四个维度考量：

  1. 各个过程的落实及普及程度，抽取数据作为度量的指标找到落地的不足和缺失
  2. 通过结果的角度收集泳衣分析的数据，比如，漏洞检测的效果，安全工具的效果等
  3. 通过安全检测工具的反馈结果评价开发人员安全能力的薄弱点进而解决安全意识和技能的缺失
  4. 通过考量发布流程中的时间，频次消耗，成功率等针对性优化流程的合理性

3

4

其他挑战

1. CI/CD平台安全 在继承各种工具的过程中，安全性也必须要考虑，不能因为引入安全工具反而带来了安全问题

2. IaC基础设施及代码 利用可扩展的基础架构，软件系统构成的动态基础设施，可以通过脚本编排一次性任务，基础架构配置工具定义组件，容器编排工具来部署同样的应用在不同环境。

这样通过对基础设施，基线，配置等检测提早到很早期的阶段，配置的代码可以和应用程序的源代码一起维护。

安全实践：

5

部分实践：

  • IaC代码中的错误配置，硬编码
  • 融入开发流程
  • 可以对供应链进行过治理
  1. 一些平台的安全
    1. 代码托管平台，比如git
    2. 项目管理平台
    3. 容器的管理平台，kubernetes
    4. 代码审计的工具及平台

2. 云原生场景

概述

所谓云原生，利用“云计算交付模型”的优势来构建和运行应用程序的方法，涉及基线代码、依赖、配置、后台服务、构建发布上线、进程、端口绑定、并发、快速处理、环境一致性、日志、管理进程等要素，包括微服务，PaaS（平台即服务），通过API互动。

云原生架构被认为应当具有模块化、可观察性、可部署性、可测试性、可处理性、可替换性的特质。 也可以认为是：DevOps、持续交付、微服务和容器化。

核心技术：

  1. 微服务
  2. 服务网格，一般单独在云原生中作为一层，通过代理的方式存在于每一个服务中，代理可以在应用无意识的情况下管理实例（拦截流量，提供监控、校验、路由、健康检查、容错、测试等）
  3. 不可变基础设施，容器化虚拟化，使得基础设置标准化、版本化。
  4. 声明式API
  5. 容器，Docker，Kubernetes

云原生安全

安全防护模型

《云原生架构安全白皮书2021年-云原生产业联盟》的安全防护模型

6

安全4C模型
  1. 安全分层，共计4层，由外向里依次是，云，集群，容器，代码

云安全： 一般是数据中心，提供集群需要的计算机资源，需要遵循提供商的一些建议

集群安全： 保护可配置的集群组件、运行的应用程序

容器安全： 基础设施：是否提供必要的容器安全功能 供应链：确保镜像安全 运行时：识别恶意行为

代码安全： 最容易利用的攻击面

云原生与DevSecOps

相同点：持续交付的安全能力、安全检测技术、安全运行技术 不同点：云原生更加容器化，更加注重基础设施和环境

对比分析：

7

云原生敏捷安全落地

分层设计：

8

  1. 构建安全

9

  1. 部署安全，镜像及仓库配置
  2. 测试安全
  3. 运行时安全

3. 一些实践总结

通常情况面临的挑战：

  1. 研发抵制
  2. 安全角色从管理变成服务
  3. 责任不清
  4. 目标不同而不配合
  5. 安全投入不足
  6. 新技术隐患

DevSecOps安全流程：

10

安全测试左移： 如果是瀑布研发模式，在测试团队的PC端配置浏览器代理，测试的时候就可以遍历所有的功能点而让IAST工具自动进行安全测试。 如果是敏捷开发模式，IAST可以插桩探针，埋入软件测试环境

统一云上开发的集成平台对应的安全开发流程：

11

安全开发工具链建设：

12

云原生体系下的DevOps体系：

13

车联网行业，对应风险分析：

14

DevSecOps与软件供应链安全

1. 概况

风险面主要是软件漏洞：

  1. 合法供应商引入的
  2. 篡改伪造的组件
  3. 编码过程引入的
  4. 开源组件引入的

攻击环节：

  1. 开发环节，未能够识别威胁和漏洞
  2. 分发环节，SaaS交付有一定凤霞想你
  3. 使用环节，下载劫持等

攻击类型：

  1. CI/CD基础设施污染
  2. 开发工具污染
  3. 软件源代码污染
  4. 依赖混淆，命名关系，命名空间的同名依赖
  5. 捆绑下载
  6. 下载劫持
  7. 升级劫持
  8. 证书劫持

风险治理：

  1. SDLC供应链风险治理

15

  1. 分发过程的治理 a. 来源可信，供应商评估 b. 软件合规 c. 资产管理机制的建立，供应链清单，版本，漏洞信息等 d. 服务支持，SLA e. 安全应急响应机制

比较新的框架：

  1. Google的SLSA
  2. 云安全共享责任模型（微软）
  3. Grafeas开源计划

2. 开源安全治理落地实践

开源软件的优缺点 优点：灵活、高适应性、高效益、低使用门槛、低维护成本 缺点：低易用性、缺乏支持、高隐性成本、高安全风险

风险分析：

  1. 安全漏洞
  2. 知识产权与合规风险，开源许可证，以及许可证的兼容风险
  3. 数据安全风险，配置文件等
  4. 运营和技术分线，需要记录版本，位置，以及组件交互。

关于开源许可证 分类：Copyleft和Permissive，按要求分发，宽松式许可证

常见许可证：GPL、Apache许可证、Ms-Pl（微软公共许可证）、BSD、CDDL、MIT许可证

开源治理难点：

  1. 无法快速止损
  2. 对已用部分没有统一梳理
  3. 没有评估能力
  4. 无法引入相应流程

治理目标：

  1. 梳理并了解开源情况
  2. 避免合规问题
  3. 构建工具，避免手动跟踪
  4. 有应急响应
  5. 开源组件的代码质量跟企业标准能保持一致（感觉很难）

实践过程：

  1. 制定策略：建立规范，建立制品库，排查开源软件（SCA），合理选择开源软件，应急预案，更新和销毁
  2. 要点：管理组织层推动，覆盖全面，构建一整套治理工程

治理技术：

16

关于SBOM：软件物料清单，能够更容易发现安全漏洞的影响，需要了解其概念和生产流程及作用。

以上就完成了这本书的读书笔记，DevSecOps确实更符合当先软件开发环境安全管理，随着与最新技术不断结合，仍然在不断的迭代更新中。

updatedupdated2025-03-022025-03-02

相关文章：