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

前言

继续这本《DevSecOps敏捷安全》的读书笔记整理出来，本次主要是DevSecOps的进阶内容，第一篇可以点击这个链接：https://daliu.net/posts/20250228/。

DevSecOps敏捷安全进阶

1. 开发模式

传统瀑布式开发

6个阶段：制定需求收集计划、需求分析、设计、开发、测试和部署 面对当下快速交付场景很难适应，因而转到敏捷开发

敏捷开发

敏捷开发过程迭代的交付方式，持续快速交付，但是其业务价值的变现依赖于运营侧的部署和稳定，所以DevOps的含义就是研发运营的一体化融合流程。

因而需要开发者具有灵活的思维，避免前期的盲目投入。

Scrum模型（冲刺模型）：以用户故事的方式，作为功能增量，实现价值交付。

工具：白板和即时贴（现在一般都是项目管理软件，电子版的） 三个角色：产品经理，项目经理和团队成员（产品是对接用户确定产品功能的，pm是管理开发及团队的，个人觉得合二为一就会有问题因为角度不同） 其他不多赘述了，就是PMP那一套。

DevOps

通过反馈和改进形成循环的，实现的开发体系。 扩展了软件的加速交付、部署、运营等

核心要素：

1. 敏捷管理
2. 持续交付
3. IT服务管理，传统的更重视流程，也就是各种审批流，而DevOps快速迭代会矛盾所以需要整合。
4. 精益管理，比如共享平台，提升效率

构成如下：

方法论：

1. 团队建设，流程主管、服务主管、DevOps工程师，发布/部署、研发、测试、运营
2. 流水线，可视化，项目规划、需求设计，开发测试，部署，运营
3. 工具链，设计开发、项目管理、交付和部署，自动化测试（计划， 用例，性能测试）

敏捷和DevOps的主要区别是：敏捷解决的是用户和开发的障碍，而DevOps解决的是开发和运营的障碍

2. 架构与实践

敏捷安全架构

包括三个方面：核心内涵、框架和典型场景

敏捷安全实践

安全左移，源头治理

1. 开发安全专家审核
2. 代码标准化
3. 自动化测试

积极防御技术

因为攻击智能化、渗透工具自动化、网络武器快速增加，所以防御需要更加积极，基础设施（CWAPP技术、API安全、Kubernetes）、应用层（RASP、IAST、SCA），安全运营层（BAS技术）。

国内监管

《关键信息基础设施安全保护条例》、《关于规范金融业开源技术应用与发展的意见》、《信息安全技术-ICT供应链安全风险管理指南》（GB/T36637-2018）

3. 敏捷安全体系

建设难点

1. 安全文化挑战，开发，运营，安全角色都是独立的，跨部门有隔阂
2. 人才匮乏（安全要懂的比较多）
3. 能力薄弱，技能和意识匮乏
4. 自动化程度低
5. 安全研发过程割裂，各种安全工具没有可以耦合的标准
6. 没有长期体系规划

建设要素

关于文化

1. 顶层设计
2. 共担与赋能，人人参加，参与部分都有有责任
3. 重视专家意见
4. 持续学习，避免闭门造车
5. 拥抱实践
6. 善于借鉴

关于流程

Gartner的定义： 10个阶段：

1. 计划阶段，安全需求、设计及赋能
2. 创建阶段，安全编码、安全组件应用和安全构建
3. 验证阶段，测试环境下的安全测试
4. 预发布阶段，预生产环境（部署生产投入使用前），系统健壮性检验
5. 发布阶段，交付安全
6. 预防阶段，实现安全部署（感觉跟上面的重复）
7. 检测阶段，运营安全
8. 响应阶段，也是检测阶段的响应
9. 预测阶段，也是运营的一部分，预警
10. 改进阶段，反馈，进入下一个周期

关于技术

1. 安全活动都能够工具化实现，一条链条
2. 持续自动化的流水线
3. 工具链模型

建设体系

实践活动清单：

一些参考

GSA DevSecOps指南、DOD企业DevSecOps设计指南、NIST DevSecOps项目

4. 敏捷安全技术

技术点

风险面：

1. 自研代码，尤其逻辑漏洞和配置问题
2. 三方开源组件，log4j等
3. 容器镜像，不可信镜像，并且检测阻碍更大
4. API安全，敏感信息等

构成要素

1. CI/CD工具链集成安全，嵌入流水线
2. 少侵入性，杜绝安全早晨的代码污染（IAST探针）
3. 检测时间缩短
4. 误报率低
5. 过程可以透明化
6. 能够实现对开发的风险通知

安全技术

1. IAST、交互式检测，部署应用接入agent探针，功能测试时执行自动化测试用例
2. RASP、关键函数插针进行自保护技术，应对紧急版本上线，能够实时下发阻断策略。
3. SCA、接入IDE编码，构建编译，运行时检测，代码仓库扫码等，提供质量门禁。最容易落地
4. BAS、自动化攻击模拟，多节点模拟验证，渗透攻击模拟等。
5. API安全、API攻防、UEBA行为分析，机器学习，API检测分析等
6. 容器和Kubernetes安全、

安全管理

1. 质量门禁、嵌入DevOps流程，设置阈值
2. 工具编排、方便增量检测提高效率
3. 指标化、汇总各个环节的数据，分析收敛趋

IAST

交互式应用安全测试，通过插桩方式，实现透明的自动化检测漏洞分析漏洞的方式，因为涉及到需要耦合软件或者内置agent，所以需要匹配不同的开发语言。

信通院发布过《交互式应用程序安全测试工具能力要求》的标准，其中，开发语言是首要要求，也就是底线要求。

技术剖析

1. java 如果提供了对应接口，可以直接在启动参数加载探针，实现动态数据流污点追踪

2. PHP 通过包装替换原始函数，因为php的内置函数都是c代码，因为php默认是通过建立进程来处理新请求，所以每次建立的时候都是通过先经过插桩函数，比对调用函数，分析，并替换函数。

3. Node.js js比较灵活，所以Node.js插桩也比较简单，跟php类似也是包装函数，hook要调用的函数。

4. Python 虽然同样是包装，但是可以直接用其内建的自省机制，import hook实现插桩。动态对函数添加装饰器。

5. .NET 这个与Java类似，同样是有接口机制可以实现

6. Go 虽然go是直接编译到可执行文件，与其他完全不同，但是，又因为go的开源特性，可以完全实现一个不一样的go build逻辑，使得go在编译的时候以带有插桩的方式进行编译。

应该具备的特点

1. 规则动态更新
2. 无代码侵入性
3. 开源依赖分析
4. 性能监控
5. 脏数据处理
6. 自动回归测试，再出发能够验证修复状态

插桩模式：

1. 动态污点追踪

2. 交互式缺陷定位 通过重构请求，复测漏洞，而不需要hook函数的触发

流量监测模式：

1. 终端流量代理
2. 主机流量嗅探
3. 旁路流量镜像

日志检测模式：

将web服务器的日志转发到IAST服务器

爬虫模式：

个人理解就是因为从内部知道站点地图，接口地址等，所以更加方便进行漏洞检测

嵌入流水线的架构

RASP

技术剖析

运行时应用防护，监听关键代码和函数，识别风险，也能够及时阻断相应攻击行为，工作原理和IAST相似（IAST识别，RASP保护） 工作原理依然是，插桩，触发防护规则，恶意数据报告

源代码插桩：SDK方式 函数Hook：编译时候hook特定函数，比较主流，不会增加开发人员工作量 二级制文件插桩：编译后文件插桩（如果是加固过的二级制就比较难） 字节码插桩：运行时环境插桩 Trap-based插桩：操作系统级的，属于hook了中断，特权模式，风险较高

市面上较多的是JAVA的字节码插桩，hook对应.class文件中的特定方法，并设定执行逻辑。因为会影响响应时间，CPU使用，以及IO，内存使用分配启动时间等。

关于部署

1. 流水线自动化部署，在CI/CD中（尤其是容器），编排的时候把探针安装编排进去，启动的时候就可以自动插桩
2. 应急式部署，例如kubernetes API实现动态加载，插桩，或者Kubernetes Pod的探针也能触发agent的部署
3. 手动部署

关于运行

三种模式，监控、阻断（阻挡会话攻击）、熔断（停止检测和防护）

场景与优势

场景包括：常规、对抗，应急等。 优势：

1. 相比于waf等边界防护，更能知道应用上下文以及堆栈使用，识别更精准，而且适配DevOps
2. 针对0day更有效
3. 可以构造虚拟补丁实现漏洞临时防护

DevOps应用

有益于在开发生命周期早期发现和缓解这些问题，最理想的是在容器化部署和云原生，这样随着容器一起创建和销毁。

SCA

软件成分分析，也就是我所说的开源组件风险管理。

技术剖析

从打包文件中解压并提权特征信息（配置文件、代码片段摘要等），得到的组件信息与漏洞库匹配。 静态模式：直接文件解析识别和分析 动态模式：执行过程收集元数据

1. 知识库构建：组件库、漏洞库、开源许可证和开源项目库
2. 成分分析：基于源文件、基于包管理器依赖、二进制成分分析，开源软件漏洞分线分析、许可证风险分析、运行时分析 许可证分析流程：

检测工具

特点：

1. 定期更新知识库
2. 有修复建议
3. 可视化
4. 能够在平台集成

DevSecOps中接入

应用场景：

1. 制品库接入
2. DevOps发布质量门禁

最佳实践：

1. 需求和编码阶段：扫码仓库，引入的组件属于安全范围内的版本
2. 集成交付阶段：集成到构建环境中，确保自动化，对有风险的构建进行阻断
3. 测试阶段：上线前安全检查，并同步测试人员对应的安全视角
4. 与其他应用安全测试集成（AST系列）
5. 确保软件供应链的安全

BAS

入侵与攻击模拟，模拟真实攻击，进行可重复的端到端的测试。

技术实现

1. 基于agent的漏扫，局域网内的关键节点
2. 基于恶意流量的测试，目标是看是否被检测和拦截
3. 模拟多重攻击方式，适用于云环境

相较于传统攻击方式，更多是自动化测试，对攻击链进行建模，确定最有可能用来攻击的路径，而且可以持续测试。

DevSecOps的落地

1. 评估安全解决方案的效果
2. 高速交付的过程中，通过快速的测试来提高其效率和安全效果

其他场景方案：

1. 模拟攻防演练
2. 量化评估防御体系
3. 高频次、低规模的攻击，防御更加主动

API技术解析

技术实现

风险分析：owasp 关于api的常见威胁清单

1. 主要是通过流量和日志整体分析和挖掘来判断漏洞及暴露面，并且判断频率，攻击源，攻击位置等综合给出结论等。
2. UEBA技术：用户和实体行为分析来判断是否异常，比如越权，未授权，数据泄露等。
3. 机器学习技术
4. 动态防御技术，串行的api网关有更高效率的过滤能力，插件方式实现。

实施步骤：

1. 清点api资产，通过统一安全分析平台分析数据来确保。
2. 访问控制，确保调用api的管理
3. 威胁检测
4. 安全测试，设计安全测试用例，渗透测试方法测试，或者IAST方式
5. 监控和分析

DevSecOps的落地

1. 针对微服务架构，api的部署更重要
2. 上线前集成更容易发现api的方法，例如：旁路流量监测、IAST插桩、RASP主动防御

容器和Kubernetes

威胁矩阵

1. Containers威胁矩阵

2. Kubernetes威胁矩阵

生命周期

各阶段的安全问题：

1. 构建阶段，保护镜像评估资产的风险，漏洞扫描，CI/CD集成，以及镜像仓库
2. 部署阶段，错误配置和漏洞点，合规性检查
3. 运行阶段，阻止攻击，监控容器，容器间的流量监控，可视化管理

注意事项：

1. 共享操作系统内核
2. 上线前未扫描
3. 不安全的配置
4. 存量镜像风险
5. 传统网络安全技术

容器安全落地

1. 基础镜像管理，经过深度扫描以及定期检查，补丁更新，保持简单化（拆分开）
2. Docker安全，主机和内核安全
3. 运行时入侵检测
4. 网络实现微隔离，不同pod间进行隔离，或者server Mesh技术，或者参考PCI-DSS合规标准
5. 微服务API安全，数据安全等
6. 资源控制，因为容器数量多，可以配置大型集群，因而资源竞争问题。
7. CIS安全基线检查
8. Kubernetes，计算资源，集群安全

5. 敏捷安全度量

成熟度模型

常见模型：可信研发与运营安全能力成熟度模型、研发运营一体化能力成熟度模型、DSOMM模型、BSIMM模型、SSE-CMM模型、SAMM模型

可信研发与运营安全能力成熟度模型

《面向云计算的可信研发及运营安全能力成熟度模型》 9大部分：

1. 管理制度
2. 要求阶段，明确安全要求等
3. 安全需求分析阶段
4. 设计阶段
5. 开发阶段
6. 验证阶段
7. 发布阶段
8. 运营阶段
9. 停用下现阶段

成熟度划分为三个级别： 基础级：有安全准则和要求，可实现基本的研发和运营安全 增强级：基础级基础上，借鉴国内外优秀实践，持续优化，可以实现一定程度的研发和运营安全 先进级：精细化安全要求基础上，通过新技术方法提升安全呢里，达到更高程度研发和运营安全

研发运营一体化能力成熟度模型

《研发运营一体化（DevOps）能力成熟度模型》 端到端的覆盖软件交付生命周期全流程的集合，总体划分四部分，过程（敏捷开发管理、持续交付、技术运营）、安全架构、安全管理和组织结构。

安全管理分四个板块，如下图：

OWASP DevSecOps成熟度模型

DevSecOps Maturity Model，DSOMM 强化了可以应用的安全措施，并展示了如何对这些㞞进行排序。

有四个方面的衡量：

1. 静态深度：静态代码分析的有多深
2. 动态深度：动态扫描执行有多深
3. 强度：安全扫描的调度频率有多激烈
4. 整合：处理结果的过程有多完整

也是设计软件开发生命周期中的成熟度体现，所以也可以与SAMM（软件成熟度模型）进行比较

软件安全构建成熟度模型（BSIMM模型）

通过一系列指标权重来可视化的评估软件安全计划的成熟度。

该模型是一种描述类型的模型，基于数据和事实来衡量，软件安全框架还为该模型提供了一套通用词汇表。

最新的版本还包括针对供应链的针对性措施，增强了云安全，容器等，攻击划分四个领域：管理、情报、SSDL触电和部署。

系统安全工程能力成熟度模型（SSE-CMM）

主要用于评测和改进整个信息安全系统全生命周期的安全工程活动，适用于所有安全工程活动的组织，例如，产品开发商销售商，系统集成商，服务提供商，采购方，安全评价组织等。

采购方可以通过该模型来评价上游组织机构的安全工程能力，该模型将安全工程划分为风险过程，工程过程和保证过程（共计11个过程域）

针对成熟度的指标体现，定义了5个过程能力级别，和1个非正式（未开展任何过程域的基本实践）

级别1：是否执行了上述基本实践过程 级别2：项目层面的定义，计划与执行问题 级别3：有原则的对已定义的过程进行剪裁 级别4：找到与组织业务目标相符合的度量方法 级别5：组织文化的调整以支撑获得的成果

软件保证成熟度模型（SAMM）

以软件开发的核心业务功能和安全保证实践为核心。定义了，治理、设计、开发、验证和运营。

定义了三种安全实践，涵盖所有领域，每个实践两个活动路，与不同的目标和不同成熟度级别的实践活动对齐，提高成熟度

几种模型对比如下：

度量实践框架

可以考虑5个方面：数据采集、指标建立、模型建立、平台建设、持续迭代改进，但是个人觉得大部分实践场景一般就是能把模型进行充分实践已经非常不错了，还有去评价模型实践的效果，量化出结论很难，可能更多是局部的获取一些优化策略。