软件安全保障过程的研究和设计
杨凯
北京邮电大学计算机科学与技术学院，北京（100876）
摘要：软件安全性正越来越多地受到人们的关注。目前关于软件安全性研究大都集中于软件
生命期的测试和维护阶段。论述了在整个软件生命期考虑进安全性的必要性，重点研究了国
内外软件安全开发过程模型，提出了一个软件安全保障过程模型（OVSP），总结了当前研究
工作并指出了未来研究方向。
关键词：软件安全性；安全漏洞；软件生命期；软件安全开发过程；建模
中图法分类号：
1．引 言
由软件安全问题导致的损失是巨大的，据 CSI（Computer Security Institute）安全性调查
发现在 2001 年，2002 年和 2003 年因为安全缺陷造成的损失分别为 亿美元， 亿美
元和 亿美元 [3]。另外据统计，目前安全缺陷正以每天超过 10 个的速度在商业软件和开
源软件中蔓延[17]。因此软件安全问题应该受到人们的重视。
软件安全问题的根源可分为内因和外因两个方面。内因是指软件有错误，如脆弱点，缺
陷(设计层)和 Bug(实现层)，和软件开发方法存在问题；外因是指软件的运行环境，如网络
对软件发展产生的巨大影响（负面居多），外部环境（如黑客，恶意代码）和内部环境（如
误操作，报复，经济犯罪等）。
目前在安全软件开发方面有三种主要的方法：
第一种方法就是为软件打补丁，修复存在安全缺陷的应用程序。这种方法很通用，但是
在软件发布之后，发现并修复其中 bug 的成本是在开发阶段就解决此问题成本的 100 倍[16]。
另外，补丁中也有可能包含新的缺陷。
第二种方法是为软件创建安全的环境。比如安装入侵检测系统和防火墙。这些保护机制
可以提供一定程度的安全性，但是显然仍然是不够的，很多黑客能容易地越过这层保护膜。
第三种方法是构建安全软件工程，采用结构良好的开发过程，在软件生命期的各阶段都引
入安全思想。
为了确保软件安全，通常的做法是将这三种方法配合使用。不过综合来看更多地关注第
三种方法也许是目前最主要做的事。不仅是因为针对这种方法的研究还处于初级阶段，而且
根据 CERT/CC 调查，超过 90%的安全缺陷是在开发阶段产生的[6]。如果开发人员能及时避
免或移除这些安全缺陷，就会节约大量的人力和物力成本。因此本文主要探讨软件安全开发
过程这一问题。
2．研究现状
本节旨在探讨近年来最主要的软件安全开发过程模型。其中包括 Gary McGraw 团队的
1
SDLC（Software Development Life Cycle）最佳实践加强版本[1][2][5][6] ，David Byers 等人的
基于 SPI（Software Process Improvement）的安全过程模型 [13] 和 Shanai Ardi 的基于
OpenUP/Basic 开发过程的 S3P（Sustainable Software Security Process）插件模型[15] 。
SDLC最佳实践加强版本
软件开发过程可分为瀑布模型，IBM 的统一建模（RUP），极限编程，敏捷建模，螺旋
模型，能力成熟度模型集成（CMMI）和其它的一些涉及一系列制品的开发过程。图 1 展示
了基于上述模型骨架的 SDLC 最佳实践的加强版本。其中确定了很多活动和制品。
图 1 软件开发生命周期
表 1 给出了图 1 中某些名词定义。
表 1 术语说明
定义 构成 SDLC 制品
原则
Principles
安全性的实际经验 标题，定义（带有说明，举
例和参考），相关的指标和相
关的规则
安全性需求
和软件架构
指标
Guidelines
在语义级指导软件开发过程中
要做什么而不做什么。指标可以
帮助发现架构上的缺陷和实现
阶段产生的 bug。
上下文说明（平台，操作系
统，语言等），标题，类型，
目的，开发方案，说明，相
关 API，参考，相关原则，
规则，安全性需求和软件设
计
代码
规则
Rules
在语法级指导软件开发过程中
要做什么而不做什么。规则可以
上下文说明，ID，标题，攻
击类型，安全缺陷,位置，签
滥用用例，软
件设计文档，
需求和用例 设计 测试计划 编码 测试结果 反馈
滥用用例
安全需求
风险分析
外部复查
基于风险的
安全测试
静态分析（工具）
风险分析
渗透测试
安全断点
原则 攻击模式
指标 历史风险 安全漏洞 漏洞利用
规则
2
通过词汇扫描或构造的软件解
析（源代码或二进制）进行验证。
它们为具体的编程语言而存在，
能帮助发现实现阶段产生的
bugs。
名，举例，参考，相关原则，
相关指标
安全性测试
计划和渗透
测试（又称入
侵测试）
攻击模式
Attack Patterns
一个攻击模式是通过对大量的
漏洞利用进行推理而得的。攻击
模式帮助确定和量化风险。对于
误用用例和滥用用例的设计也
很有帮助。
上下文说明，标题，攻击类
型，说明，举例，参考，相
关原则，相关指标
代码
历史风险
Historical risks
实际软件开发过程中发现的风
险。风险伴随着条件和事件，并
可以计量风险发生的可能性和
造成的影响。历史风险对于在软
件开发过程中早期发现潜在的
事件是很好的资源，能够为缓解
风险提供潜在的线索和为提高
一致性和风险管理质量的思路。
标题，类型（业务或技术），
子类别，作者，主人，工程，
风险状态，可能性，影响，
风险上下文，风险描述，实
现指示器，影响说明，评估
的影响日期，潜在的成本，
紧急应变计划，相关业务目
标，相关风险，相关缓解和
诊断方法
软件架构，软
件设计，测试
计划
安全漏洞
Vulnerabilities
一个漏洞是软件缺陷的结果，攻
击者可以利用它获得合法访问
计算机系统的权限——或者对
安全造成负面影响。
上下文说明，标题，说明，
严重性，丢失类型和参考
代码，软件架
构，软件设
计，渗透测试
漏洞利用
Exploits
一个漏洞利用是利用一个具体
的漏洞或一系列漏洞对计算机
系统进行攻击的一个事例。
上下文说明，标题，说明，
前置条件，动机，暴露类型，
漏洞利用代码，封锁方法和
相关的漏洞
穿透测试（又
为入侵测试）
基于SPI的安全过程模型
此安全性过程是软件过程提高（SPI）的过程，它与软件生命期并行并穿越整个生命期，
其输出可用于软件开发过程的提高。由三个主要步骤组成，如下图 2 所示：[13]
3
图 2 软件生命过程上下文中的软件过程
（1）漏洞建模（Vulnerability Modeling）：产生漏洞原因图（VCG），如下图 3 所示，
VCG（Vulnerability Cause Graph）表明了在整个生命期中导致漏洞的条件和事件。图 3 是一
个小型的 VCG 举例。从此模型中可看到，漏洞 V 可以通过移除原因 A 和和原因 B 和 C 其
中之一或全部得以阻止。V 也可以通过移除原因 D 和 E 得以预防。
原因 D 原因 E
原因 A 原因 B 原因 C
新的/重现的漏洞
漏洞建模 漏洞移除 过程成分定义
需求 架构 设计 实现 测试 部署 维护
软
件
生
命
期
新移除技术 新的或改变的风险过程环境改变
过程改变
安
全
过
程
漏洞 V
图 3 漏洞原因图（Vulnerability Cause Graph）
在漏洞原因确定之前漏洞必须被完全理解，我们通过深度分析法对漏洞进行建模。这种
分析法可以容易地确定直接原因（一般在源代码中就能发现），然后再寻找间接原因。为了
确定原因，此过程需要外部资源的配合（比如需求分析和设计文档，版本控制历史，过程文
档等）。
（2）漏洞原因移除（Vulnerability Cause Mitigation）：是一个确定如何阻止 VCG 中出现
的漏洞原因的过程。这里也采用了被称为安全活动图（Security Activity Graph 简称 SAG）[18]
的结构化表示方法。SAG 表明了在软件生命期中一个漏洞或其原因是如何被阻止的。叶子
节点代表活动；使用逻辑与和逻辑或将其联系在一起形成一张图，图 4 表示了单一原因的
4
SAG。
设计和代码间的交叉索引
创建可识别的设计对象
缺少设计到实现的可跟踪性
连接代码和设计对象的注释
根据设计产生所有代码
图 4 安全活动图（Security Activity Graph）
活动需要被完全文档化，包含了如何实现和验证它们的详细信息。每个漏洞对应的 SAG
是根据 VCG 中的漏洞原因自动形成的。
（3）过程成分定义（Process Component Definition）：是一个为了阻止软件漏洞的产生
而从一系列软件安全活动图中选择要实现的活动的过程。这些活动被赋予了权值，只有具有
最佳权值的活动才被选择。一个活动的权值依赖于一些因素，比如对开发过程，产品，人员
和组织的适应性，执行活动的成本，所需工具和培训的成本等等。一旦确定了 SAG（或 SAG
集）和活动的权值，就能够从中选出一个防止漏洞产生的最小成本活动集。
基于OpenUP/Basic开发过程的S3P模型
此模型跟基于 SPI 的安全过程模型类似（如图 5 所示），所不同的是，本模型使用的是
OpenUP/Basic 开发过程。
5
图 5 安全 OpenUP/Basic 过程
OpenUP/Basic 是一个使用敏捷方法进行软件开发的过程。其对象是 3-6 个人的小团队在
3-6 个月内完成的小的项目。由于 OpenUP/Basic 应用面较窄，在此不做详述，有兴趣者可参
考文献[19]。
此模型的一个创新点是将 S3P（Sustainable Software Security Process 持续软件安全过程）
作为一个插件，很好地融入了 Eclipse 开发环境。为了定义安全性插件的结构，我们为在软
件开发过程中使用 S3P 假定了一个场景，这个场景包含下面的步骤：
（1）在软件开发过程中发现安全问题和漏洞并对此文档化；
（2）选择被强调的问题；
（3）根据被选择的问题创建 S3P 输入文档；
（4）执行 S3P 的步骤；
（5）定义由 S3P 产生的过程成分；
（6）过程成分提交至开发过程。
总结
通过对上述三个过程模型的描述，我们可以发现 SDLC 最佳实践加强版本是安全软件过
程的概述，内容比较详细，侧重从理论方面进行理解；而基于 SPI 的安全过程模型则可看作
是 SDLC 最佳实践加强版本模型的具体化或深化，更便于实现；最后，基于 OpenUP/Basic
开发过程的 S3P 插件模型则是融合了基于 SPI 的安全过程模型的基本思想和 OpenUP/Basic
开发过程，此模型最值得赞赏的是将 S3P 做成了插件，可以得到更好更方便的利用，但是也
显现出了适用面窄的缺陷。
Sustainable Software Security Process (S3P) 安
全
插
件
安全报告：新的/重现的漏洞
漏洞建模 漏洞移除 过程成分定义
安全性检查列表
OpenUP/Basic
lifecycle 开始 详细阐述 构 建
ConstructionInception Elaboration
转换
Transition
6
3．面向VAD的安全过程模型
VAD 框架
在对上述三个模型充分理解的基础上提出了本文的安全开发过程模型——面向 VAD
（Vulnerability Analysis Database）的安全过程模型（Oriented VAD’s Security Process Model），
简称 OVSP。本模型采纳了三个模型的基本思想和各自的优点，从另一个视角对安全开发过
程进行了描述。该模型的框架如图 6 所示：
图 6 面向 VAD 的安全过程模型
基于 OVSP，软件生命期的每一阶段都与 VAD 交互，漏洞分析数据库 VAD（Vulnerability
Analysis Database）是一个共享仓库，其内容我们在后面列出。我们为图 6 中的每个箭头都
赋予了标号，每个标号代表的元素如下表 2 所示：
表 2 软件生命期各阶段/过程与 VAD 的交互说明表
标号 所属阶段/过程 IN（入 VAD） OUT（出 VAD）
1 需求 安全需求说明，新漏洞 需求阶段容易出现的漏洞，攻
击树模型，误用/滥用用例
2 架构 架构说明，新漏洞 架构阶段容易出现的漏洞，架
构风险分析
3 设计 设计说明文档，新漏洞 设计阶段容易出现的漏洞，威
胁模型，攻击树模型
漏洞建模 漏洞移除 过程成分定义
需求 架构 设计 实现 测试 部署 维护
软
件
生
命
期
新移除技术 新的或改变的风险过程环境改变
10
漏洞建模工具
1
3 2 4 5 6
7
8
9
可
做
成
工
具
VAD
漏洞分析数据库
7
4 实现 代码，版本控制新漏洞等 实现阶段易出现的缺陷，漏洞
移除建议/活动等
5 测试 安全测试用例，安全测试计
划新漏洞等
安全测试指导，各种安全测试
模型说明等
6 部署 部署说明文档新漏洞等 部署时的安全指导
7 维护 维护文档新漏洞等 风险分析，渗透测试用例等
8 漏洞建模
9 漏洞移除
10 过程成分定义
漏洞或安全缺陷 VCG，SAG，安全活动等
说明：1-7 是通常的软件开发过程，可将各阶段产生的相关制品存储到 VAD 中，而从
VAD 中的所得依赖于 VAD 的完善或智能程度；8-10 可在 1-7 中的任何阶段使用，可以做成
一个工具，用户只需输入安全漏洞/缺陷，最佳安全活动可自动作为结果输出，而用户不必
知道其中各阶段与 VAD 交互的细节。
各阶段活动描述
需要注意的是并非软件生命期的各个阶段只与 VAD 交互以后就能将缺陷移除，VAD 只
提供缺陷预防，发现和移除的指导作用，所以各个阶段还需要进行下面一系列的活动[12]：
1．需求阶段：安全需求分析，以 VAD 的输出为参考确定此阶段可能出现的漏洞；
2．架构阶段：进行架构风险分析，主要活动是从适当的高度建立一个目标系统的视图，
避免“只见树林不见森林”，提倡“forest-level”视图。在 forest-level 视图中主要分析以下
几个方面：威胁（谁可能攻击系统）、每一层环境中的风险、每个组件和数据流中可能存在
的漏洞、技术风险可能造成的商业破坏、风险被实现的可能性、任何在每一层能够实现的可
行对策、考虑整个系统范围内的可用保护机制。
3．设计阶段：可以分为 13 项活动[16]：
（D1）根据项目类型，需求和期望的功能，选择合适的编程语言。这是一项重要的决
定，可以减轻很多可能出现的缺陷（Vulnerabilities）；
（D2）采用最小权限和职责分离原则；
（D3）为了敏感数据（尤其需要高度保密的数据）的安全存储，使用合适的访问控制
和加密算法；
（D4）为保证数据（尤其是敏感数据）的安全传输，采用安全的数据传输协议；
（D5）应用复杂的密码策略，以选择适当的密码；
（D6）为了检测不可信的代码并阻止它们进入系统，要对移动代码进行有效性检查。
这也包括上传文件和附属的电子邮件的有效性验证；
（D7）使用合适的认证，至少是用户名和密码的组合。这一过程不能用纯文本格式验
证数据。上锁机制也是这一类活动；
（D8）避免外来数据的日志；
8
（D9）减少请求以避免 DoS（拒绝服务）或低性能。这可以通过过滤不必要的请求来
实现，但并不总是容易的工作；
（D10）如果有必要，对共享资源使用合适的上锁机制；
（D11）为登陆系统或使用资源设定具体的时间限制；
（D12）使用内部而非外来通话；
（D13）通过预料所有可能的状态和事件和为每个错误处理采取合适的行动而安全地失
效。
4．实现阶段：可分为 19 项活动：
（I1）采用标准的和定以良好的编程结构编码；
（I2）进行安全代码复查，可使用自动化的工具实现；
（I3）服务器端用户输入数据的校验；
（I4）输出验证；
（I5）使用存储过程而不是动态 SQL；
（I6）变量声明后立刻初始化；
（I7）验证函数的返回值；
（I8）数组边界检查；
（I9）在使用任何指针之前和指针释放之后 null 指针的设置进行全面检查；
（I10）使用标准的函数库重新实现不安全的函数；
（I11）使用现存的库函数阻止非法代码的执行。举例：如果攻击导致堆栈崩溃，程序
至少可以发出警告；
（I12）为内存分配或数组寻址的可能需求而检查计算结果；
（I13）数组处理而不是直接的指针操纵；
（I14）程序中静态创建外部命令；
（I15）通过清楚地变量类型声明，避免弱的或不清晰的变量；
（I16）不使用用户无法控制的静态字符串，格式化字符串函数和检查发给函数的参数
数量；
（I17）为临时文件选择合适的，很难猜到的位置，并将访问控制机制应用其上。最好
不要产生客户端的临时文件；
（I18）明确声明所有用到的函数；
（I19）伴随出错信息的合适的错误/异常处理。
5.测试阶段[9]：主要进行渗透测试和基于风险的安全测试。
渗透测试是针对系统威胁尝试对系统进行渗透，包括：积极（正向）测试，验证软件正
常执行了规定的任务；消极（负向）测试，安全测试人员必须深入研究安全风险（可能由滥
用用例和体系风险驱动）以便确定系统在攻击之下如何反应。
基于风险的安全测试旨在揭示可能的软件风险和潜在攻击。使用传统方式的标准测试组
织可以执行功能安全测试而基于风险的安全测试更依赖于专门技术和经验，而不是测试经验
9
和安全经验；需要教会测试专业人员学会在测试时像攻击者一样思考。实施方式有：白盒测
试——静态分析，根据基于对软件体系深入的理解而进行的风险分析的结论进行测试；黑盒
测试，运行程序－－恶意输入[4]。
6．部署阶段：此阶段出现安全漏洞的机率很小，可以暂不研究；
7．维护阶段：目前大部分人的研究都是集中在此阶段，相关的文献也不少，主要研究
点在软件缺陷的预测，缺陷的分类，安全性检测，缺陷分析和评估等方面，在此不在详述。
VAD 的内容
对于软件开发过程的各阶段中与 VAD 的交互（标号 1-7）可以通过可视化的方式进行，
各阶段软件开发相关人员通过数据库 Web 接口与 VAD 交互，可以将相关文档，制作的用例，
发现的漏洞等通过图形化界面存储到 VAD 中。另外也可以通过图形化界面查询漏洞原因，
移除和预防漏洞的方法或活动等等。如下图 7 所示。
图 7 漏洞分析数据库及交互图
使用此模型的关键在于 VAD 的构建，VAD 中的内容如图 7 所示应该包括：相关文档，
攻击树，威胁模型，VCG，SAG，漏洞，活动和滥用/误用用例等。下面做简单说明：
（1）漏洞（Vulnerabilities）：被分析到的每个漏洞都要加入到 VAD 中，每个漏洞都要
包括 ID，标题，漏洞概要和说明等等
数据库
Web 接口
滥
用
/
误
用
用
例
漏洞分析数据库
各阶段软件开
发相关人员
VAD
文档
漏洞
漏洞原因图
VCG
安全活动图
SAG
活动
威胁模型
攻击树
S3P 工具
VAD 构建者
原因
其它相关工具
10
（2）漏洞原因图（VCG）：产生的每个漏洞原因图都存储在 VAD 中，该图可被可视化，
可被连接到它代表的漏洞，也可被连接到它所包含的原因上。
（3）原因（Causes）：VCG 中的每个原因都包括：ID，标题，概要，深度分析说明，
代码实例,相关的漏洞和一个 SAG。如下图 8 所示
共享的数据和状态
ID： 共享的数据和状态
概要： 一个单独的变量既可以保存状态也可以保存数值
说明： 程序可以将数据和状态保存在同一位置即一个单独变量中。这个变量保存的
到底是数据还是状态取决于上下文。两者区分依赖于外部条件或变量中的当前值。
举例 在出错的条件下许多函数会返回一个错误的数值。例如 fgetc 函数在遇到文件
结束这一条件后会返回 EOF（典型值为-1），在没有遇到文件结束条件时会返回一个
字符。当程序员不正确地用分配的字符串变量接收函数返回值时就会遇到一个问题，
因为此时这个变量已被分配得值为字符 0xff，这就无法区分 EOF 和 0xff。
缓解： 共享数据和状态
在设计时分离
数据和状态
检验共享数据
和状态实例
用类型系统分
离数据和状态
图 8 一个典型的原因
（4）安全活动图（SAG）：产生的每个 SAG 被存储到 VAD，该图可被可视化，可被连
接到它代表的漏洞，也可被连接到它所包含的原因上。
（5）活动（Activities）：SAG 中的每个活动都包括：ID，标题，实现步骤，验证过程，
限制集,被评估的权值。
（6）相关文档：即安全过程各阶段与安全性相关的文档，如安全需求，测试计划，安
全架构，安全分析文档，安全设计文档，安全维护文档等等。
（7）攻击树（Attack Tree）：攻击树模型采用树结构（如图 9 所示）攻击一个系统，其
目标在根节点，叶子节点就是不同的攻击方式。此模型可用于软件开发的需求分析和设计阶
段。
实现远程访问
实行缓冲区溢出攻击 猜测密码
图 9 一个攻击树实例
11
（8）威胁建模（Threat Modeling）[20]
威胁建模主要用于设计阶段，目的是明白软件面临的威胁和对手可能使用的攻方式。威
胁建模由以下活动组成：
<1>分解应用程序，确定过程范围。使用 DFD（数据流图）或者 UML（统一建模语言）
描述威胁模型，作为分析应用程序的重要组成部分。对应用程序进行形式化分解，自顶向下，
逐层细化，在分解过程中关注过程之间的数据流。
<2>确定系统面临的威胁，可通过在 STRIDE 分类（身份欺骗，篡改数据，否认，信息
泄露，服务拒绝，权限提升）基础上的集体讨论，DFDs 和/或通过使用威胁树来获取。威
胁树与攻击树类似，但是对确定的威胁增加了缓和条件（如图 10 所示）。
远程攻击成功
图 10 一个威胁树实例
<3>解决威胁
<4>跟进，检测假设和安全需求，跟踪变化。
（9）滥用和误用用例
误用用例，由 Sindre 和 Opdahl[21]提出的，是系统中不希望行为的用例，它扩展了一般
的用例。一般用例可以缓和误用用例，即一般用例可以是误用用例的对策；误用用例能威胁
一个用例，即一个用例可以被一个误用用例利用和阻碍。图 11 展示了一个误用用例图，这
里安全用例“加密敏感信息”是为了防止对手窃取敏感信息的威胁。这个威胁就代表误用用
例“窃取敏感信息”。
攻击者猜测密码攻击者进行缓冲
区溢出攻击
and
系统对缓冲区溢
出敏感
攻击者有一定的
技术水平
12
图 11 误用用例图
与误用用例相关的是 McDermott 和 Fox[22]提出的滥用用例（Abuse Case），是指软件开
发人员需要在正常特性之外思考软件系统的固有特性，如可靠性、安全和性能。需要对系统
的异常行为在事先有所预期，像攻击者一样思考你的系统，即利用“反需求”查找出错点。
例如：系统有一个使用加密保护通过序列化将关键数据写到磁盘上的安全需求，与这个需求
对应的“反需求”就是要确定当缺少加密的时候会发什么情况。通过使用标准的 UML 用例
标记法表述威胁。滥用用例被保存在一个独立的模型中。
漏洞与设计和实现阶段的活动
漏洞分析数据库最主要的素材就是漏洞，它是其它一切活动基础，在使用此模型之前一
定要先将一定数量的漏洞存储在 VAD 中。目前人们对漏洞的认识已经越来越深，下面列出
23 项普通漏洞。然后，对这些漏洞在设计和实现阶段产生的原因进行评估。最后给出避免
和缓解这些漏洞的对策。
普通漏洞：（V1）缓冲区溢出；（V2）整型出界；（V3）命令注入；（V4）SQL 注入；（V5）
跨站点脚本攻击；（V6）字符串格式错误；（V7）指针值不合法；（V8）日志伪造；（V9）路
径遍历；（V10）字符串终止错误；（V11）未发布的资源；（V12）无效的返回值；（V13）竞
争状态（Race condition）；（V14）不合适的错误处理；（V15）违背最少权限；（V16）不安
全的临时文件；（V17）双重释放；（V18）未初始化的变量；（V19）使用已被释放的指针；
（V20）弱加密算法；（V21）引用不可信的移动代码；（V22）参数丢失；（V23）信息泄露。
[8][10][16]
为了便于理解，在此举例将漏洞映射到上面提到的设计和实现的活动上。这个映射可帮
助我们容易地发现减轻具体漏洞的活动。表 3 中的列代表了活动（DA1~DA13 指上文中设
计阶段的 13 项活动，而 IA1~IA19 指上文中实现阶段的 19 项活动），而行代表了漏洞。如
果任何活动可以减轻一个漏洞，那么交叉的那个格打勾。一个活动可以映射到多个漏洞。表
3 显示在设计阶段作重要的安全措施是选择合适的编程语言和在资源访问控制方面保持最
小权限原则。C#和 Java 的漏洞较少。在实现活动中重要的活动有安全代码复查，输入验证，
安全库函数的使用。
对手 缓和
威胁
存储敏感信息
用户
窃取敏感信息
加密敏感信息
13
表 3 设计和实现阶段的活动与漏洞的映射表
V
1
V
2
V
3
V
4
V
5
V
6
V
7
V
8
V
9
V
1
0
V
1
1
V
1
2
V
1
3
V
1
4
V
1
5
V
1
6
V
1
7
V
1
8
V
1
9
V
2
0
V
2
1
V
2
2
V
2
3
S
U
M
1 √ √ √ √ √ √ √ √ √ √ √ √ √
1
3
2 √ √ √ √ √ √ √ 7
3 √ √ 2
4 √ √ 2
5 √ 1
6 √ √ 2
7 √ 1
8 √ 1
9 √ 1
1
0
√ √ 2
1
1
√ 1
1
2
√ √ 2
设
计
活
动
D
A
1
3
√ √ √ √ 4
1 √ √ √ √ √ 5
2 √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √
1
8
3 √ √ √ √ √ √ √ √ 8
4 √ √ 2
5 √ 1
6 √ 1
7 √ √ 2
8 √ 1
9 √ √ 2
1
0
√ √ √ √ √ √ 6
1
1
√ √ √ √ 4
1
2
√ 1
实
现
活
动
I
A
1
3
√ √ 2
14
1
4
√ √ √ 3
1
5
√ √ 2
1
6
√ 1
1
7
√ √ √ 3
1
8
√ 1
1
9
√ √ 2
4． 结束语
本文提出了一个安全过程模型——OVSP 模型，此模型最大的优点是安全知识都存储在
VAD 中，处于各个软件开发阶段的人员都可以根据需要从 VAD 中可视化查询共享的安全信
息，有助于安全漏洞的缓解和移出。另外相关人员新发现的漏洞也可以存储到 VAD，VAD
可以根据自动对漏洞进行分类，生成 VCG 和 SAG 等。由于本模型处于刚提出的阶段，只
提供了一个框架，有很多细节问题没有解决，比如说 VAD 的结构，攻击树和威胁建模的实
现等等，希望对安全过程感兴趣的人提供宝贵意见，并继续研究。
参考文献
[1] Kanta Jiwnani，Marvin Zelkowitz. Maintaining Software With a Security Perspective[J]. Proceeding of the
International Conference on Software Maintenance (ICSM’02).
[2] Gary McGraw Cigital. Software Security[J] . IEEE Computer Society, 2004.
[3] Jon Heffley and Pascal Meunier. Can Source Code Auditing Software Identify Common Vulnerabilities and
Be Used to Evaluate Software Security? [J] Proceedings of the 37th Hawaii International Conference on System
Sciences 2004.
[4] Bruce Potter，Gary McGraw. Software Securty Testing[J]. IEEE Security & Privarcy 2004.
[5] Sean Barnum,Gary McGraw. Knowledge for Software Security[J]. IEEE Security & Privarcy 2005.
[6] Nancy R. Mead, Gary McGraw. A Portal for Software Security[J]. Published By The IEEE COMPUTER
SOCIETY, IEEE Security & Privarcy, 2005.
[7] Bengt Carlsson,Dejan Baca. Software Security Analysis-Execution Phase Audi[J]. Proceeding of the 2005 31st
EUROMICRO Conference on Software Engineering and Adwanced Applications(EUROMICRO-SEAA’05).
[8] Katrina Tsipenyuk, Brian Chess, Gary McGraw.. Kingdoms:A Laxonomy of Software Security Errors[J].
IEEE Security & Privarcy 2005.
[9] Martin , Sheila . Dynamic Software Security Testing[J]. IEEE Security & Privarcy 2006.
[10] Anil Bazaz,James . Towards A Taxonomy of Vulnerabilities[J]. Proceedings of the 40th Annual
Hawaii Internatinal Conference on System Sciences(HICSS’07).
15
[11] Dorina Ghindici, Gilles Grimaud, Yanguo Liu, Issa Traore. Integrated Security Verification and
Validation:Case Study[J]. IEEE 2006.
[12] Jeff Zadeh, Dennis De Volder. Software Development and Related Security Issues[J]. IEEE 2007.
[13] David Byers, Nahid Shahmehri. Design of a Process for Software Security[J]. Second International
Conference on Availability,Reliability and Security(ARES’07).
[14] Shanai Ardi, David Byers, Per Hakon Meland, Inger Anne, Tondel, Nahid Shahmehri, How can the developer
benefit from security modeling? [J]. Second International Conference on Availability,Reliability and
Security(ARES’07).
[15] Shanai Ardi, Nahid Shahmehri. Integrating a Security Plug-in with OpenUP/Basic Development Development
Process[J]. IEEE2008.
[16] , , , . Software Security:A Vulnerability-Activity Revisit[J].
The Third International Conference on Availability,Reliability and Security 2008.
[17] John Wilander , Jens Gustavsson. Security Requirements – A Field Study of Current Practice[J].
Symposium on Requirements Engineering for Information Security (SREIS’05), In conjunction with RE 05-13th
IEEE International Requirements Engineering Conference, Paris,France,2005.
[18] S. Ardi , and . Towards a Structured Unified Process for Software Security. [J] In
Proceedings of the ICSE 2006 Workshop on Software Engineering for Secure Software(SESS06), Shanghai, China,
2006.
[19] A. Borg , M. Patel , K. Sandahl. Extending the OpenUP/Basic Requrements Discipline to Specify Capacity
Requrements[J]. In Proceedings of the 15th IEEE International Requrements Engineering Conference (RE’07),
Delhi, India, 2007.
[20] . Demystifying the threat-modeling process[J]. IEEE Security & Privacy,3(5):66-70, 2005.
[21] G. Sindre and L. Opdahl. Eliciting Security Requirements With Misuse cases[J]. Requirements Engineering,
10(1):34-44,2005.
[22] J. McDermott and C. Fox . Using Abuse Case Models for Security Requirements Analysis[J]. In ACSAC’99:
Proceedings of the 15th Annual Computer Security Applications Conference, Page 55, Washington, DC, USA,
Computer Society.
16
Research and design on software security assurance process
YANG Kai
（School of computer science and technology
Beijing University of Posts & Telecommunications, Beijing 100876, China）
Abstract
More and more people concern the problem of software security. Today , the research in this field
almost focus on test and maintenance phases in software lifecycle. The necessity of software security
consideration among the whole software lifecycle is discussed, the major domestic and foreign models
of software security development process are investigated, a process of software security assurance is
presented. In the conclusion, the present study is summarized and future directions of software security
process are pointed out.
Key words: software security; security vulnerability; software lifecycle; software security assurance
process; modeling
17
1．引 言
2．研究现状
SDLC最佳实践加强版本
基于SPI的安全过程模型
基于OpenUP/Basic开发过程的S3P模型
3．面向VAD的安全过程模型
各阶段活动描述
漏洞与设计和实现阶段的活动
4． 结束语
