diff --git a/10_第十章 软件安全开发/10.1 软件安全开发生命周期.md b/10_第十章 软件安全开发/10.1 软件安全开发生命周期.md
index 0e46bbb..d29e245 100644
--- a/10_第十章 软件安全开发/10.1 软件安全开发生命周期.md
+++ b/10_第十章 软件安全开发/10.1 软件安全开发生命周期.md
@@ -1,29 +1,270 @@
# 软件安全开发生命周期
->
+> **一、软件生命周期模型**
+> 了解软件生命周期的概念及瀑布模型、迭代模型增量模型、快速原型模型、螺旋模型、净室模型等典型软件开发生命周期模型。
+>
+> **二、软件危机与安全问题**
+> 了解三次软件危机产生的原因、特点和解决方案；
+> 了解软件安全和软件安全保障的基本概念。
+>
+> **三、软件安全生命周期模型**
+> 了解SDL、CLASP、CMMI、SAMM、BSIMM等典型的软件安全开发生命周期模型。
### 一、软件生命周期模型
+#### 1、软件的定义
+软件是与计算机系统操作有关的计算机程序、规程规则，以及可能有的文件、文档及数据。
+#### 2、软件生命周期模型
+- 瀑布模型
+- 迭代模型
+- 增量模型
+- 快速原型模型
+- 螺旋模型
+- 净室模型
+#### 3、瀑布模型
+1. **最早出现的软件开发模型**
+2. **核心思想**
+ - 按工序将问题简化
+ - 将功能的实现与设计分开
+3. **不足**
+ - 没有对开发周期后期发现错误做出相应的规定
+4. **应用场景**
+ - 规模较小
+ - 周期较短
+ - 需求明确
+
+#### 4、迭代模型
+
+1. **瀑布模型的小型化应用**
+2. **完整的工作流程**
+3. **降低风险**
+ - 增量开支的风险
+ - 产品无法按期进入市场的风险
+4. **加快开发进度**
+ - 任务清晰
+ - 需求更容易随需而变
+5. **关于迭代的认知**
+ - 选代模型是从深度或细化的程度来划分的，每阶段功能得到完善、增强；
+ - 迭代，就是在实现软件的每一功能求精的过程，是提升软件质量的过程，从模糊到清晰的过程。
+6. **应用场景**
+ - 需求频繁变更
+
+
+
+#### 5、增量模型
+
+- 融合了瀑布模型和迭代模型的特征；
+- 本质上是迭代，每个增量发布一个可操作产品。
+- 应用场景
+ - 周期短
+ - 规模大
+
+
+
+#### 6、螺旋模型
+
+- 兼顾快速原型的选代的特征以及瀑布模型的系统化与严格监控；
+- 引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失；
+- 构建原型是螺旋模型用以减小风险的途径；
+- 适合于大型的昂贵的系统软件开发；
+- 制定计划 - 风险分析 - 实施工程 - 客户评价（4个象限）。
+
+
+
+#### 7、其他软件开发方法
+
+1. **快速原型模型**
+
+ - 快速原型模型又称原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上逐渐完成整个系统的开发工作。
+
+ - 应用场景：需求不明确
+
+2. **净室模型**
+
+ 净室是一种应用数学与统计学理论以经济的方式生产高质量软件的工程技术。力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷。
+
+
### 二、软件危机与安全问题
+#### 1、第一次“软件危机”
+- 20世纪 60年代
+- 根源：日益庞大和复杂的程序对开发管理的要求越来越高。
+- 解决：软件工程
+#### 2、第二次“软件危机”
+- 20世纪 80年代
+- 根源：软件规模继续扩大，程序数百万行，数百人同时开发，可维护性难。
+- 解决：面向对象语言 - `C++`、`java`、`c#`
+#### 3、第三次“软件危机”
+- 21世纪 头十年
+- 根源：软件安全
+- 解决：软件安全开发生命周期管理
+#### 4、软件安全问题
+> 软件缺陷普遍存在
+- 千行代码缺陷数量（千行代码缺陷率）
+ - 普通软件公司：4～40
+ - 高管理软件公司：2～4
+ - 美国NASA软件：0.1
+- 漏洞数量
+#### 5、软件安全问题产生
+1. **内因**
+ - 软件规模增大，功能越来越多，越来越复杂
+ - 软件模块复用，导致安全漏洞延续
+ - 软件扩展模块带来的安全问题
+
+ 
+
+2. **外因**
+
+ - 互联网发展对软件安全的挑战
+
+ - 开发环境和开发人员对软件安全的挑战
+
+ 1. 开发者缺乏安全开发的动机
+
+ - 市场和业务要求将交付期和软件功能做主要因素
+
+ - 用户方没有提供安全方面的压力
+
+ 2. 开发者缺乏相关知识
+
+ - 软件复杂性加大，开发者需要学习更多东西
+
+ - 传统软件开发不进行安全教育
+
+ 3. 缺乏安全开发工具
+ - 缺乏安全开发配套管理、测试等工具
+
+#### 6、软件安全保障
+
+- 贯彻风险管理的思想
+ - 安全不必是完美无缺的，但风险必须是可管理的；
+ - 树立对软件安全控制的信心，该信心是通过保障活动来获取的。
+- 通过在软件开发生命周期各阶段采取必要的、相适应的安全措施来避免绝大多数的安全漏洞。
+- 采取措施只能有效减少，但并不能完全杜绝所有的安全漏洞！
+
+### 三、软件安全开发生命周期模型
+
+#### 1、软件安全开发覆盖软件整个生命周期
+
+- 需求分析阶段考虑软件的安全需求
+- 在设计阶段设计符合安全准则的功能
+- 编码阶段保证开发的代码符合安全编码规范
+- 安全测试和运行维护确保安全需求、安全设计、安全编码各个环节得以正确有效的实施
+
+> 在软件的各个阶段引入安全措施！
+
+#### 2、V模型
+
+- **开发阶段**：需求分析、概要设计、详细设计、编码阶段
+- **测试阶段**：验收测试、系统测试、集成测试、单元测试
+
+#### 3、软件安全问题越早解决成本越低
+
+- 在软件开发生命周期中后面的阶段改正错误开销比前面的阶段要高出数倍；
+- NIST：在软件发布以后进行修复的代价是在软件设计和编码阶段即进行修复所花代价的30倍。
+
+#### 4、相关模型和研究
+
+1. **安全软件开发生命周期**
+ - 安全设计原则
+ - 安全开发方法
+ - 最佳实践
+ - 安全专家经验
+2. **多种模型被提出和研究**
+ - 可信计算安全开发生命周期（微软）
+ - CLASP（OWASP）综合的轻量应用安全过程
+ - BSI系列模型（Gary McGraw等）
+ - SAMM（OWASP）软件保证成熟度模型
+
+#### 5、SDL
+
+1. **什么是SDL**
+
+ 安全开发生命周期（Security Development Lifecycle，SDL）
+
+2. **SDL发展**
+
+ 
+
+3. **SDL的阶段和安全活动**
+
+ - 七个阶段
+ - 十七项必需的安全活动
+
+ 
+
+#### 6、CLASP
+
+1. **什么是CLSAP**
+ - 综合的轻量应用安全过程（Comprehensive，Lightweight Application Security Process，CLASP）
+ - 用于构建安全软件的轻量级过程，由30个特定的活动(activities)和辅助资源构成的集合
+ - 针对这些活动给出了相应的指南、导则和检查列表
+2. **特点**
+ - 基于角色的安排
+
+#### 7、CMMI
+
+1. **什么是CMMI**
+
+ - 软件能力成熟度集成模型（Capability Maturity Model Integration）
+
+2. **五级**
+
+ 
+
+3. **过程区域**
+
+#### 8、SAMM
+
+1. **什么是SAMM**
+
+ - 软件保证成熟度模型（Software Assurance Maturity Mode，SAMM）
+ - 提供了一个开放的框架，用以帮助软件公司制定并实施所面临来自软件安全的特定风险的策略。
+
+2. **核心业务功能**
+
+ SAMM规定了4个软件开发过程中的核心业务功能，包括治理、构造、验证以及部署，这4个业务功能各包括了3个安全实践。
+
+ - 治理：专注软件开发企业组织管理其软件安全开发相关的过程、活动和措施，主要包括策略与指标、教育与指导、政策与遵守等三项安全实践。
+ - 构造：关注与软件安全开发中需求、目标和架构方面的过程、活动和措施，主要包括安全需求、威胁评估和安全架构3个方面的安全实践。
+ - 验证：注重软件检查和测试中的过程、活动和措施，主要包括设计审核、安全测试和代码审核三项安全实践。
+ - 部署：强调了软件发布和部署配置时相关的过程、活动和措施，主要包括环境强化、漏洞管理和操作启用3项安全实践。
+
+ 
+
+#### 9、BSI系列模型
+
+1. **BSI （Building Security IN）**
+ - 使安全成为软件开发必须的部分
+ - 强调应该使用工程化的方法来保证软件安全
+2. **软件安全的三根支柱**
+ - 风险管理：策略性方法；
+ - 接触点：一套轻量级最优工程化方法，攻击与防御综合考虑；
+ - 安全知识：强调对安全经验和专业技术进行收集汇总，对软件开发人员进行培训，并通过安全接触点实际运用。
+3. **BSIMM - BSI成熟度模型**
+ - 对真实的软件安全项目所开展的活动进行量化
+ - 构建和不断发展软件安全行动的指南
+
+#### 10、各模型比较
+
+
-### 三、软件安全开发生命周期模型
\ No newline at end of file
diff --git a/10_第十章 软件安全开发/10.2 软件安全需求及设计.md b/10_第十章 软件安全开发/10.2 软件安全需求及设计.md
index c199272..d0e2ff7 100644
--- a/10_第十章 软件安全开发/10.2 软件安全需求及设计.md
+++ b/10_第十章 软件安全开发/10.2 软件安全需求及设计.md
@@ -1,27 +1,209 @@
# 软件安全需求及设计
->
+> **一、威胁建模**
+> 理解威胁建模的作用及每个阶段的工作内容；
+> 掌握STRIDE模型用于进行威胁建模实践。
+>
+> **二、软件安全需求分析**
+> 理解软件安全需求在软件安全开发过程中的重要性；
+> 理解安全需求分析的方法和过程。
+>
+> **三、软件安全设计**
+> 理解软件安全设计的重要性及内容和主要活动；
+> 理解最小特权、权限分离等安全设计的重要原则；
+> 理解攻击面的概念并掌握降低攻击面的方式。
### 一、威胁建模
+#### 1、什么是威胁建模
+威胁建模是了解系统面临的安全威胁，确定威胁风险并通过适当的缓解措施以降低风险，提高系统安全性的过程。
+#### 2、为什么要威胁建模
+- 帮助在设计阶段充分了解各种安全威胁，并指导选择适当的应对措施；
+- 对可能的风险进行管理；
+- 可以重新验证其架构和设计；
+- 有助于软件的受攻击面降低。
+#### 3、威胁建模流程
+
+1. **确定对象**
+ - 确定要保护和评估的目标（资产）
+ - 在使用实例和应用场景中分析
+ 1. 明确应用或系统的关键威胁场景
+ - 部署方式、配置信息、用户使用方式等
+ 2. 典型场景
+ - 移动或小型设备物理失窃场景
+ - Web应用匿名用户场景
+2. **识别威胁**
+
+ - 识别每一个可能面临的威胁
+
+ - 理解软件可能面临的威胁是安全开发的前提
+ - 威胁不等于漏洞
+ - 威胁永远存在
+
+ 
+
+ - 理解STRIDE六类威胁
+
+ 
+
+3. **评估威胁**
+
+ - 评估威胁风险值
+ - 评估被利用和攻击发生的概率
+ - 评估攻击后资产的受损后果，并计算风险
+
+ > 参考风险管理、安全工程中相关内容！
+
+4. **消减威胁**
+
+ - 重新设计并排除这个威胁
+ - 使用标准的威胁消减技术
+ - 发明新的消减方法
+ - 根据安全Bug标准来确定是否可接受风险
+ - 把威胁作为漏洞记录下来，以后再想办法消减
+
+ > 要想办法消减每个威胁！
### 二、软件安全需求分析
+- 软件安全需求和设计是开发安全软件的基础。
+#### 1、软件安全需求分析
+- 以风险管理为基础，建立“威胁”分析计划；
+- 建立软件安全需求定义，确保软件安全需求定义正确；
+- 安全需求应文档化。
+#### 2、软件安全设计
+- 软件系统的每一项需求，都应该在软件安全设计阶
+ 段认真考虑
+#### 3、安全需求分析
+1. **安全需求分类**
+ - 安全功能需求
+ - 安全保障需求
+2. **需求分析的要点**
+
+ - 安全需求进行有效定义
+
+ - 不仅考虑系统功能，还要考虑系统不应该做什么
+
+ - 功能需求、安全需求、安全目标要达到平衡
+
+ > 需求工程师不要仅仅从用户的角度出发考虑系统的功能，还应从攻击者的角度出发考虑系统的漏洞。
+
+3. **需求分析过程**
+
+ - 系统调查
+ - 定性分析系统的脆弱点和可能遭受的安全威胁
+ - 脆弱点和安全威胁的定量分析
+ - 需求的确定
+
+ > 建立在风险分析的基础上！
+
+#### 4、安全设计的重要性
+
+- 安全编码？安全测试？
+
+ - 传统方法：软件发布后测试、等待修复Bug
+ - Gary McGraw：50%的安全问题由设计瑕疵引l起
+ - 安全提前介入，效益高，成本低
+
+ 
+
+- 设计缺陷 - 举例
+
+ - Microsoft Bob
+ - 明文存储口令，甚至将口令拿到客户端对比验证
+
+### 三、软件安全设计
+
+#### 1、安全设计阶段
+
+1. **安全概要设计阶段**
+ - 包括但不限于：安全体系结构设计、各功能块间的处理流程、与其他功能的关系、安全协议设计、安全接口设计等。
+
+2. **安全详细设计阶段**
+ - 详细设计阶段作为安全功能的程序设计阶段，应当直接指导安全功能的编码工作。包括但不限于：模块设计、内部处理流程、数据结构、输入/输出项、算法、逻辑流程图等。
+
+> 根据安全需求方案确定的安全目标，对初步风险评估确定的控制措施的具体技术实现而进行安全设计。
+
+#### 2、安全设计的主要活动
+
+- 详细风险评估
+- 控制措施选择
+- 安全技术实现
+- 安全设计评审
+
+#### 3、安全设计原则
+
+- **最小特权原则**
+ - 对于请求存储资源的主体，只应该分配最少的必要权限，而且应该保证赋予权限分配的必要时间最短。如果授予一个用户或进程、组件超过其行为必要的权限范围的许可，该用户或进程、组件就有可能获得或修改其没有权限处理的信息。
+- **权限分离原则**
+ - 尽量把软件划分为不同独立的组件，把权限分离成不同的权限许可和认证条件，把用户分离成不同的权限角色。不要将权限一次性授予给一个用户，而是根据需要提供多重的认证与检查机制再进行授予。
+- **最少共享机制原则**
+ - 避免多个主体共享同一个资源，因为敏感的信息可能通过相同的机制在这些主体之间共享导致被其他用户获取。每个主体应该有不同的机制或不同的机制实例，在保证多用户存取访问的灵活性的同时，防止由单一的共享机制导致潜在违背安全性的行为。
+- **完全中立原则**
+- **心理可接受度原则**
+- **默认故障处理保护原则**
+- **经济机制原则**
+- **不信任原则**
+ - 开发者应该假定系统环境是不安全的。减少对用户、外部系统、其他组件的信任，对外部实体所有的输人都需要进行检查，即使对于可信的外部用户输人。另外也不应该信任每次对函数或系统的调用操作都必然会成功，如内存的分配，因此必须对每次函数或系统的调用的返回值进行检查，并进行正确的处理。
+- **纵深防御原则**
+ - 软件应该设置多重安全措施，并充分利用操作系统提供的安全防护机制，形成纵深防御体系，以降低攻击者成功攻击的机率和危害。结合多重安全措施使攻击者要绕过每一个机制才能达到目的，提高了攻击者的攻击成本和要求，降低了安全危害。
+- **保护最薄弱环节原则**
+- **公开设计原则**
+- **隐私保护原则**
+ - 系统收集到的用户信息都必须实施妥善和安全的保护。攻击者获得了用户的隐私数据之后，可以发起进一步针对用户的各种攻击，如欺骗等，不应该向其他用户泄露用户的隐私信息。
+- **攻击面最小化原则**
+ - 攻击面（Attack Surface），通常也称受攻击面，是指对一个软件系统可以采取的攻击方法集合。因为攻击者对软件的攻击是从其暴露在外部的接口、功能、服务和协议等资源来实施的，通过对每种资源计算其被攻击成功的可能性，并将这些可能性综合归纳，即可衡量软件的攻击面大小。可以看出，一个软件的攻击面越大，其安全风险也就越大。
+
+#### 4、攻击面相关概念
+
+- **降低攻击面**
+
+ 1. 作用
+ - 攻击面越小，安全风险越小
+ 2. 实现
+ - 取消不需要的功能
+ - 增加对功能的安全防护
+ 3. 示例
+ - SQL Server 2005默认关闭`xp_cmdshell`存储过程
+ - `xp_cmdshell`使用的注意事项：
+ 1. 必须具有sysadmin角色
+ 2. 必须在master数据库下执行
+ 3. SQL2000中缺省情况下xp_cmdshell是启用的
+ 4. SQL2005及后续产品中xp_cmdshell是禁用的
+
+- **分析软件攻击面**
+
+ - 分析产品功能的重要性（是否必须）
+ - 分析从哪里访问这些功能（本地&远程）
+ - 分析访问权限（匿名&经过认证）
+
+ 
+
+- **降低攻击面策略**
+
+ - 重要等级为低的功能：攻击面大，取消该功能；
+ - 重要等级为中的功能：攻击面大，设置为非默认开启，需要用户配置后才予以开启；
+ - 重要等级为高的功能：攻击面大，关闭或限制一些接口方式，增加一些安全的保证措施或技术。
+
+ > 降低受攻击面对于提高软件源代码安全性至关重要！
+
+- **降低软件攻击面通常做法**
+
+ 
-### 三、软件安全设计
\ No newline at end of file
diff --git a/10_第十章 软件安全开发/10.3 软件安全实现.md b/10_第十章 软件安全开发/10.3 软件安全实现.md
index 830c750..94baf29 100644
--- a/10_第十章 软件安全开发/10.3 软件安全实现.md
+++ b/10_第十章 软件安全开发/10.3 软件安全实现.md
@@ -1,29 +1,170 @@
# 软件安全实现
->
+> **一、安全编码原则**
+> 了解验证输入、避免缓冲区溢出、程序内部安全安全调用组件、禁用有风险的函数等通用安全编程准则；
+> 了解相关的安全编码标准及建议；
+> 理解常见的代码安全问题及处置办法。
+>
+> **二、代码安全编译**
+> 了解代码编译需要关注的安全因素。
+>
+> **三、代码安全审核**
+> 理解代码审查的目的；
+> 了解常见源代码静态分析工具及方法。
### 一、安全编码原则
+#### 1、验证输入
+- **对所有输入数据进行检查、验证及过滤**
+ - 应用软件的“数据防火墙”，避免恶意数据进入。
+- **什么时候验证**
+ - 最初接收数据时
+ - （第一次）使用数据时
+- **常见输入源**
+ 1. 命令行
+ - 参数数量、数据格式、内容
+ 2. 环境变量
+ - 环境变量可能超出期望
+ - 有的环境变量存储格式存在危险
+ 3. 文件
+ - 不信任可以被不可信用户控制的文件内容
+ - 不信任临时文件
+ 4. 网络
+ - 来自网络的数据是“高度不可信的“
+ 5. 其他来源
+#### 2、避免缓冲区溢出
+- **缓冲区溢出**
+ - 缓冲区：包含相同数据类型的实例的一个连续计算机内存块
+ - 溢出：数据被添加到分配给该缓冲区的内存块之外
+- **外部数据比目标空间大**
+- **是一个非常普遍而且严重的问题**
+ 
+- **溢出后果**
+ - 攻击者可以使远程服务程序或者本地程序崩溃
+ - 攻击者可以设计溢出后执行的代码
+
+- **C/C++语言**
+
+ - 语言特性决定
+ - 大量的库函数存在溢出
+ - `strcpy`、`strcat`、`gets`等
+
+- **其他语言**
+
+ - 调用C语言库
+ - C#允许设置“不安全”例程
+
+- **解决办法**
+
+ - 填充数据时计算边界
+ - 动态分配内存
+ - 控制输入
+ - 使用没有缓冲区溢出问题的函数
+ - `strncpy`、 `strncat`、C++中`std:string`
+ - 使用替代库
+ - `Libmib`、`libsafe`
+ - 基于探测方法的防御
+ - `StackGuard`、`ProPolice`、`/GS`
+ - 将一个“探测”值插入到返回地址的前面
+ - 非执行的堆栈防御
+ - 不可在堆栈上执行代码
+
+#### 3、程序内部安全
+
+1. **程序内部接口安全**
+ - 程序内部接口数据的检查。
+2. **异常的安全处理**
+ - 检测异常，安全处理各种可能运行路径；
+ - 检测到某些错误行为/数据，必须以合适的方式处理，保证程序运行安全；
+ - 必要时立即拒绝服务，.甚至不回送详细的错误代码。
+3. **最小化反馈**
+ - 避免给予不可靠用户过多的信息
+ - 成功或失败
+ - 作为跟踪检查的日志可以记录较为详细的信息
+ - 认证程序在认证前尽量少给信息
+ - 如果程序接受了密码，不要返回它
+4. **避免竞争条件**
+ - 访问共享资源时（文件/变量）没有被适当地控制
+ - 使用原子操作
+ - 使用锁操作避免死锁
+5. **安全使用临时文件**
+
+#### 4、安全调用组件
+
+1. **应用程序实际上几乎都不会是自包含的，它们通常都会调用其他组件**
+
+ - 底层的操作系统
+
+ - 数据库
+
+ - 可重用的库
+
+ - 网络服务（WEB、DNS）
+
+2. **使用安全组件，并且只采用安全的方式**
+
+ - 检查组件文档，搜索相关说明
+ - gets
+ - 随机数
+
+ - 使用经过认可的组件
+
+ - 尽可能不调用外部命令，如果不得已要调用，必须严格检查参数
+ - `system`、`open`、`exec`
+
+3. **正确处理返回值**
+ - 一定要检查返回值调用是否成功
+ - 成功时检查
+ - 返回值，是否按照期望值处理
+ - 数据中可能含有NULL字符、无效字符或其他可能产生问题的东西
+ - 错误时检查
+ - 错误码
+4. **保护应用程序和组件之间传递的数据**
+ - 视安全需求和安全环境
+ - 考虑传输加密，包括密码算法和安全协议
+
+#### 5、禁用不安全函数
+
+- 编码中禁止使用的危险函数举例
+
+ 
### 二、软件安全编译
+#### 1、确保编译环境的安全
+- 使用最新版本编译器与支持工具
+- 可靠的编译工具
+- 使用编译器内置防御特性
+#### 2、确保运行环境的安全
+- 将软件运行环境基于较新版本的系统
+### 三、代码安全审核
+#### 1、什么是源代码审核
+- 通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性，报告源代码中可能隐藏的错误和缺陷。
+#### 2、源代码审核方式
+- **人工审核**
+ - 费时费力
+ - 容易遗漏
+- **工具审核**
+ - 速度快自动
+ - 可升级知识库
+> 统计证明，在整个软件开发生命周期中，30%至70%的代码逻辑设计和编码缺陷是可以通过源代码审核来发现的。
-### 三、代码安全审核
\ No newline at end of file
+> 在软件编码完成后，理想的做法是使用源代码审核工具审核和人工审核结合的方式对代码进行审核，能极大地减少软件中的安全问题被带人随后的软件生命周期阶段的可能性。
\ No newline at end of file
diff --git a/10_第十章 软件安全开发/10.4 软件安全测试.md b/10_第十章 软件安全开发/10.4 软件安全测试.md
index e6d08eb..d59027b 100644
--- a/10_第十章 软件安全开发/10.4 软件安全测试.md
+++ b/10_第十章 软件安全开发/10.4 软件安全测试.md
@@ -1,19 +1,173 @@
# 软件安全测试
->
+> **一、软件测试**
+> 了解软件测试的基本概念；
+> 了解常见的软件测试方法及不同测试方法之间的区别和优缺点。
+>
+> **二、软件安全测试**
+> 了解软件安全测试的基本概念；
+> 理解模糊测试、渗透测试等软件安全测试方法的原理、相互的区别以及各自的优势；
+> 掌握安全测试的思路和方法。
### 一、软件测试
+#### 1、基本概念
+1. **什么是软件测试**
+ - 使用人工和自动化的手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差异。
+2. **基本概念**
+ - 测试用例
+ - 测试用例是为某个特殊目的而编制的一组测试输人、执行条件以及预期结果。
+ - 测试覆盖率度量指标
+ - 测试覆盖率度量指标是测试完整性的一个手段，是测试有效性的一个度量。
+3. **测试的信条**
+ - 预期测试的测试结果是预先确定的；
+ - 好的测试用例发现错误的概率高；
+ - 成功的测试就是发现了错误的测试；
+ - 测试独立于编码；
+ - 需要具备应用（用户）及软件（编程）两方面的专业知识；
+ - 测试人员使用不同于开发人员的工具；
+ - 只检查常见的测试用例是不够的；
+ - 测试文档要能够再利用。
+#### 2、软件测试方法
+> 根据软件测试工作的测试策略，一般将软件测试过程分为单元测试、集成测试、系统测试和验收测试4个大阶段；
+> 根据对软件内部工作过程了解的程度又分为黑盒测试、白盒测试和灰盒测试；
+> 从测试过程中是否执行软件又可以将软件测试方法分为静态测试和动态测试。
+- **单元测试、集成测试、系统测试**
+ - 单元测试是对软件中的基组成单位进行的测试；
+ - 集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位时间之间的接口是否正确；
+ - 系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求。
+- **黑盒测试、白盒测试、灰盒测试**
+ - 黑盒测试意味着测试要在软件的接口处进行，因此黑盒测试又称功能性测试或数据驱动测试；
+ - 白盒测试也称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试，是对软件的过程细节做细致的检查。确定实际状态是否与预期的状态一致；
+ - 灰盒测试是一种介于白盒测试和黑盒测试之间的一种测试方法。灰盒测试关注输出对于输人的正确性，同时也关注内部表现。
+- **静态测试、动态测试**
+ - 静态方法是指不运行被测程序本身，静态测试又可分为代码走查、代码审查、代码评审；
+ - 动态方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等。
+- **回归测试**
+ - 回归测试是指在发生修改之后重新测试先前的测试以保证修改的正确性。
+- **验收测试**
+ - 验收测试旨在向购买者展示该软件系统满足其用户的需求；
+ - 这是软件在投入使用之前的最后测试。
+### 二、软件安全测试
+#### 1、什么是软件安全测试
+
+- 确定软件的安全特性实现是否与预期设计一致的过程
+- 有关验证软件安全等级和识别潜在安全缺陷的过程
+- 查找软件自身程序设计中存在的安全隐患，并检查应用程序对非法侵入的防范能力
+
+#### 2、为什么需要软件安全测试
+
+- 传统测试仅考虑软件出错时的处理，没有考虑对软件的故意攻击。
+
+#### 3、软件安全测试方法
+
+- 在应用投产前，应由独立的安全团队对应用的安全性进行综合评估
+ - 功能性安全测试
+ - 对抗性安全测试
+- 安全测试方法
+ - 模糊测试
+ - 渗透测试
+ - 静态源代码审核
+
+#### 4、模糊测试（Fuzzing）
+
+1. **什么是模糊测试**
+
+ - 也称Fuzzing测试，一种通过提供非预期的输入并监视异常结果来发现软件故障的方法。
+ - 黑盒测试，不关心被测试目标的内部实现，而是利用构造畸形的输入数据引发被测试目标产生异常，从而发现相应的安全漏洞。
+
+ > 非常有效的漏洞挖掘技术，已知漏洞大部分都是通过这种技术发现的。
+
+2. **强制软件程序使用恶意/破坏性的数据并进行观察结果的一种测试方法**
+
+ - 不够强壮的程序会崩溃
+ - 编码良好的程序正常运行
+
+3. **特性**
+
+ - 方法学
+ - 随机值
+ - 大量测试用例
+ - 查找漏洞或可靠性错误
+
+4. **模糊测试过程**
+
+ 1. 生成大量的畸形数据作为测试用例；
+ 2. 将这些测试用例作为输入应用于被测对象；
+ 3. 监测和记录由输入导致的任何崩溃或异常现象；
+ 4. 查看测试日志，深入分析产生崩溃或异常的原因。
+
+ 
+
+5. **影响模糊测试效果的关键因素**
+
+ 1. 测试点
+ - 数据通道入口、可信边界点
+ 2. 样本选择
+ - 选择覆盖面广、便于测试的多个样本
+ 3. 数据关联性
+ - 智能模糊测试
+ 4. 自动化框架
+ 5. 异常监控与异常恢复
+ 6. 分析评估
+
+#### 5、渗透测试
+
+1. **渗透测试**
+
+ - 通过模拟恶意攻击者进行攻击，来评估系统安全的一种评估方法；
+ - 从攻击的角度测试软件系统是否安全；
+ - 使用自动化工具或者人工的方法模拟攻击者的输入找出运行时刻目标系统所存在的安全漏洞。
+
+2. **优点**
+
+ - 找出来的问题都是真实的，七也是较为严重的。
+
+3. **缺点**
+
+ - 只能到达有限的测试点，覆盖率较低。
+
+4. **渗透测试流程**
+
+ 
+
+5. **渗透测试要点**
+
+ 1. 授权
+ 2. 测试目的
+ - 安全性的评估，不是摧毁或破坏
+ 3. 测试人员
+ - 技术、知识和经验很重要
+ - 像“坏人”一样思考问题
+ 4. 安全问题
+ - 系统备份和恢复措施
+ - 风险规避
+ - 渗透测试不要在业务的高峰期进行
+
+6. **灵活安排自己的“组合”**
+
+ - 代码审核 + 体系结构风险评估
+ - 基于风险的安全测试 + 渗透测试
+ - 安全需求分析 + 滥用案例开发
+ - 代码审核 + 渗透测试
+ - 体系结构风险分析 + 基于风险的测试
+
+#### 6、软件安全测试思路
+
+- 充分了解软件安全漏洞
+- 评估软件安全风险
+- 拥有高效的软件安全测试技术和工具
+ - 包括IMPACT、CANVAS和Metasploit；
+ - Metasploit为开放源代码。
-### 二、软件安全测试
\ No newline at end of file
diff --git a/10_第十章 软件安全开发/10.5 软件安全交付.md b/10_第十章 软件安全开发/10.5 软件安全交付.md
index 2485a7a..d6e1e60 100644
--- a/10_第十章 软件安全开发/10.5 软件安全交付.md
+++ b/10_第十章 软件安全开发/10.5 软件安全交付.md
@@ -1,27 +1,36 @@
# 软件安全交付
->
+> **一、软件供应链安全**
+> 了解软件供应链安全的概念并理解软件供应链安全措施。
+>
+> **二、软件安全验收**
+> 了解软件安全验收的重要性及需要考虑的内容。
+>
+> **三、软件安全部署**
+> 了解软件安全部署的重要性及软件安全加固、软件安全配置的概念。
### 一、软件供应链安全
+#### 1、供应链安全概念
+- 目前软件安全开发生命周期中新的威胁，涉及到软件的代码编写、代码编译、软件分发、软件更新
+- 代码编写：共享库
+- 代码编译：被污染的编译软件
+- 软件分发/更新：污染源头
+#### 2、供应链安全应对策略
-
-
-
-
+- 安全流程覆盖到引入的第三方代码中
+- 可靠的编译软件获取方式
+- 官方渠道、发布验证
### 二、软件安全验收
+- 正式的验收流程
+- 安全纳入到验收考虑中
+### 三、软件安全部署
-
-
-
-
-
-
-
-
-### 三、软件安全部署
\ No newline at end of file
+- 提供软件部署所需要的文档和工具
+- 软件加固
+- 软件安全配置
\ No newline at end of file