作者：宋明秋
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
软件安全开发——属性驱动模式试读：
作者简介
宋明秋工学博士，CISSP、CISA，大连理工大学管理与经济学部副教授，英国牛津大学Internet研究所访问学者，主要研究方向：软件安全开发，信息安全风险管理。
其他
Breaking something is easier than designing something that cannot be broken.——McGraw
发现漏洞是重要的，更重要的是了解漏洞产生的原因，以及如何控制和消除它们的影响。——张建军
本书的章节设置
第1章 描述了软件安全的基本概念。对软件安全的基本属性进行了深入细致的刻画，分析了软件安全实现的基本方法，并对属性驱动的软件安全开发方法基本思想进行了阐述。
第2章将安全嵌入软件开发的整个生命周期。对于软件安全开发方法的历史演化过程进行了总结，对于几种典型的软件安全开发方法进行了较为详细的阐述，比较分析了每种方法的特点以及发展的趋势，并由此提出属性驱动的软件安全开发的基本方法和过程。
第3章 软件安全需求分析。应用需求工程的理论与方法，分析了软件安全需求定义，提出软件安全需求的内容、来源与分类方法，重点阐述了如何获取、评价安全需求，以及如何对安全需求进行追踪测试等方法。
第4章 软件安全保障设计。采用领域驱动的设计思想，阐述了软件安全的架构设计和选择的方法，提出将安全属性转换为安全功能的设计方法，并给出了软件设计安全性的检查方法。
第5章 软件安全编码。阐述软件编码过程中存在的各种安全问题、可能采取的控制和编码防御措施，以及具体编码中的安全实践指南。
第6章 软件安全测试。紧密围绕软件安全属性需求，采用传统的可重用的测试方法，提出属性驱动的软件安全功能测试方法；阐述了安全漏洞测试的内容和方法；并对于与安全紧密相关的其他属性，如性能、可扩展性、隐私性等方面的测试进行了较为详细的讨论；最后阐述了软件测试的过程模型，使软件安全测试更加系统。
序言
当前随着社会经济的发展和科学技术的进步，计算机的应用日益广泛，人们不但直接使用了从微型计算机、平板电脑、智能手机直到超级计算机的不同信息与计算工具，而且在生产装备、运输工具甚至家庭生活用具中也嵌入了各式各样的计算装置。互联网的日益普及主要得益于计算机的应用，在现代生活和工作中人们享受着计算机带来的巨大效益和便利，与此同时对计算机安全工作的依赖性也日益增加。计算机在安全方面的问题不但会影响到生产和生活的正常运行，有时候甚至造成人身伤亡、装备损毁等重大事故，因此近年来人们对日益严重的计算机系统的安全问题开始密切重视。
在计算机系统的硬件和软件两个方面，人们历来重视的是硬件方面的安全性和可靠性，而对比较隐蔽的软件安全性却关注得不够。但是许多安全事故却是出在软件方面，发生在20世纪90年代的Ariane 5运载火箭、SOHO太空飞船等五起航天器事故的罪魁祸首就是软件，而通过软件安全事件每年给全球造成的经济损失已经高达4500亿美元。因此近年来人们开始以很大的注意力关注软件的安全性问题，因为这不仅影响到个人或者企业自身，而且已经上升到国家安全的高度。
软件的安全性可以理解为软件在系统中运行不至于在工作中造成不可接受的风险（如人身伤亡、设备损坏、财产重大损失、严重污染环境等）的能力。为构建这种能力，人们采取了一系列的方法和技术，逐步形成了计算机软件安全的理论。
为了提高软件的安全性，在软件的开发过程中就应该对安全问题加以认真考虑，由此近年来逐步形成了软件安全开发的概念和方法。由于这是一个新的领域，有关的方法和技术还局限于某些具体应用，尚缺少比较系统介绍的著作，本书正是为了填补这一空白而撰写的。
本书作者在书中一开始先介绍了软件安全的基本概念，对软件安全的基本属性进行了深入细致的描绘，分析了软件安全实现的基本方法，对属性驱动的软件安全开发方法的基本思想进行了阐述。然后利用系统工程思想将安全属性嵌入软件开发的整个生命周期。在回顾软件开发方法的演化过程和对各种方法进行对比的基础上，提出了属性驱动的软件安全开发的基本方法和过程。在总揽全局的基础上，依次详尽地探讨了软件安全需求分析、软件安全保障设计、软件安全编码、软件安全性测试问题。全书贯穿了系统工程整体性和有序性的理念和方法而又不失对技术细节的阐述，形成了本书的特点。
由于软件安全开发方法涉及的学科比较多，涵盖了多方面的技术细节，因此建立系统的开发理论和方法体系是一项艰苦的工作。深切希望本书作者能在这本著作的基础上进一步深入探索，以满足日益增长的软件安全开发的要求。
大连理工大学系统工程研究所
2015年12月第1章理解软件安全开发1.1 信息安全面临的困境
随着互联网技术的快速发展，网络应用（包括社交网络、即时通信、电子邮件、门户网站、网络游戏、手机游戏、电子商务、智慧城市）迅速普及，各种新型网络接入技术（移动网络、云计算、物联网）与传统互联网相融合，为人们提供了更加方便快捷的信息服务，然而同时也带来了日益严重的安全问题。黑客攻击、恶意代码、信息泄露、拒绝服务、权限提升等安全事件层出不穷，每年给全球经济造成的损失超过4500亿美元。更有甚者，2013年“棱镜”事件敲响了国家安全的警钟，信息安全不再只是企业自身的问题，而已经上升到了国家安全的层面。
调查数据显示，企业的信息安全预算中主要的投资方向仍集中于传统的防病毒、防火墙、VPN及身份认证等方法，这些以网络边界安全防护为主的传统安全解决方案可以减少漏洞被利用的机会，然而却不能有效减少系统本身漏洞的存在，仍属于检测型或补偿型控制的被动防护方法。尽管如微软等核心软件公司能够定期发布安全补丁，较为及时地对操作系统、数据库等核心软件的漏洞进行修复，但对于一些零日攻击系统几乎没有防范能力；加之大多数的应用软件开发人员没有能力及时地对应用软件漏洞进行修复，使得系统的运行处于一种危机四伏的状态。传统的安全控制效果不尽如人意，信息安全问题越来越多，攻击形势越来越隐蔽（如APT攻击），智能程度越来越高（技术水平越来越高），组织方式多样化（由最初的单个人员入侵发展到利益驱动的有组织、有计划的产业行为），危害程度日益严重。
分析这一现象产生的根本原因是软件产品本身存在安全漏洞，这些漏洞不止发生在操作系统、数据库或者Web浏览器，也发生在各种应用程序中，特别是与关键业务相关的应用程序系统中。据统计，有超过70%的漏洞来自于应用程序软件，而当前最为热点的移动互联网 App 存在安全漏洞的比例高达 90%以上。众所周知，系统安全漏洞可以为 Internet远程访问、进行系统穿透、实现系统破坏大开方便之门。目前通行的系统开发后期进行测试以消除编码中Bug的方式，对于减少软件产品的漏洞数量具有一定的作用，但该方法是以企业为软件开发人员不断犯同样的错误而支付相当的开发成本为代价的，并且一些系统设计逻辑上的缺陷在测试阶段是无法发现的，这些漏洞会增加后期系统维护的成本，并给用户带来巨大的潜在风险。
软件产品存在大量的漏洞是当前信息安全领域面临的最大困境。由于漏洞的产生、利用以及相互作用的机理复杂，因此，如何有效减少系统漏洞数量，提高信息系统整体安全性成为当前亟待解决的挑战性问题。1.2 软件安全基本概念
我们从软件的基本定义出发，根据需求产生技术的基本原则，从软件错误的类型以及产生的原因分析，提出软件安全属性的概念，并对每一种属性进行描述，根据各属性的原子特性将它们划分为核心安全属性与非核心安全属性。这些安全属性将是软件开发整个生命周期安全保障的基础和目标。1.2.1 软件的定义
IEEE 给出的软件的定义是计算机程序、方法、规则和相关文档资料，以及在计算机上运行时所需的数据。软件并不只是包括可以在计算机上运行的电脑程序，与这些电脑程序相关的文档一般也被认为是软件的一部分。简单地说，软件就是程序、数据加文档的集合体。
与软件的定义紧密相关的是信息系统的概念，这是一个更加复杂的体系。GB/T 20438.4—2006对系统（System）的定义是根据设计相互作用的一组元素，可能包括相互作用的硬件、软件和人等。本书只关注软件的安全开发问题，对于硬件及人员的问题暂不涉及。1.2.2 软件安全错误“错误”一词在软件安全文献中很少使用，大部分人都习惯于用“漏洞”或者“脆弱点”，有时候软件缺陷也指代错误。
软件安全错误是软件开发生命周期各阶段中错误的真实体现，这些错误会导致软件的漏洞或者脆弱点。
如果与开发过程相关联的话，软件安全错误可以包含下面几种情况：（1）需求说明错误。由于软件开发生命周期需求分析过程的错误而产生的需求不正确或缺失的需求，如缺少用户输入验证，这会导致数据格式错误或缓冲区溢出漏洞。（2）设计错误。由于设计阶段引入不正确的逻辑决策、决策本身错误或者由于决策表达错误而导致的系统设计上的错误，如不正确的口令恢复程序。（3）代码编写错误。由于软件生命周期实施阶段的错误而导致的设计决策的不正确表达。（4）配置错误。由于软件在应用环境中配置不当而产生的错误，如防火墙采用默认口令。
软件安全错误是软件错误的一个子集，两者之间唯一的差别是软件安全错误导致漏洞或脆弱点，而软件错误可能会产生与安全无关的不期望的行为。
对于软件安全错误的解决方法基本有两种途径：
第一种途径是采用各种检测、分析、挖掘技术对安全错误进行发现、分析、评价，然后采取各种安全控制措施进行错误修复和风险控制，如传统的打补丁、防病毒、防火墙、入侵检测、应急响应等。这种方法是将安全保障措施开始于软件发布运行之时，是当前系统安全保障普遍采用的方法。历史经验证明，该方法在时间和经济上投入产出比较低，信息系统的安全状况没有得到有效改善。
第二种途径是分析软件安全错误发生的原因，将安全错误的修正考虑嵌入到软件开发生命周期的早期阶段。通过对需求分析、设计、实现、测试、发布，以及运维等各阶段相关的软件安全错误的分析与控制，以期大大减少软件产品的漏洞数量，使软件产品的安全性得到有效提高。该方法是将安全保障的实施开始于软件发布之前，尤其强调从软件生命周期的早期阶段开始安全考虑，从而减少软件生命周期的后期系统运行过程中安全运维的工作量，提高安全保障效果。研究结果表明，在系统维护阶段才考虑安全问题比从系统开发需求阶段就引入安全要素，所花费的错误修复成本要高30～100倍。1.2.3 软件安全的定义
在传统领域，安全的定义是“使伤害或者损害的风险控制在可接受的水平内”（ISO8402）。在软件工程国际标准ISO/IEC15026及国家标准GB/T 18492—2001中对于安全性的定义是“系统在规定的条件下不导致危害人类生命、健康、财产和环境的一个状态的期望值”。
在此基础之上，软件安全的主要研究人员McGraw在他早期的文献[1]中将软件的安全性定义为“在面临蓄意威胁其可靠性的事件的情形下依然能够提供所需功能的能力”，这是一种广义的对于软件应用安全状态的理解。而在我国国家标准 GB/T 16260.1—2006/ISO/IEC9126-1:2001 中，软件的安全性被定义为“软件产品保护信息和数据的能力，以使未授权人员或系统不能阅读或修改这些信息和数据，而不拒绝授权人员或系统对它们的访问”。这一标准定义包含了保密性、完整性、可用性三个方面的安全特性，体现了软件安全与数据保护的密切关系。
尽管“软件安全”本身是一个系统性问题，但软件安全仅仅与软件内部的失效有关，与硬件、人为操作等因素无关。也就是说，作为系统重要组成要素的软件，本身不直接涉及系统中硬件的物理安全问题，也不涉及软件人机接口实现而可能带来的因为软件安全失效或者人员误操作而产生危险的问题，以及对系统中相关操作人员的管理问题。软件安全只是软件在系统上下文环境中对系统安全性贡献的速记
[2]形式。
安全性是软件质量的一个重要属性，描述了软件在系统工作中避免不可接受风险的能力，以及系统正常运行而不会引起事故的能力。软件在系统运行、危险控制以及关键安全功能实现等方面正发挥着越来越重要的作用，成为系统安全保障、避免重大人员伤亡和财产损失的一个重要环节。
现有的关于软件安全性问题的方法和技术主要包含软件安全属性认知、软件安全测试、软件安全评估、信息系统安全工程以及软件安全开发几个方面。（1）软件安全属性的认知。安全是整体性的概念。根据国家标准 GB/T 16260.1—2006/ISO/IEC9126-1:2001，软件安全既离不开它所存储、传输、处理的数据的安全，也离不开相关文档的安全，因此软件安全应涵盖数据及其信息处理过程本身的三个基本安全要素：保密性、完整性和可用性；同时软件需要接收外界信息输入才能实现预期的功能产生输出结果，信息来源的安全性必然成为软件安全重要的组成部分。基于这些分析，我们将保密性、完整性、可用性、认证性、授权、可记账性作为软件安全的核心属性；而软件自身的实现质量，即软件产品包含的漏洞情况也应该是软件安全性的主要内容，因为这些漏洞会直接导致安全性问题，这也是传统的软件安全关注的问题；此外，站在不同的管理者视角，抗抵赖性、审计性、可信性、可控性、可靠性、软件弹性等也成为软件被关注的其他安全属性。（2）软件安全测试用来验证与软件相关的系统风险已被消除，或者被控制在可接受的风险水平，并通过测试在软件中发现和排除隐蔽的重大错误及漏洞。（3）软件安全性评估是为度量软件产品的安全性和系统保障措施而提供的一种客观可信的方法，帮助消费者确定软件产品和相应的保障措施的可信级别。（4）系统安全工程是一项复杂的系统工程，需要运用系统工程的思想和方法，系统地分析信息系统存在的安全漏洞、风险、事件、损失、控制方法以及效果之间复杂的对应关系，对信息系统的安全性进行分析与评价，以期建立一个有效的安全防御体系，而不是简单的安全产品堆砌。
确切地说，系统安全工程是系统的安全性问题而不仅是软件产品的安全性问题，是一种普适性的信息系统安全工程理论与实践方法，可以用于构建各种系统安全防御体系。系统安全工程可以在系统生命周期的不同阶段对安全问题提供指导，例如，对于已经发布运行的软件，可以采用系统测试、风险评估与控制等方法构建安全防御体系；而对于尚待开发的系统，也可以应用系统安全工程的思想方法来提高目标系统的安全性。这是一项具有挑战性的工作，也是本书的出发点。（5）软件安全开发关注的是如何运用系统安全工程的思想，以软件的安全性为核心，将安全要素嵌入软件开发生命周期的全过程，有效减少软件产品潜在的漏洞数量，提高软件产品的本质安全性。与传统的信息安全工程最大的差别就在于，它将安全问题的考虑提前到了软件生命周期的早期。微软SDL实践证明，从需求分析阶段开始就考虑安全问题，可以大大减少软件产品漏洞的数量，而不会增加成本。
这里“本质安全”是指 “通过设计等手段使生产设备或生产系统本身具有安全性，即使在误操作或发生故障的情况下也不会造成事故的功能。具体包括失误—安全功能（误操作不会导致事故发生或自动阻止误操作），以及故障—安全功能（设备、工艺发生故障时还能暂时正常工作或自动转变为安全状态）”（GB 3836.18—2010）。
对于软件安全性的测试和评估主要基于产品的视角，描述产品是什么，它的安全性怎么样；而系统安全工程与软件安全开发是基于过程的视角，回答软件的安全性是如何构建的，软件安全开发是系统安全工程应用的最高阶段，也是解决信息安全问题的最根本途径。1.3 软件安全属性刻画
本小节从软件安全属性的认知出发，对软件安全相关的属性进行定义和描述，包括核心安全属性，即保密性、完整性、可用性、认证性、授权、可记账性/审计性，以及抗抵赖性、可控性、可信性、隐私性等其他相关安全属性。1.3.1 保密性
ISO/IEC9126 质量模型将保密性（Confidentiality）定义为与防止对程序和数据进行非法存取的预防能力有关的质量属性。该定义描述了软件对信息和数据的安全保护能力，主要关注的是权限和密码。ISO/IEC15026及GB/T 18492—2001 对于保密性的描述为对系统各项的保护，使其免于受到偶然的或恶意的访问、使用、更改、破坏及泄露。信息技术安全管理指南（ISO13335）中保密性定义是确保信息不被非授权的个人、实体或者过程获得和访问。
保密性是为了保证敏感和私有信息不被未授权人访问，在使用计算机处理敏感信息时，如存储、传输和处理，对未授权人设置一定的限制机制，同时又保证授权人在允许的权限范围内自由访问。1.3.2 完整性
完整性（Integrity）指在传输、存储信息或数据的过程中，确保信息或数据不被未授权的人员篡改或在篡改后能够被迅速发现。ISO13335中完整性包括数据完整性的内涵，即保证数据不被非法地修改和销毁；同样还包括系统完整性的内涵，即保证系统以无害的方式
按照预定的功能运行，不被有意的或者意外的非法操作所破坏。
ISO/IEC15026对于软件完整性进行了分级描述，提出“软件完整性级别表示软件特性的取值范围，该范围将系统风险保持在可容忍的限度内。对于执行缓解功能的软件而言，此特性是指软件必须执行缓解功能的可靠性；对于因其失效而导致一个系统威胁的软件而言，此特性是指对失效的频率和概率的限制。”
GB/T 18492—2001《信息技术 系统及软件完整性级别》提出软件完整性需求是软件开发中软件工程过程必须满足的需求，是软件工程产品所必需满足的需求，或是为提供与软件完整性级别相适应的软件置信度而对软件在某一时段的性能的需求。
综上，我们将软件完整性定义为软件产品能够按照预期的功能运行，不受任何有意的或者无意的非法错误所破坏的软件安全属性。1.3.3 可用性
可用性（Availability）是指被授权实体访问并按需求使用的特性，即当需要时能存取所需的信息，而未授权的用户则无法获取信息或资源。拒绝服务攻击就是对软件可用性的破坏的一个实例。
ISO9241/11中对可用性的定义是：一个产品被指定用户使用，在一个指定使用情景中，有效地、有效率地、满意地达到指定目标的程度。其中，有效是指用户达到指定目标的精确性和完全性，效率是指用户精确完全地达到目标所消耗的资源，满意度是指使用舒适和可接受程度。
GB/T 3187—1997 对可用性的定义是在要求的外部资源得到保证的前提下，产品在规定的条件下和规定的时间区间内处于可执行规定功能状态的能力。它是产品可靠性、维修性和维修保障性的综合反映。
可用性是一个多因素概念，涉及易用性（容易学习、容易使用）、系统的有效性、用户满意度，以及把这些因素与实际使用环境联系在一起针对特定目标的评价。可用性描述了一个产品在何种程度上能帮助特定的用户在特定的上下文环境中有效地和有效率地实现所定义的目标，包括运营、服务和维护。可用性不仅指人机交互系统中以人为本的设计流程，也包括人因工效学、软件的易用性及可用性的相关技术支持。
在上述可用性特征中，站在安全的角度，可用性被定义为保证授权实体在需要时可以正常地访问和使用系统信息的属性（安全管理指南ISO13335）。
可用性是系统可靠性和可维护性的一个重要指标，可以表示为系统保持正常运行时间的百分比，即MTTF/(MTTF+MTTR) * 100%，它描述了设备或系统处于完好状态的概率。其中，平均无故障时间（MTTF）描述了系统平均能够正常运行多长时间，才发生一次故障；平均维修时间（MTTR）描述的是系统发生故障后维修和重新恢复到正常运行状态平均需要花费的时间。MTTF是系统的可靠性度量指标，系统的可靠性越高，平均无故障时间越长；而MTTR是系统的可维护性度量指标，平均维修时间越短，可维护性越好。1.3.4 认证性
认证（Authentication）是一种信用保证形式。ISO13335中对信息安全认证性的定义是确认和识别一个主体或资源就是其所声称的身份，被认证的主体可以是用户、进程、系统和信息等。
软件是访问内部网络、系统与数据库的渠道，因此对于内部敏感信息的访问必须得到批准。认证就是解决这一问题的信息安全概念，它通过验证身份信息来保证访问主体与所声称的身份唯一对应。
只有在申请认证的身份信息是可识别的情况下认证才能成功，所提供的凭证信息必须是真实可信的。凭证最普通的格式是用户名和口令的组合，认证可以依据下面一种或几种因素的组合来实现：
•所拥有的知识：在这种机制下提供的用于验证的身份信息是你所知道的知识，如用户名和口令、通行短语或者个人识别码PIN（Personal Identification Number）。
•所有权：用于验证的身份信息是你自己特有的或者所拥有的，通常指硬件，如令牌和智能卡。
•生物特征：在这种机制下，用于验证的身份信息如生物特征，以此来证明你是谁。基于生物特征的身份信息是典型的对于物理特征的数字化描述，虹膜、指纹、视网膜都是生物特征的典型例子。生物特征是有局限性的，因为随着时间的推移这些生物特征会发生变化，可能是自然的，也可能是人为的。一些可以数字化的物理动作如签字（压力和倾斜度）也可以作为基于特征认证的身份识别信息。
采用以上两种或两种以上的认证方法要比只采用一种认证方法安全性更高，这被称为多因素认证。当对包含敏感和重要的信息进行访问认证时，推荐使用多因素认证。例如对于金融系统的访问，只有在环境条件不足或者补偿措施充分的情况下才能使用单因素认证。1.3.5 授权
授权（Authorization）是指在访问主体与访问对象之间介入的一[3]种安全机制。根据访问主体的身份和职能为其分配一定的权限，访问主体只能在权限范围内合法访问。
可验证的实体身份证明并不意味着该实体可以被授予访问请求的资源的所有访问权限。例如，普通员工能够登录公司账户，但是不能够访问人力资源的工资数据，因为没有相应的权限或优先权。
对于系统或者数据的访问是受到被认证的实体的权限或优先权控制的一个安全概念，而访问权限和优先权的授权决策是根据安全政策，由数据和系统的所有者来决定的。授权决策在认证之上，但决不会先于认证。访问的请求者是主体，可以是一个人或者一个进程，访问的目标作为访问对象，如数据库、文件或视图。主体的动作权限通常包括产生（Creation）、读（Reading）、更新（Update）或删除（Deletion），可记为CRUD。不同优先级的用户将拥有不同的权限。比如一个普通用户只能“读”，而管理员可以有“产生”、“读”、“更新”数据的权限。1.3.6 可记账性/审计性
在ISO13335中，可记账性（Accountability）确保一个实体的访问动作可以唯一地被区别、跟踪和记录。可记账性是通过审计日志来实现的。可记账性是指具有优先级和关键的业务交易被记录下来的一个安全概念；而日志是用来建立事件的历史记录，实现可记账性的一种技术手段，可用于故障排除和取证。
审计（Audit）是指根据公认的标准和指导规范，对软件从计划、研发、实施到运行维护各个环节进行审查评价，对软件及其业务应用的完整性、效能、效率、安全性进行监测、评估和控制的过程，以确认预定的业务目标得以实现，并提出一系列改进建议的管理活动。
审计是一个检测性的安全控制机制，审计阈包括谁（用户和进程）做了什么（CRUD），在哪里（文件或表），什么时间（产生或被修正的时间戳），以及业务定义的优先级和重要的交易事件前后的信息修改快照，这些信息都需要记录下来。此外，新的审计日志总是附加在旧的日志之上且永远不能被覆盖。由于日志保留期限的不同会出现存储容量和空间问题，保留期限要根据规则需求和组织政策来制定，以免规则需求和组织保留政策相矛盾。规则需求必须被遵守，而组织政策也需要适当地被修改，以避免未来可能出现的矛盾冲突。
如果没有适当的相关性和模式识别能力，关键性与管理性的操作将会被漏掉，由此反而会降低审计提供的安全保证能力。
审计也是一种威慑控制措施，因为审计日志可以用于确定用户或软件代理的动作历史。同时，基于日志的审计也是一种被动的检测控制措施，对于审计的预知可以潜在地威慑用户不执行未授权的动作，但不能完全阻止他们那么做。
可记账性与审计性是两个紧密关联的属性，可记账性是审计的基础，为审计取证提供依据；审计是对可记账信息实施检查监督，发现风险的方法。1.3.7 抗抵赖性
抗抵赖性是指软件防止用户否认执行了某些行为的功能，它保证了可记账性不会被推翻或者绕过。
抗抵赖性解决的是用户或者软件代理对于已有动作的否认问题。例如，当价格发生变化时，如果软件能够记录假冒的动作变化以及施加动作的用户身份，就可以给个人一个否定或者拒绝动作的机会，由此保证抗抵赖性的实现。
可记账性与审计相结合，可以有效地实现抗抵赖性。1.3.8 可控性
可控性反映的是信息系统不会被非授权使用，信息的流动可以被[4]选择性阻断的属性。
信息安全的可控性主要是指对于信息安全风险的控制能力，即在一定条件下，通过一系列措施，对信息系统安全风险进行事前识别、预测，并通过一定的手段来防范、化解风险，以减少遭受损失的可能性。
可控性是一种系统性的风险控制概念，具有对于分布式软件系统层次性的控制能力。通过提供集中地、自动地对网络设备、应用和用户接入的控制能力，例如实现网络配置、定位服务、基于角色的策略制定的自动化，完成对威胁的检测、定位及网络配置的自动响应等功能。可控性保证对网络安全进行全局监控，对影响网络性能的行为自动做出快速反应，并减少这些行为造成的损失。1.3.9 可信性
可信性是信息安全领域较为经典的一个概念。早在1985年，美国国家计算机安全中心NCSC（National Computer Security Center）倡议的可信计算机系统评价准则中就将软件可信性定位在安全性这个[5]唯一的质量属性上，指出可信性是属于软件产品质量的一个属性。TSM（可信软件方法学）项目对于软件可信性的定义为“软件满足既定需求的信心度”，阐述了可信性对管理决策、技术决策，以及既定[6]需求集合的高度依赖性。而文献[7]则把软件可信性定义为为降低错误率的软件工程技术（如加强测试、评审、检查等）的适用程度。其他的一些研究者对可信性所包含的属性也有不同的见解，其中，大部分的研究者认为可信性应包括可用性（Availability）、可靠性（Reliability）、传统物理安全性（Safety）、信息安全性（Security，包括保密性和完整性），以及可维护性（Maintainability）等属性。由此可见，可信性是一个综合性很强的安全性度量指标。1.4 信息产品的安全性评估标准
信息安全评估是指评估机构依据信息安全评估标准，采用一定的方法或方案对信息安全产品或系统的安全性进行评价。国际最早的信息产品安全评估标准是TCSEC（Trusted Computer System Evaluation Criteria），在此基础之上的ITSEC（Information Technology Security Evaluation Criteria），以及发展到现在广泛使用的CC（Common Criteria）标准。
TCSEC是1983年8月由NCSC 首先推出的计算机系统安全评估准则（CSC-STD-001-83），这套标准的文献名称是可信计算机系统评价准则，也称为橘皮书。1985年美国国防部DOD（Department of Defense）正式采用该标准，并进行了修改和完善，作为美国国防部的标准。TCSEC作为一种信息产品验收度量标准，为制造商提供一个安全评估准则，更关注高安全等级信息的机密性和安全可控性，为产品的检查与评价提供依据。
ITESC是1991年由法、英、荷、德欧洲四国联合发布的信息技术安全评估标准，被称为欧洲白皮书。它提出了信息安全的机密性、完整性、可用性的安全属性，与TCSEC相比，ITESC面向商业领域，强调了信息安全的完整性。
加拿大也在1993年提出了可信计算机安全评估标准 CTCPEC（Canadian Trusted Computer Product Evaluation Criteria）。
美国在TCSEC的基础之上，又增加了“保护轮廓PP”（Protection Profile）的概念，每个轮廓都包括功能、开发保证和评价三部分，并提出TCSEC的升级版联邦标准FC（Federal Criteria）。FC充分吸取了TCSEC和CTCPEC的优点，在美国的政府、民间和商业领域得到了广泛应用。
由于信息互联互通的需要，美、加、英、法、德、荷六个国家于1996年联合提出信息技术安全评价的通用标准 CC，并逐渐形成国际标准 ISO15408。该标准定义了评价信息技术产品和系统安全性的基本准则，是目前国际上公认的表述信息技术安全性的结构，描述了信息技术安全性的结构、安全组件包、保护轮廓PP和安全目标ST（Security Target），并将功能和保证相分离。其中PP是一份安全需求说明书，针对某一类安全环境确定相应的安全目标，进而定义为实现这些安全目标所需要的安全需求。ST是一份安全需求与概要设计说明书，为某一特定的安全产品而定义的安全需求。CC标准为产品评价定义了一套评价保障等级 EAL（Evaluation Assurance Level）作为刻画产品的安全确信度的尺度，分为EAL-1,…,EAL-7。它的发布对信息安全具有重要意义，是信息技术安全评价标准和信息安全技术发展的一个重要里程碑。
我国在21世纪初也开始启动信息安全评估标准的相关工作，建立了GB 17859—1999《计算机信息安全保护等级划分准则》，该标准与TCSEC是相对应的，并增加了完整性保护的内容；另外，还建立了GB 18336—2001《信息技术 安全技术 信息技术安全性评估准则》，这是与CC相对应的技术评估标准。
通过信息安全性评估可以及时发现信息产品存在的安全问题，采取措施对安全问题进行修复、改进和提高。这里没有直接将信息安全性评估定义在软件产品的范畴，是因为除了软件（包括数据、文档）之外，信息系统安全性还涉及硬件、固件等。
信息技术的高度复杂性使得人们越来越难以判断所购买的信息产品是否能够满足他们的安全需求，因而信息产品的安全评估成为一个重要的议题。1.5 系统安全工程
系统工程（Systems Engineering）是系统科学的一个分支，是以大型复杂系统为研究对象，按一定目的进行设计、开发、管理与控制，以期达到总体效果最优的理论与方法。系统工程关注系统的组成要素以及要素之间的关系，并强调以工程的思想对大系统开发过程进行管理与控制。
系统安全工程SSE（System Security Engineering）是采用系统工程的理论与方法，识别、分析和评价系统中的危险因素，并根据分析结果调整工艺、设备、操作、管理、生产周期和投资费用等因素，使系统所存在的危险因素能得到消除或控制，使事故的发生降低到最低程度，从而达到最佳安全状态。系统安全工程的主要内容包括系统安全分析、系统安全评价、系统安全预测与系统安全控制。
对于已经具体实施的软件产品来说，软件的运行环境、硬件设备以及操作人员是无法分开的，因此在某一特定软件产品环境下，系统安全工程是指将专门的安全技术（如通信安全、计算机安全和网络安全技术等）应用于信息系统生命周期的各个阶段，以保证组织对信息系统的需求按照可行的安全策略得到满足，并使信息系统能够抵御可[8]感知的威胁。
国际知名信息安全专家，剑桥大学计算机系的Ross Anderson 教授在其著作 Security Engineering一书中对系统安全工程的定义是研究如何构建安全的系统，使系统在面对恶意攻击、错误以及灾难时仍保[9]持可靠性。
系统安全工程着重研究系统设计、实现和测试方面的过程、方法和工具，目的是以最优的费效比提供并实施满足安全需求的安全解决方案。良好的安全需求定义和完善的安全风险分析是实现系统安全工程目标的基础，选择合适的安全策略则是实现系统安全工程目标的关键，而提供支持安全需求定义、安全风险评估、安全策略制定与实施的模型、方法和工具则是系统安全工程的主要内容。1.6 系统安全工程能力成熟度模型
系统安全工程能力成熟度模型 SSE-CMM（System Security Engineering-Capability Mature Model）是一种衡量系统安全实施能力的方法，起源于1993年，由美国国家安全局NSA 发起，由60多个成员单位组成工作组，对于系统安全工程是否需要能力成熟度模型而开展的研究。1995年推出CMM 1.0版，1997年推出评价方法第一版；1999年完成了CMM2.0，2001年SSE-CMM2.0被国际标准化组织接受成为国际标准ISO/IEC DIS 21827信息技术-安全系统工程-能力成熟度
[10]模型。
CMM是基于统计过程控制理论基础之上的系统定义、管理完善、可测、可控的有效业务过程的度量，可用于指导信息安全过程的完善和改进，使系统安全工程成为一个清晰定义的、成熟的、可控制的、有效的和可度量的学科。
SSE-CMM将系统安全工程过程划分为风险过程、工程过程和保证过程三个基本的过程，强调安全适度原则，并指出对于开发过程，应从风险分析开始，分析威胁、脆弱性和影响，得出安全需求。因此，SSE-CMM强调安全需求分析，即如何得到适度的安全需求。
CC与SSE-CMM的区别：简单地讲，CC是软件产品质量评测标准，而CMM是实施的过程控制标准。
CC是面向最终产品评价的方法，即通过对文档、产品的分析测试来建立产品安全性的度量指标，通过安全需求的描述来测试安全需求与产品安全性能上的一致性。
CC标准强调安全需求的定义和获取，包括功能需求和保证需求。该标准定义了11个公认的安全功能需求类（即安全审计、通信、加密、用户数据保护、身份识别与鉴别、安全管理、隐私、安全功能组件保护、资源使用、安全产品访问和可信路径/通道），以及七个安全保障需求（配置管理、发行与使用、开发、文档、生命周期支持、测试和脆弱性评估）。CC 标准还提出了保护轮廓 PP 的概念，这是一个满足特定用户而与实现无关的安全需求，结合与安全目标[10]ST相应的安全功能需求来评价最终产品的安全性。
然而，相对于软件安全需求来说，CC标准的测试结果缺少继承性。即使是同一个开发团队开发出来的软件产品，前一个产品的测试结果也不能作为后续产品测试的基础，每一个产品都要重新进行测试，导致测试时间冗长和成本提高。
而SSE-CMM基于过程管理的视角，根据安全适度原则，提出软件安全开发应该从威胁、脆弱性及其影响进行分析，分析软件产品应用环境下将会面临的风险，从而得出安全需求。
CC的评估结果反映的是软件产品的确信度，一般只用于软件产品安全性的评价，而对于产品的开发过程并不予以关注，因而对安全开发只能起到辅助作用；而SSE-CMM的评估结果表达的是组织实施过程管理和制度能力的尺度，可用于软件开发过程的安全控制。但由于CMM本身仍属于过程评估标准的范畴，对于安全开发过程仍不能提供完全指导。1.7 属性驱动的软件安全开发的基本思想
软件工程是为了确保系统按照预期的功能目标运行，而安全工程则是确保某些事情不发生，其中包括软件错误、灾难，以及恶意攻击。这两者看似目标不同，但可以在软件开发过程中实现很好的统一。由于软件错误而导致的系统可靠性受到威胁，会危及信息系统基础设施（如工控系统）和个人隐私（如信用卡账户信息）的安全，给整个社会带来破坏作用甚至产生犯罪，阻碍经济有序发展。因而如何将软件工程与安全工程的理论方法结合起来，找到一条有效的途径，提高软件产品的本质安全性，这是我们亟待解决的问题。1.7.1 软件安全开发方法
NASA 8719.13A标准提出“软件安全性是指在软件生命周期内，应用安全性工程技术，确保软件采取积极的措施提高系统安全性，确保降低系统安全性的错误已经减少到或控制在一个风险可接受的水平内。”[11]
这一概念向我们阐述了软件安全性是一个针对软件生命周期的过程安全的概念。为了实现软件产品安全性的目标，2004年微软公司提出了系统安全开发的概念，其核心思想就是将安全要素嵌入到软件开发生命周期的全过程。
软件安全开发方法继承了系统安全工程的思想，以提高软件产品的本质安全为目标，将安全性的实现提前到软件开发生命周期的早期阶段，即从需求分析开始就考虑各种安全活动，从而最大限度地减少软件安全漏洞的数量，提高系统的整体安全性。
软件安全开发方法保留了风险管理、身份认证、访问控制、数据加密保护、入侵检测等传统安全方法的优点，抛弃了传统的安全保障方法的先构建系统，然后再将安全手段应用于系统的信息系统构建模式，将安全作为功能需求的必要组成部分，在系统开发的需求阶段就引入安全要素，同时对软件开发全过程的每一个阶段实施风险管理，以期减少每一个开发步骤中可能出现的安全问题，最终提高软件产品的本质安全性。1.7.2 软件定义安全
软件定义的信息安全（简称软件定义安全）是当前热门的信息安全话题。Gartner将软件定义安全作为2014年十大信息安全技术之一发布，体现了软件定义安全问题在当前形势下的重要性。为避免读者将“软件定义安全”与“软件安全”这两个字面上相似但意义却完全不同的概念混淆，本书中对软件定义安全加以简要阐述，以供读者辨别两者之间的异同之处。
软件定义安全SDS（Software Defined Security）：所谓的“软件定义”是指当我们将数据中心原本紧密耦合的基础架构元素（如服务器、存储、网络和信息安全等）解离并提取之后所创造的能力，如同网络、存储、计算的情况，对信息安全所产生的影响也将发生变化。软件定义安全并不代表不再需要一些专门的信息安全硬件，这些仍然是必不可少的，只不过，就像软件定义的网络一样，只是将价值和智[12]能化转移到软件当中而已。
软件定义安全SDS是从软件定义网络SDN（Software Defined Network）引申而来的，原理是将物理及虚拟的网络安全设备与其接入模式、部署方式、实现功能进行解耦，底层抽象为安全资源池里的资源，顶层统一通过软件编程的方式进行智能化、自动化的业务编排和管理，以完成相应的安全功能，从而实现一种灵活的安全防护。
1．软件定义网络SDN
软件定义网络是一种新出现的计算机网络结构，主要特征是网络路由和交换机中的数据平面及控制平面是分离的。换句话说，控制将硬件脱离出去，而通过软件来实现。在这种结构下，服务器中控制平面是通过软件来实现的，而与网络设备相分离；数据平面是在网络硬[13]件或设备中实现的。这种结构最典型的模型为OpenFlow。
为了更好地理解软件定义网络，首先看传统的网络结构是怎样对数据包构成威胁的。当一个数据包到达交换机或路由器时，固件告诉硬件向哪里转发数据包并通过相同的路径将所有的数据包发送到目标。换句话说，数据包的处理方式是一样的。更多高级的集成了应用电路的智能型交换机可以识别不同类型的数据包，并根据应用电路的编程原理将它们分别处理，这种解决方案非常昂贵。
然而，软件定义网络将控制与网络硬件的固件分离，而将它交到网络管理员的手中，管理员可以在不改变单个交换机设置的情况下，从一个中央控制台重塑网络信息流通量。这意味着管理员能够改变网络规则，根据需要进行优先级设置，甚至用强有力的控制来阻断某些网络数据包。SDN对于云计算是非常重要的，因为对于一种多承租人的架构来说，SDN允许一个更有效的灵活的负载控制。
SDN与之前的网络类型相比，也是一种相对便宜的解决方案，因为它可以允许使用更便宜的商用交换机，但仍然可以提供更好的流量控制。网络工程师和管理员能够支持跨越不同供应商、模型、集成已有应用电路的交换机以及没有集成的交换机等多种交换结构。OpenFlow是当前最流行的SDN规范，并且允许远程控制路由表。
2．软件定义安全SDS
软件定义安全是一类通过安全软件来使信息安全得到实施、控制和管理的安全模型，是一种由软件管理、政策驱动和治理而产生的安全，其中大部分的安全控制如入侵检测、网络隔离和访问控制都是自动化的，并可以通过软件来进行监控。图1.1 简要描述了软件定义安全的工作模型。
软件定义安全是IT 环境中的典型安全实现，如云计算和虚拟化技术，而尽量少或不依赖于硬件。环境中每一个新设备都要自动受到安全政策的监管和控制，当环境中基础设施和资源发生变化的时候也需要确保系统能够具有可扩展性。更进一步地，由软件定义和管理的安全，环境可以向其他数据中心或IT设备中迁移，但不会影响安全政策和控制措施的实施。图1.1 软件定义安全的工作模型
软件定义安全的核心在于安全控制平台，通过控制器的应用逻辑定义对信息系统提供保护，对于分布式的网络平台如云计算平台的安全保护尤其适用。
就具体实现而言，软件定义安全（SDS）框架可以划分为四个层次，由底至顶分别为安全资源层、转发层、控制层、管理编排层，如图1.2所示。图1.2 软件定义安全SDS
•安全资源层：由各种物理形态或虚拟形态的网络安全设备组成，兼容各厂商的产品。这些安全设备接受统一部署、管理、调度，以实现相应的安全功能。
•转发层：即SDN网络中的网络基础设施层（Infrastructure Layer），是一类仅需根据控制器指令进行数据包转发，而无须自主地理解和处理各种网络协议的网络交换设备。将网络安全设备接入转发层，通过将流量导入或绕过安全设备，即可实现安全设备的部署和撤销。
•控制层：能够根据不同业务的安全策略，从全局的视野对转发层和安全资源层进行集中管理并下发调度命令。
•管理编排层：由侧重于安全方面的应用组成，将用户配置或运行中实时产生的安全功能需求转化为具体的安全资源调度策略，并通过控制层予以下发，实现安全防护的智能化、自动化、服务化。
软件定义网络以及在此基础上发展起来的软件定义安全，基本思想都是不依赖于硬件设备，通过软件来实现系统的安全性，特别是可控性保障。从本质上来说，软件安全开发关注的是实现软件产品安全性的全面质量保证方法，而软件定义安全是实现分布式系统安全可控性的一种有效方法。二者虽然都属于信息安全工程的范畴，但却是两个不同的发展方向，可以高度地结合起来，实现更高等级的系统安全。1.7.3 属性驱动的软件安全开发方法
属性驱动的软件安全开发方法来源于对软件安全性的认识。（1）软件产品安全性的市场需求：将市场上的安全需求与用户的倾向性需求结合起来成为软件产品的安全需求，包括核心安全需求和安全相关需求。（2）传统的软件安全性构建方法是一种由创意到功能再到结构设计的思维过程。由于信息系统的复杂性，使得这种思维过程的发散空间巨大，因而很难找到满意解，这也是传统的系统安全方法成功率较低的主要原因。（3）与传统的系统安全性构建方法不同，属性驱动的软件安全开发方法先确定结构，然后再构造功能。根据康威定律和机械理论中的循环定律，某种形式或结构产生后，很容易构筑它的功能和用途[14]。
属性驱动的软件安全开发方法是一种基于瀑布模型的结构化的软件开发方法。从软件安全属性的认知开始，在软件开发生命周期的各个阶段体现了对于安全属性的认知、继承、实现、评估和反馈，又体现了迭代式开发过程不断进化的特点，最终实现软件产品的安全目标。
属性驱动的软件安全开发方法，是系统安全工程思想在软件开发过程的应用，强调属性驱动和过程控制的观点，是一种可追溯的软件安全开发生命周期的质量保证方法。1.8 本章小结
截至目前为止，人们对于软件安全尚没有一个统一的定义。已有文献基本从三个角度来描述软件安全：（1）从信息安全的基本属性出发来刻画软件安全，主要包括信息的保密性、完整性、可用性；（2）较早一些的软件安全性概念则从软件或系统测试的角度出发，注重漏洞测试及其修复方法；（3）当前应用最为广泛的描述信息技术安全性技术评估标准（CC）则从结构安全组件包、保护轮廓定义书和安全目标定义书三个方面对信息技术安全性进行了描述，并将功能和保证措施相分离，是相对较为全面的软件技术安全性定义。
根据软件安全性的内涵和外延，本书将软件安全性描述为六个核心安全属性、软件安全漏洞及其他安全相关属性，根据已有信息安全领域研究和标准对这些安全属性进行了定义，并提出了属性驱动的软件安全开发方法的基本思想，对于这些安全属性的认知是软件开发整个生命周期的安全基础。第2章将安全嵌入软件开发整个生命周期2.1 系统安全开发方法的进化史
为解决软件产品的漏洞问题，而将安全活动集成到系统开发和软[15]件质量保证活动中，相关的研究可以追溯到1986年。2000年，美国航空航天局（NASA）的一个系统安全评估项目正式开启了软件安全开发方法的序幕，其核心思想是要在软件开发的每个关键点嵌入安全要素，通过安全需求分析、安全设计、安全编码、安全测试等专业手段，解决各阶段可能出现的安全问题，以期减少软件开发过程中引入的安全漏洞数量，提高软件产品安全质量。
软件安全开发方法的基本出发点是要解决系统开发过程中产生的漏洞。为此，很多研究机构和大企业投入了大量的研究工作，相当的研究集中于系统开发模型，在短短十几年的时间先后出现了以AEGIS、微软SDL、McGraw的BSI（接触点）模型、OWASP的CLASP模型为代表的几十种软件安全开发模型，并在一些重要的领域，如军事、政[16]府和金融领域得到了应用。
这些模型基本可以划分为两个阶段：
第一阶段为2005年之前，此期间安全开发模型的一个显著特点是以安全问题为导向的启发式方法，针对开发过程中某一个或几个安全问题提出解决方案。例如，2003年由英国UCL大学计算机系的Ivan[17,18]等人提出来的AEGIS模型，该模型是最早的完整的软件安全开发模型，开辟了用形式化的UML 语言分析安全问题的先河，是一种基于螺旋式开发方法的软件安全开发模型，并引导研究者将资产识别、风险威胁分析、情景分析等思想融入到安全开发中。这一时期还发展[19,20,21,22]了一些软件安全性评估工具（SSAI）。
第二个阶段为2005年到现在，这一时期的安全开发模型是一种面向软件开发全生命周期的系统开发方法，代表性的方法有微软的软件安全生命周期SDL模型、McGraw的BSI模型、OWASP的CLASP模型，以及在此基础上发展起来的ISO27034、BSIMM和SAMM标准，这些模型和标准从不同的视角诠释了软件安全开发应遵循的方法。图2.1 给出了以时间为轴线的软件安全开发方法的演化历史。图2.1 软件安全开发方法的演化历史
尽管已经有学者对各种模型进行过对比研究，但到目前为止，对于软件安全开发领域的整体研究图谱还不是很清晰。无论是标准还是能力成熟度模型都是软件安全开发的框架，对于日益复杂的应用软件来说，如何获得软件安全需求，将安全需求转化为可实现的软件功能模块，最终实现软件的安全目标，还需要我们深入思考、不断地实践才能逐渐掌握。2.2 软件安全开发模型
对于软件开发各阶段的安全考虑从最初个别的启发式案例到后来在整个软件开发全过程的安全嵌入，经历了从启发式到全生命周期的安全开发模型两个发展阶段。2.2.1 启发式软件安全开发模型
启发式开发模型的一个显著特点是以安全问题为导向。2003年，Ivan等人提出了最早的安全系统开发模型AEGIS，开辟了用形式化的UML语言分析安全问题的先河，是一种基于螺旋式系统开发方法的安全系统开发模型。该模型站在利益相关者的视角进行资产的识别、分析风险和威胁，并将应用情景分析等思想融入到安全开发过程中；AEGIS还首次提出了风险及控制措施的成本度量问题，通过二者的比较，选择具有更好经济性的风险控制方法，该模型关注安全需求获取和设计，而对其他阶段没有详细的说明。2007年，Jeff Zadeh和[23]Dennis DeVolder提出问题/意见驱动的系统开发模型，针对软件的设计和开发的四个阶段（风险分析与响应、安全需求、安全设计、安全实施）提出一些相关安全问题和软件开发的指导意见。GQM（Goal/Question/Metric）模型则从目标/问题/指标三个维度构建安全的系统，首先从理论上找到有效的系统安全目标，从安全风险评估中发掘安全问题，然后根据生命周期各阶段汇集的问题找到适当的[24]软件安全测量指标，最后找到正确的测量目标，验证安全目标的实现。
启发式安全系统开发模型对于软件安全开发的理解还是片面的、局部的，但这一时期的开创性思想对于以后的研究有很大的借鉴作用。2.2.2 软件安全生命周期开发模型
2004年，微软公司提出的SDL模型成为安全生命周期开发研究中的里程碑模型。该模型遵从软件工程的瀑布模型开发方法，并继承了早期的软件安全开发的研究成果，比如AEGIS模型的威胁识别、风险分析及面向安全问题的UML系统开发建模方法；同时更加注重系统的实施和保障，如对缓冲区溢出和格式字符串漏洞等的防范，以期减少软件开发过程中产生的软件缺陷数量。
在此后的一段时期里，大量的模型借鉴了微软SDL安全生命周期模型的思想，将各种安全方法注入其中，逐步丰富了安全系统开发模型的理论体系，这其中也包括后来成为软件安全开发能力成熟度模型的著名的McGraw的BSI模型。一些方法如TSP-Secure模型主要通过安全规划、建立自主团队、管理安全和培训开发人员四个方面在开发过程中嵌入安全要素，强调开发团队中人员的作用，特别是安全经理[25]角色的重要性；Apvrille和Pourzandi则从实践中总结出具有很强的可操作性的安全活动和工具，并将它们引入到安全系统开发过程，该模型中提到的方法工具（如 UMLsec、各种测试工具）都有很好的实[26]际工程应用背景。
2007年，SecSDM提出了一个基于ISO7498-2—1989的简单过程模型，通过对标准的贯彻实施枚举了软件安全开发的10个步骤，为软件安全开发成为一种科学的可重复的过程模型提供了理论支持，为[27]不具备安全专业知识的开发人员构建安全的系统提供了指南。
2008年，Abhay Raman将安全工程和软件工程整合到一起，提出软件开发过程的整合模型，与传统软件工程的瀑布模型相一致，将软件安全开发分为计划、需求定义、架构设计、构建、测试、实施和展示以及运行维护七个阶段，并在软件开发的每一阶段定义了安全需[28]求（输入）和可交付物（输出）。
2009年，由OWASP提出的CLASP（Comprehensive,Lightweight Application Security Process）是软件安全开发的又一个代表性模型。该模型在系统开发过程中引入了问责制（可记账性原则），强调开发过程中安全活动的角色和职责，但采用较简单的流程阶段和交互，为每一阶段指派具体的角色负责安全活动，每一项安全活动都围绕指定的七项最佳实践来进行。CLASP模型采用基于角色的过程组件集合来构建系统的开发思想，组件之间可以以一种结构化的、可重复的、可度量的方式来集成，使开发人员能够采用相对简单的流程系统地开发出安全的软件产品，因而成为目前软件安全开发最佳实践的有效楷
试读结束[说明：试读内容隐藏了图片]