一、引言：
软件安全的重要性和相关性。
软件是我们在现实世界中做任何事情的关键，同时， 软件也分布在最关键的系统中。基于此，软件的安全设计是至关重要的。大多数信息技术 (Information Technology, IT)相关的安全解决方案已经能够有效地降低不安全软件带来的风 险。为了证明一个软件安全程序的合理性，必须知晓没有构建安全软件带来的金钱成本和其 他风险的重要性与相关性，以及构建安全软件的重要性、相关性和成本。总而言之，软件安 全同样是一个商业决定，因为它关注避免安全风险。
软件安全和软件开发生命周期。
在这里，重要的一点是要区分在软件开发中我们熟知 的软件安全(software security)和应用程序安全(application security)0尽管这两个术语经常 互用，但是我们仍然需要区分它们。因为实现这两个目的的程序在管理过程中存在明显的不 同。在模型中，软件安全表示在SDLC中，应用SDL构建安全的软件，而应用程序安全表示 发布后运行过程中软件和系统的保护。
高质量和安全代码。
尽管安全代码未必是高质量代码，同时高质量代码也未必是安全 代码，但是软件的开发过程是基于高质量和安全代码原则的。你不能拥有不安全的高质量代 码，更不能拥有劣质的安全代码，它们相辅相成。至少，质量和软件安全程序应该在开发过 程中紧密结合；理想情况下，它们应该是同一组织的组成部分，以及软件开发工程部门的一 部分。这将在本书中后面的章节中从组织和操作角度进一步讨论。
三个最重要的SDL安全目标。
所有软件安全分析和构建的核心是三个最重要的安全因 素：保密性(Confidentiality)、完整性(Integrity)和可用性(Availability),也称为 C.I.A.模型。 为了确保软件开发是安全的，上述三个特性必须一直作为整个SDL过程中的主要组成部分。
威胁建模和攻击界面验证。
威胁建模和攻击界面验证是SDL中最耗时和难以理解的部 分。在当今的敏捷软件开发中，必须正确处理这个问题，否则无法保证软件安全。SDL中的 威胁建模和攻击界面验证，将最大限度地避免软件产品发布后发现安全漏洞。我们认为这个 功能非常重要，因此本书将专门用一节和一章来关注这个主题。
二、安全开发生命周期
2.1克服软件安全中的挑战
SDL拥有开发行业、政府标准和最佳实践强化软件所需的所有活动与安全控制，它们也是SDL的基本组件。为了能够真正阻止、识别和减轻已开发系统中的可利用漏洞，经验丰富的工作人员、安全软件的策略和管制要求是必需的。
如果不满足SDL中的最小活动要求，将会给内部和外部威胁提供误用系统资产的机会。安全不再单纯是一个网络要求，它现在是一个信息技术(IT)要求，其中包括所有的软件开发意图分发、存储和处理信息。为了保护客户的隐私和他们的重要信息，组织必须实施最高标准的开发以保证发布最高质量的产品。
SDL程序的实现，能够保证良好的企业软件设计和开发固有的安全，而不是在产品发布后。使用SDL方法能够产生切实的好处，例如保证所有的软件版本符合最低安全标准，所有的利益相关者支持和强制执行安全准则。在开发周期的早期漏洞更容易被修复且成本更低,此时给信息安全团队提供一个系统化的方法在开发过程中协同消除软件风险。
2.2软件安全成熟度模型
实践模型：
1.策略和度量标准
2.符合性和政策
3.培训
4.攻击模型
5.安全特征和设计
6.标准和要求
7.架构分析
8.代码审查
9.安全测试
10.渗透测试
11.软件环境
12.配置和漏洞管理
BSSIM的第4个版本发布于2012年9月18 0,它的一些要点如下。
BSIMM项目中，除了原有的109个活动之外，首次观察到新的活动，因此未来模型增 加了两个新的活动：模拟软件危机和自动化恶意代码检测。
BSIMM4包括来自12个垂直行业的51家公司。
BSIMM4相对于BSIMM3增长了 20%,比2009年版大十几倍。
BSIMM4数据集有95个不同的测量（有些公司多次测量，一些公司由多个部门单独测 量并得到一个公司评分）。
BSIMM4继续表明，领先的公司雇用的每100个开发人员中平均有两名全职的软件安 全专家。
BSIMM4介绍了与2039名保证某软件安全的开发人员共事的974名软件安全专业人士 的工作，该软件由218 286名开发人员完成。[10]
OWASP的软件保证成熟度模型（SAMM）是一个灵活的规范性框架，用于把安全性融入 软件开发组织。通过覆盖多于典型的SDLC基础模型的安全性，SAMM使得组织能够自行评 估其安全保障程序，然后使用建议的路线图在组织面对的特定风险方面有所改进。除此之外， SAMM能够创建记分卡，记录在典型的管理、开发和部署业务功能过程中组织在安全开发方 面的有效性。记分卡也能够在组织内部实现管理，通过迭代建立安全保证程序来说明量化的 改进。
2.3 ISO/IEC 27034：信息技术、安全技术、应用安全
ISO/IEC制定了ISO/IEC 27001标准(纳入ISO/IEC 17799，这一直是信息安全事实上的ISO标准)。它是一个信息安全管理体系( Information Security Management System, ISMS)标准，通过制定一个管理体系获得正式管理控制下的信息安全。它规定了一个组织采用该标准时需要满足的具体要求。该标准从整体上解决了信息安全问题，囊括了从物理安全到规范的所有内容。行业踊跃采用该实践，ISO/IEC 27001是当今面向信息安全管理体系(ISMS)的领先标准。大多数其他标准的控制策略都可以映射回ISO/IEC 27001标准中。这使得组织能够在一个标准下加强各种安全力度，寻求整体安全考虑下的单一框架，并以一种一致的方式收集度量标准来衡量和管理一个组织的安全。
在ISO/IEC 27001标准出现的几年前，作者看到与信息安全类似的软件安全(和SDL)已经出现。有多种SDL方法(开放的和专有的)，每一个都自称比下一个好。混乱阻碍了组织中实现软件安全的最佳方式。对一个组织应用任何一个框架，要求组织采用不同的过程或者定制一个使用他们环境的SDL框架。随着ISO/IEC 27034标准的出现，作者看到软件安全标准/框架开始整合，就像ISO/IEC 27001标准对于信息安全的影响。即使处于起步阶段，也应该意识到ISO/IEC 27034标准的重要性。微软已经宣布其SDL方法将会遵守ISO/IEC 27034-1标准。4我们期望在不久的将来能够看到其他框架类似的结果。
ISO/IEC 27034标准提供帮助组织内嵌过程(包括应用程序生命周期)安全方面的指导,有助于环境中运行安全的应用程序。它是一种基于风险的框架，通过流程整合/改进来管理应用程序，持续不断地提高其安全性。这需要过程方法的设计。
2.4其他SDL最佳实践的资源
1、SAFECode
2、美国国土安全软件保障计划
3、美国国家标准与技术研究院
4、MITRE公司公共计算机漏洞和暴露
5、SANS研究所高级网络安全风险
6、美国国防部网络安全与信息系统信息分析中心
7、CERT、Bugtraq和SecurityFocus
2.5关键工具和人才
1．工具
1.1模糊测试
模糊测试(Fuzz testing/Fuzzing)是一种自动或半自动化的黑盒软件测试技术，它为某一 计算机软件程序输入提供了无效、意外或者随机数据。
1.2静态分析
静态程序分析是指在不实际运行程序的条件下，进行计算机软件分析的方法。
1.3动态分析
动态程序分析是指在真实或者虚拟处理器中运行程序的条件下，进行计算机软件分析的 方法。
2．人才
2.1软件安全架构师
2.2软件安全从业者
2.6最小特权原则
限制特权提升是威胁建模的重要部分，其也是SDL架构（A2）阶段的一个核心组成部分，这将在第4章讨论。特权提升的概念是非常重要的，它是微软安全开发生命周期卡片游戏的主题，旨在培养开发人员和安全专业人员快速、轻松地找到软件或计算机系统的威胁。未经授权的权限提升攻击利用程序错误或设计缺陷，赋予攻击者访问网络及其相关的数据和应用程序的提升权限。这些攻击可以是垂直的(攻击者赋予自己特权)，或水平的(攻击者使用已经赋予的相同水平的特权)，但假设他拥有具有相似权限的另一个用户的身份。
确保最小特权防止敏感数据泄露，并防止未经授权的用户访问程序或者他们未曾想要访问的区域。软件设计应遵循最小特权原则，这是软件发展的一个关键因素。限制特权等级是非常重要的，因为特权提升可以导致攻击者获得超过授予一个普通用户的授权。例如，若拥有普通用户特权的攻击者有“只读”权限，则他或许能够破解软件进而提升权限以获得“读写”权限。推动最小权限要求用户获得执行一个特定任务所必需的最小权限。在SDL/SDLC的设计阶段，你需要确定执行工作所需的特权最小集合，限制用户登录到只有这些特权的域中。确保最小特权不仅包括用户权限的限制，还包括资源权限的限制，比如CPU限制、内存、网络和文件系统权限。这就要求将权限授予一个对象之前满足多个条件，因为仅仅检查一种状况下的访问可能无法满足强安全性。例如，如果攻击者能够获得一个特权，但没有获得第二个特权，将会限制其实施成功的攻击。将软件隔离到需要多次检查访问的单独组件中，可以抑制攻击或者可能阻止攻击者接管整个系统。访问权限的慎重授权可以限制攻击者成功地攻击软件或系统。资源的最小权利和访问应限于完成该任务需要的最短时间内。
2.7隐私
保护用户的隐私是SDL过程的另一个重要组成部分，应被视为SDLC所有阶段重要的系统设计原则。用户隐私安全出了问题将导致信任危机。由于在未经授权访问的用户越来越多的情况下，个人信息在媒体中公开，在软件和系统中使得客户的数据得到可靠保护的状况日益恶化。此外，许多新的隐私法律法规强调了在软件和系统的设计和开的包含隐私的重要性。至于安全性，已经通过的软件开发生命周期的进度的变更是成本很高的，就是把高成本的隐私保护方法和技术融入SDLC的适当阶段，以维护个人的隐私，并保护个人身份信息（PII)的数据。包含在微软SDL中的一些关键的隐私设计原则，包括提供有关数据收集、存储或者共享的适当通知，使用户可以对自己的个人信息做出明智的决策;使用户策略和控制可用;最小化数据收集和敏感性;以及存储保护和数据传送。
2.8度量标准的重要性
SDL 的一个目标是在整个过程中实现缺陷多级过滤过程，而不是仅仅包含单个活动或时间节点，从而使导致漏洞的剩余缺陷最小化。每个缺陷去除活动可以被看作一个从软件产品中消除一定百分比缺陷的过滤器，这些缺陷可导致安全漏洞。在软件开发生命周期中有越多的缺陷去除过滤器，当软件产品发布时,其中剩余的可导致安全漏洞的缺陷将越少。更重要的是，早期的测量使组织能够于软件开发生命周期的早期采取纠正措施。每一次缺陷去掉时，都会测量它们。每个缺陷移除的点都会成为一个检测的点。缺陷度量比缺陷的移除和预防更重要:它告诉团队他们的立场与目标，帮助他们决定是否要转移到下一个步骤，或停止并采取纠正措施，并指示如何改正以满足他们的目标。本书将重点介绍SDL模型中如何在
有意义的安全度量标准允许一个组织确定其安全控制的有效性。为了有效地衡量一个组织的安全状况，产品的安全性首先要保证适当的框架到位，以得出有意义的度量数据。这包括适合于产品的安全治理模式、企业的战略和运营要求。这样的模式应该实现实用的产品安全政策和程序，统一部署最佳做法和措施，并要求在整个组织强有力地执行管理支持。最佳实践要求下的安全性是作为一个企业的水平、垂直和跨职能管理整个组织的模型。这种模式事活合干实现—颈的监测、计量和报告个业的产品安全状况。
2.9把SDL映射到软件开发生命周期
无论你使用何种SDL模式，不论它是否已经存在，一个你自己开发的或者是两者的结 合，都必须将其映射到当前的SDLC才能有效。图2-4是一个SDL活动和最佳实践模型，作 者已经开发并将其映射到典型的SDLC阶段。每一个SDL活动和最佳实践基于现实世界的经 验，作者提供的例子向读者表明安全可以内置到每一个SDLC阶段中——安全到SDLC的映 射。如果安全内置到每一个SDLC阶段，那么该软件默认有较高的概率是安全的，后续软件 的变化是不太可能危及到整体安全的。这种映射的另一个好处是，你将有可能与SDL的拥有 者和的利益相关者一起工作，这将有助于在SDLC的操作和业务过程中构建买进、高效和可 实现的安全，将可能包括开发人员、产品和项目经理、业务经理以及主管。
2.10软件开发方法
1．瀑布开发
2.敏捷开发
2.1Scrum
2.2精益开发
三、安全评估（Al）: SDL活动与最佳实践
3.1软件安全团队提早参加项目
SDLC通常有正式的启动会议，把软件安全团队包括在内是非常重要的，以确保安全是SDLC的重要元素，并内置于整个过程。现场会议或网络会议给了与会者和利益相关者来大致认识和了解的重要机会。开发过程的早期就引入安全团队是启动风险辨识、规划和减轻最具成本效益的方法。早期识别与减轻安全漏洞和错误配置将降低安全控制实施和漏洞缓解的成本;提高强制安全控制所造成的潜在工程挑战的认识;以及识别共享的安全服务，重复安全策略和工具，以降低开发成本，同时通过行之有效的方法和技术，提高安全性。安全团队的早期介入将使开发人员计划的安全要求和相关的约束加入到项目中。这也提醒项目负责人,随着项目的继续许多正在做出的决定应适当权衡安全隐患。早期的规划和认识将通过适当的风险管理规划，节约成本与时间。安全性的讨论应作为项目的一部分，以确保业务决策和风险影响到整体的发展这个观点成为项目人员间坚实的理解。
3.2软件安全团队主持发现会议
发现会议基本上是一个SDL启动会议，在会上关键的SDLC利益相关者在过程开始时聚在一起，使安全成为内置的而不是附加的。在发现会议安全规划中应包括筹备整个系统生命周期，包括关键安全里程碑和可交付成果以及工具和技术的鉴定。特别应考虑到可能需要进行采购的项目，比如软件安全性测试和评估工具，以及第三方软件安全架构师或工程师潜在的使用可能,(如果需要扩充员工或有客户要求第三方认证)。其他资源的影响，如主动测试、认证以及所需的培训，必须加以考虑。整个系统的每一个安全注意事项应该规划在一系列里程碑或安全会议中。发现会议的成果通常是其对未来活动的决定条款，这在SDL过程中是后面的实际安全或隐私方面的活动。项目进度表应结合安全活动，以确保与时间表和资源相关的任何未来决定有适当的规划。所有的会议参与者和利益相关者应该就本次会议的安全影响、注意事项以及对软件的要求达成共识。
3.3软件安全团队创建SDL项目计划
SDL的项目计划应基于发现阶段获得的信息列出安全里程碑，并把它们集成到整个SDLC的时间表中，使得变化发生时有适当的规划。在发现阶段,从决策方面来说，活动可能转化为安全活动遵守里程碑。这个项目计划整合了在发现阶段反映安全性和隐私活动或决策的初步时间表这样的安全预期的共识。
3.4隐私影响评估计划启动
PIA要点：
立法摘要
所需的工艺步骤
技术和技巧
其他资源
评估初步需求的内容：
利益相关者的教育
其他软件的交互
PII收集
PII存储保留
访问
隐私管理工具
安全保障
数据完整性
评估安全性和私密性要求之间是否有冲突
应用最小特权原则
网络和web服务
使用cookie
IP地址
客户隐私的通知
儿童的隐私
第三方
用户控件
需要在共享计算机上使用的软件隐私控制
协作、分享和社交软件隐私特征
安全
隐私影响评级
P1高隐私风险
P2中隐私风险
P3低隐私风险
###安全评估（A1）成功的关键因素和度量标准
成功的关键因素：
计划SDL活动的准确度
产品风险轮廓
威胁轮廓的准确度
有关规定、认证和法规遵从框架的覆盖
软件所需安全目标的覆盖
可交付成果：
产品风险轮廓
SDL项目概述（针对安全里程碑和映射到开发进度）
适用的法律和法规
威胁轮廓
认证要求
第三方软件列表
度量标准模板
度量标准的建议：
软件安全团队循环的时间（单位:周）
参加SDL的利益相关者的百分比
SDL活动映射到开发活动的百分比
安全目标满足的百分比
四、架构（A2）：SDL活动与最佳实践
4.1 A2策略一致性分析
软件的安全策略的目的是确定哪些需要加以保护以及它如何受到保护，包括审查和结合SDL外可能会影响开发进程的策略。这些措施可能包括治理软件或开发或应用在组织中的任何地方的策略。在这个阶段，SDL 的策略域外存在的任何策略都将被审阅。企业安全与隐私策略可能会指示设计和开发人员必须有什么样的安全和隐私功能及它们该如何实现。其他策略可能包括那些支配使用第三方和开源软件或组织内部和外部的保障与控制源代码以及其他知识产权。假设软件安全组独立于集中信息安全组，重要的是，这两个群体就涉及开发和发布后后的安全支持及从该组织的软件响应所有的策略和指导方针进行合作。同样重要的是与公司的保密功能进行协作，无论是集中组还是外部法律顾问。
4.2 SDL策略评估和范围界定
SDL还提供了一个非常宝贵的指南为软件开发人员设置其组织的安全标准，应该提供一个实现路线图而无需中断生产高质量软件应用的核心业务。除非开发组织和管理团队的高层领导支持这种模式，否则SDL可能会失败。它必须由签订、出台的政策来驱动，并最好由CEO和软件开发管理团队提供支持。一个组织本应该有一个书面的和可重复的SDL的策略与方针，以支持SDLC，其中包括其业务需求，并作为它支持的工程和开发文化的补充。该组织的文化和成熟度在SDL策略的制定中是非常重要的，这样可以确保它会同时实现可行性和实用性。管理风格、人员、流程和技术需求(包括产品的整体架构)的复杂性，将有助于确定怎样的粒状或目标来作为重点指导方针。外包开发量，如果有的话，也需要作为这个过程的一部分被评估。一个内部的开发团队需要更详细的程序，而一个外包功能将需要更多的合同对象、服务水平，以及详细的可交付物。
4.3 威胁建模/架构安全性分析
1.****威胁的风险建模：
1确定安全目标
2调查应用程序
3分解它
4识别威胁
5确定漏洞
设计原则：
1.开放式设计:假设攻击者有来源和规格。
2.故障保护默认值:无法关闭;无单点故障。
3.最小特权:除需要外没有更多特权。
4.机制的经济:保持简单。
5.分离的特权:不要允许基于单一条件的操作。
6.总计调解:每次检查所有事情。
7.最常见的机制:谨防共享资源。
8.心理上的可接受性:他们会使用它吗?
安全性能：
1.保密性:数据仅提供给有意访问它的人。
2.完整性:数据和系统资源只以适当的方式由适当的人改变。
3.可用性:在需要的时候和以可接受的方式执行时系统可用。
4.身份验证:确定用户的身份(或者你愿意接受匿名用户)。
5.授权:用户明确允许或拒绝对资源的访问。
6.不可否认性:用户无法执行的操作,之后拒绝执行它。
参与威胁建模的关键步骤:
1.用数据流图打破你的产品架构。
2.使用STRIDE威胁类别，以确定哪些威胁适用于数据流图中的每个元素。
3.映射适用于使用场景的背景下有关漏洞的所有威胁。
4.威胁等级评价。为每个威胁和漏洞分配一个风险评级，用于了解它们的影响;这将有助于确定修复它们的优先级。使用DREAD或其他方法。
5.对每个标识的漏洞定义缓解计划/对策。
6.按照前面的步骤确定的优先级修正业务的不能接受的漏洞。
2.****数据流图：
威胁建模过程的第一步是确定威胁流的一个可视化表示，通常情况下这以图的形式在白 板会话期间绘制。重要的是要对这个过程提供一种结构。提供结构有助于避免错误。如果没 有一个良好的图，你可能不会有一个良好的威胁模型。重要的是要了解，第一，这项工作是 关于数据流的，而不是代码流。这是团队开发人员常常犯的错误，因为他们的生活、工作与 代码开发息息相关，但是通常不注重他们正在开发的代码的数据安全。在这个阶段的威胁建 模过程中所产生的图被称为数据流图或DFD,这应该是毫不奇怪的。DFD的重点是关注在软 件解决方案中数据如何移动，在移动时数据发生了什么，让我们更好地了解软件是如何工作 的和它的底层架构，方式是提供软件如何处理数据的可视化表示。该可视化表示是分层的结 构，所以它可以让你将软件架构分解成子系统，以及较低级别的子系统。在较高的水平，这 可以让你清楚被建模的应用范围；在较低的水平它可以让你专注于处理特定数据时涉及的具 体流程。
在开始建立你的DFD前，了解你所要使用的元素图像始终是一个好主意。DFD中通常使 用的基本元素和符号如图4-3所示。可以通过连接这些不同的元素作为数据流并应用的元素 （如适用）之间的边界建立DFD。
这里使用DFD的第1个例子是一个Web应用程序的威胁建模数据流图，见图4-4。这个 数据流图表示由客户和远程员工从公司网站访问企业营销数据的过程。第一个也是最明显的 安全控制区别在公司员工文件访问和客户文件访问之间。员工数据可能包含授权公司仅用于 公司员工的IP信息，并根据他们的职责，非常敏感的竞争力营销和定价数据只对’需要知道” 的员工授权。
3.****架构威胁分析和威胁评级：
1.****威胁判定（STRIDE）
•欺骗(Spoofing, S)
•篡改(Tampering, T)
•否认(Repudiation, R)
•信息泄露(Information disclosure, I)
•拒绝服务(Denial of service, D)
•提升权限(Elevation of privilege, E)
2.****威胁分析
1.输入验证
2.身份验证
3.授权
4.配置管理
5.敏感数据
6.会话管理
7.加密
8.参数操作
9.异常管理
10.审计和日志记录
3.****威胁的评级
风险 = 概率 X 潜在损害
DREAD模型：DREAD算法用来计算风险值，它是DREAD类别的平均值
Risk_DREAD = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS+ DISCOVERABILITY)/5
4.****风险缓解
有四种方法可以计划减缓和应对威胁:
1.重新设计过程以消除威胁。
2.作为一般性建议应用标准的缓解方法。
3.发明一种新的缓解策略（高风险且耗时）
4.接受低风险、非常费劲才能解决的安全漏洞。
完全缓解的威胁:威胁具有相应的对策，并且不再暴露漏洞或造成影响。
部分缓解的威胁:威胁使用一个或一个以上的对策被部分缓解，这表示可以漏洞仅可以被部分利用,并且造成有限的影响。
未缓解威胁:威胁没有对策，并表示可以得到充分利用的漏洞，并造成影响。
4.4开源选择
关于开源软件会增加软件的安全性还是会不利于它有一个正在进行的讨论，但底线是，你要导人软件到你的软件应用程序或解决方案中，而你的公司没有开发或者安全监督权。这将需要一个广泛的审查——通常称为第三方安全评估，该评估将由你的软件安全架构师、第三方组织，或两者的结合来进行。虽然很容易依靠工具和开源开发过程的粗略审查。但是如果没有适当的训练和经验，很容易得到错误的结果，难以形成一个可操作的修复策略。这就是高级软件安全架构师或第三方组织必须参与这一审查过程的原因。他们有多年的代码安全审计经验，有定期审查高度复杂和先进的软件安全和架构的挑战，知道如何识别和检查设计中的薄弱环节，并能发现可能导致安全的缺陷。如果没有适当的训练和经验，很容易导致错误，并且难以形成必要的可操作的补救策略。从本质上讲，对软件产品中使用的任何开源软件或组件的审查，都需要由经验丰富的软件安全架构师进行工具评估、进一步的威胁建模和风险评估。
4.5隐私信息收集和分析
考虑到系统是否能够传输、存储、创建隐私信息在SDLC早期是很重要的。信息收集、辨识以及规划实施适当的保障措施和安全控制(包括解决隐私信息事件处理和报告需求的流程)都是在这个阶段决定的。SDL 的这个阶段就是对隐私影响评估(PIA)的信息收集和分析的开始。分析阶段决定了PII将如何处理，以确保其符合有关隐私的法律、法规和政策规定;软件和开发的整个系统中，收集、维护、以可识别的形式传播隐私信息的风险和影响，或在云或SaaS环境中与它交接的风险和影响。检查和评估保护和处理用于减轻潜在的隐私风险的信息的替代过程。
4.6成功的关键因素和度量标准
成功因素：
可交付成果：
度量标准：
业务威胁、技术威胁(映射到业务威胁)和威胁参与者的列表。
这个阶段之后不满足的安全目标个数。
遵守公司(现有)政策的百分比。软件入口点的数量(使用的DFD)。
风险（和威胁)接受、减轻和容忍的百分比。
重新定义的初始软件需求百分比。
产品中计划的软件体系结构(主要和次要)的变化数量。
根据安全要求所需的软件体系结构更改数量。
五、设计和开发（A3 ）: SDL活动与最佳实践
5.1 A3策略一致性分析
对SDL域外部的所有策略进行评估。这是为了保证公司外部的开发机构在软件开发过程中遵守公司内部的安全和隐私需求以及开发指南。公司的安全和隐私策略会对需要达到的安全和隐私特征进行描述，并指导设计人员和开发人员如何实现这些特征。其他策略可能针对公司内部或公司外部在软件中使用的第三方或开源软件的管理，控制源代码以及其他智力成果。假如软件安全组是与集中的信息安全组是分开的，那么两个组都要基于所有的原则和策略进行协作是很重要的，包括开发、版本发布后的安全支持以及产品的反馈。同样重要的是在隐私功能上的合作,无论是集中式组还是外部法律决策。
5.2安全测试计划构成
测试活动用来验证产品发布后的安全措施是否能有效降低客户或恶意用户发现安全问题的可能。软件通过安全测试、工件( artifact)、报告和工具对软件的安全性进行验证。我们的目的不是为了证明产品不安全，而是在产品提供给客户前保证软件的健壮性和安全性。这些安全测试方法确实能发现安全bug，尤其是在那些没有经历关键的安全开发流程变更的产品中。安全测试和评估的结果也可能在安全控制中发现缺陷，安全控制用于保护正在开发的软件。因此需要制定详细的行动计划和里程碑进度，以记录计划的整改措施，进而增强安全控制的有效性，并在软件发布之前提供必要的安全措施。
5.3威胁模型更新
在通过第4章介绍威胁模型构建过程之后，知道构建过程何时完毕是很重要的。需要回 答以下几个问题，答案可能取决于商业竞争与安全风险之间的取舍。
\1. 你开发的软件是否能符合所有相关政策、法规、条例的规定？并且对于每个需求获得 各个层次的批准？
\2. 所有的利益相关方是否对威胁建模过程中识别出的安全和风险进行了检查？相关的架构 师、开发人员、测试人员、项目经理以及其他所有了解软件的人员都应为威胁模型构建做出贡 献并进行核查。为了保证威胁模型覆盖全面，应广泛征求各方意见。所有相关人员在威胁和风 险的认识上达成一致是很重要的。否则，针对威胁模型实现相关措施的落实会面临很多困难。
\3. 你是否就建立威胁模型和针对威胁模型釆取的应对措施、测试所需的时间和资源与相 关方达成一致？
\4. 你对风险和威胁的排名是否与相关人员达成了共识？如果你是一个软件购买者，是否 会同意这个排名？
5.4设计安全性分析和检查
1.最小权限
2.职责分离
3.纵深防御
4.故障安全
5.经济机制
6.完全仲裁
7.开放式设计
8.最小公共机制
9.心理可接受性
10.最弱环节
11.利用现有的组件
5.5隐私实现评估
高级隐私风险：特征、产品或服务对个人身份鉴别信息（personally identifiableinformation, PII)进行存储或传输,更改相关的配置或文件类型,或安装软件。
中级隐私风险：影响特征、产品或服务的隐私的独立行为是一次性的、用户发起的、匿名数据传输的（如，用户点击一个链接软件就跳转到一个外部网站)。
低级隐私风险：特征、产品或服务内部没有影响隐私的行为。不传输匿名或个人数据,不存储PII,没有配置改变用户的利益，不安装软件。
5.6成功的关键因素和度量标准
成功的关键因素
全面的安全测试计划
有效的威胁模型
设计安全性分析
隐私实现评估
策略一致性审查
可交付成果
更新的威胁模型工作
设计安全审查
安全测试计划
更新的策略遵从分析
隐私实施评估结果
六、设计和开发（A4)：SDL活动与最佳实践
6.1策略一致性分析
在这个阶段，任何存在于SDL域之外的策略都要被检查(或重新检查)。这些策略可能包含当在组织中开发软件或应用时来自开发组织之外的策略，这些组织维护要遵守的安全与隐私需求以及指导方针。在开发过程中策略更新以及需求增加也是经常发生的事。因此你最好能够对照策略更新列表并确认策略中已经包含了新的需求。
6.2全测试用例执行
基准测试:基准测试用来比较系统的评估状态和实际状态。
预定测试:预定测试是对软件和相关系统强制性的安全性验证，无论是否是安全问题或漏洞都必须实施检测和调试。
探索测试:探索性测试强调每个测试者的个性自由和对于测试质量的责任，通过学习测试相关的知识、测试设计、测试执行、测试结果解释持续地优化测试质量，在项目中采用相互支持的方式并行地执行测试工作。"测试人员积极地控制测试设计，并且在测试过程中设计新的和更好的测试方法。
6.3 SDLC/SDL过程中的代码审查
确定代码审查对象
执行初步扫描
针对安全问题进行代码审查
检查架构方面的安全问题
6.4安全分析工具
代码静态分析（优点和局限性）
阶段1：运行所有可用的代码分析工具
阶段2：寻找共同的安全漏洞模式
阶段3：深入分析代码
代码动态分析（优点和局限性）
模糊测试（优点和局限性）
聪明型模糊测试
笨拙型模糊测试
人工源代码审查的优点和局限性
控制流分析
数据流分析
6.5成功的关键因素
安全测试用例执行
安全测试
隐私验证和修复
策略合规性检查（更新）
6.6可交付成果
安全测试执行报告
更新策略的合规性分析
隐私遵守报告
安全测试报告
修复报告
6.7度量标准
应该在SDL的这个阶段收集以下度量标准（之前讨论过的一些应该交叉度量）。•遵守公司策略的比例(更新)
遵守阶段3和阶段4的比例对比
通过静态测试工具实际测试的代码行数
通过静态分析工具找到的安全缺陷数量
通过静态分析工具找到的髙风险安全缺陷的数量
缺陷密度(每一千行代码的安全问题数量)
通过静态分析、动态分析、人工代码审查、渗透测试、模糊测试找到的安全问题的类型和数量
使用不同类型的交叉测试找茁的安全问题
对比不同测试类型找到的安全问题的严重程度
把找到的安全问题与之前确定的威胁/风险进行映射
对发现的安全问题进行修复的数量
发现问题的严重程度
花费在修复发现问题上的小时数(大约)
发现问题中未解决问题的数量、类型和严重程度
遵守测试安全计划的比例
安全测试用例执行的数量
执行安全测试用例发现的问题数量
执行回归测试的数量
七、发布(A5):SDL活动与最佳实践
7.1 A5策略一致性分析
归入标准化SDL授权和活动的项目类型
定义每个SDL/SDLC项目阶段必须遵守的策略和过程
设置版本发布必须满足的需求
7.2漏洞扫描
安全漏洞扫描工具利用应用程序和数据库签名尝试确认应用程序缺陷的存在。安全漏洞扫描与渗透测试不同，不应归类其中;但是，一些相同的工具可能在两个过程中都会使用。安全漏洞扫描实际上是一个评估，会在软件和相关系统中查找已知的安全漏洞。安全漏洞扫描是自动运行的，技术人员执行后，会报告潜在的问题。开发人员执行安全漏洞扫描可以帮助他们认识和理解软件安全的基本要求。作为对比，渗透测试实际上会暴露系统架构中的弱点，需要软件和测试系统领域各种级别的专业知识。这类测试一般会让经验丰富的软件全专家（例如软件安全架构师或经验丰富的安全工程师)来执行。
7.3渗透测试
测试人员要求：
1.已经能够理解和分析可用的设计文档、源代码，以及相关开发工件，并有软件安全的背景和知识。
2.能够像攻击者一样思考,有能力设计测试用例验证软件漏洞。
3.拥有借助不同工具和技术进行白盒测试的知识与经验，能够跳出局限或非常规地思考,就像使用相同工具和技术的对手。
7.4开源许可审查
1.开源软件协议的遵守。不遵守开源软件许可要求会导致价格高昂和耗时的起诉开庭时间，侵犯版权，媒体披露，不良的公众形象，不遵守许可会带来风险和消极的商业关系。不当的管理和不遵守开源许可也会导致无法对软件产品提供支持，版本发布延期或停滞。
2.开源软件安全性。SDL、开发团队以及投资者需要意识到并理解与开源软件代码相关的安全漏洞会在他们的产品中出现。就像自己开发软件一样，所有开源软件已知的安全漏洞以及在安全社区公布的安全漏洞必须在SDL过程中使用相同的威胁模型进行确认，评估以及修复，架构性的安全和隐私审查，风险评估。
7.5最终安全性审查
三种结果：
1.最终安全审查通过。在这种情况下，所有已经确认的最终安全问题已经修正，软件已经确认满足了所有SDL需求,从安全角度来说已经具备了发布的条件。
2.最终安全审查通过但是有异常。在这种情况下，所有已经确认的问题并未全部修正，但是作为妥协可以接受开发团队无法处理的一个或多个异常。作为异常，没解决的问题将不在当前版本进行解决并且会被定位在接下来的补丁或版本中进行修正。
3.最终安全审查没有通过，需要进行扩展。在这种情况下，SDL和开发团队对一些安全漏洞与修补情况无法妥协，因此软件不能够发布。一个典型的商业理由是，SDL过程早期没能发现未遵守SDL安全需求的问题。导致软件无法发布的SDL需求无法被两个团队解决并且必须扩展至更高的管理层面来决策，用来评估不满足需求进行软件发布带来的风险与后果。扩展至管理层应该查看SDL和开发团队提交的包含安全风险描述和理由的报告。
4步流程：
1.评估资源的可用性。在该步中，需要确定执行最终安全审查的资源。增强质量的能力标准应该在软件发布前评估。可接受的最低安全水平应该通过质量标准建立起来。在SDLC过程的早期建立质量标准，从而可以使安全风险在SDL过程的早期就被认识到，保证了安全漏洞能够在早期被确认和修复，避免了不需要的工作导致的版本发布延期。SDL和开发团队必须将遵守质量标准作为最终安全审查的一部分。如果安全已经确认在SDLC过程中作为SDL的结果建立起来，就可以最小化完成最终安全审查的时间;如果没有建立，就会需要更多的时间和资源,可能会导致版本发布的延期。
2.确认合格的特征。在该步中，确认最终安全审查的安全任务的合格标准。合格的特征应该在SDL过程的早期建立，避免最终安全审查中包含未完成的安全工作。子团队也应该被审查，在SDL过程中可能包含没有报告的安全漏洞，在最终安全审查中可能会找到意外发现的遗留高风险安全漏洞。
3.评估和制订修复计划。在该步中，对任务负责的利益相关者确认之前的步骤中已经得到了通知,对最终安全审查的日程安排进行确认。
4.版本发布。除了质量标准或漏洞之外，在所有SDL需求，例如模糊测试、安全漏洞扫描、安全编码原则检查、其他现有的安全审查得到审查并批准之后，产品安全审查就完成了。功能回归测试也会占用安全审查的资源。回归测试用来发现新软件安全漏洞或根据已经发现的安全漏洞进行回归测试。这些回归测试可能导致已经存在的功能性和非功能性方面的发生改变。简言之，回归测试评估软件的一个部分发生改变是否会导致软件或系统中与它交互的另一个部分发生改变。
7.6最终隐私性审查
典型情况下，软件的隐私需求必须在发布前得到满足。尽管最终安全审查必须在版本发布前完成，如前所述但是安全例外强调并不是所有安全问题都得到解决才进行版本发布。隐私需求通常可以在最终安全审查的很多测试用例中得到核实。在隐私问卷调查完成后需要做的重要改变，例如收集不同的数据类型，大幅改变语言或风格，或确认新的软件行为可能会对隐私造成潜在的负面影响，都应该被定位。这就需要对软件任何相关的改变，或之前最终安全审查中隐私审查部分确认的问题进行进一步审查。
7.7成功的关键因素
策略一致性分析
安全漏洞扫描
渗透测试
开源许可审查
最终安全审查
最终隐私审查
客户协议框架
7.8可交付成果
更新策略一致性分析
安全测试报告
修复报告
开源许可审查报告
最终安全和隐私审查报告
用户协议框架
7.9度量标准
应该在SDL的这个阶段进行以下度量。遵守公司策略的百分比（更新的）
阶段4与5中遵守的百分比
安全漏洞扫描和渗透测试发现的安全问题的数量、类型和严重性
不同类型测试中找到的交叠的安全问题
不同类型测试发现的安全问题严重性的对比
发现的安全问题与之前确认的威胁/风险的映射
发现的安全问题的修复数量（更新的）
发现的问题的严重性
修复发现的问题花费的小时数
发现的严重问题的数量、类型、严重性（更新的）
遵守安全和隐私需求的百分比
八、发布后支持(PRSA1~5 )
8.1合理调整软件安全组
正确的组织定位
正确的人
正确的过程
8.2 PRSA1:外部漏洞披露响应
发布后的 PSIRT响应
发布后的隐私响应
优化发布后的第三方响应
8.3 PRSA2:第三方审查
1.提交源代码给第三方进行检查。对于那些想要保护他们源代码的软件开发组织来说，这不是一个真正的选择，他们视源代码为最宝贵的知识产权。
2.对于每一个新版本，与手动渗透测试服务合作，他们亦可以做深潜代码和软件架构设计评估。为了避免源代码脱离负责开发它的公司控制的风险，合约商必须按要求在受控环境的现场工作，遵守特殊的保密协议与具体的指导方针。这些通常包括源代码保护政策和知识产权保护的指导方针。对此的一种替换方法是雇用一个使用特定工具的公司，该工具仅仅需要披露二进制代码。在这种情况下，合约商像其受到攻击一样检查应用程序、二进制代码，并能确保检测到所有的威胁。这种类型的测试可以用于现场或者远程方式的服务。
3.购买、安装和培训开发团队使用内部部署的工具和功能，成为较低级的软件安全架构师，作为软件安全组的扩展来完成软件安全架构评估“人性化的一面”。然后邀请核算师进入你的组织以记录你的过程。许多成熟的软件安全组织已经这样做了。一个成熟的软件安全计划，如在本书中提到的，将有助于形成规模并减少做好这项工作需要的额外人力。把这个内置到你的SDL/SDLC过程中，是一个高性价比、高效和可管理的方式。
4.要求代码的第三方供应商在你的应用程序中做同样的操作。在当今的软件开发环境下，多数的软件开发组织利用在其他地方开发的代码，要么是商用现成产品(Commercial Off-The-Shelf,COTS),要么是开放源码的软件。就像使用内部开发的软件，第三方也应该依据每个软件应用程序所有者的要求准备一份鉴定报告。这份报告可能包括攻击面评估、.加密评估、架构风险分析、技术与特定的安全测试、二进制分析(如果源代码不可用)、源代码分析(如果源代码可用)，以及除了一般的笔测试程序外的模糊测试。
8.4 PRSA3:发布后认证
有许多关注安全的认证，一个软件开发团队可能会在产品发布后遇到这些认证。基于各种各样的原因，产品发布后认证的添加被视为一个需求，而不是在开发过程中。这些原因可能包括:设计和开发过程中未规划的工业或政府部门中的软件使用;刚开始使用该软件;新的政府、国家、区域、企业或工业部门，以及在软件发布之前未存在的监管要求。在软件开发之前未存在的发布后认证要求是一个可原谅的错误，但是缺少当前需要的任何认证并在SDL早期缺少认证都是不可饶恕的。为了避免正在开发的软件用法不兼容，需要公司的内部资源致力于遵从软件使用认证和其他方面的要求，包括隐私要求，也可以是个人或组织专门提供该领域的体验。随着这些类型的认证和要求的数量在全球范围内急剧增加，这将特别具有挑战性。以下是安全或隐私认证或者标准方面例子的一个简短清单，由于市场或用例的变化，符合发布后要求的软件产品可能会成为必然。
8.5 PRSA4:新产品组合或云部署的内部审查
在行业中，我们继续遇到误解，即一旦软件已经通过SDL，就可以以任何方式重新使用该软件的代码。但这个假设是错误的，因为软件产品发布后发生的任何体系结构变化将很可能给前面安全的代码引入新的攻击风险。由于这个原因，当发布后的代码有一个新使用的软件或体系架构变化时，软件代码必须再一次通过SDL过程。任何新的代码也必须通过前几章概述的各类安全性测试。
8.6 PRSA5:安全架构审查和基于工具评估当前、遗留以及并购的产品和解决方案
遗留代码
遗留软件中的技术负债可能包含安全漏洞。在开发项目的过程中，对于一个组织来说，很容易在软件质量和安全性方面变得松懈。最常见的是，当团队在一个给定的时间内预期完成过多的功能，或者质量和安全根本不考虑软件的高优先级特性时,会出现这样的结果。"5在这些情况下，在遗留代码中有可能存在安全漏洞，即技术负债的结果。从软件产品安全的角度看，查看遗留代码时主要的任务是权衡解决安全技术负债带来的投资回报和置之不理的危险。两个主要的决定必须要考虑:
1.你编写了多少SDL可能擦除的新代码以取代现有的旧代码?旧代码量将以什么速度被替换?剩下的代码面临的安全风险有哪些?
2.回顾旧代码是一个缓慢而乏味的过程。重要的投资回报决策必须做出。你必须保留这项工作的资源，以降低现有资源的技术安全负债。这项工作的工作量将取决于在代码开发过程中SDL是否存在。如果在遗留代码开发过程中没有SDL.工作量将会很高。
兼并和收购
为了保持竞争力，大多数公司要开发新产品，进入市场并寻求替代品，如兼并和收购( merger and acquistion, M&A)，这发生在当且仅当他们使用现有的资源无法做到这一点时。发生兼并和收购的原因有很多，但通常是渴望提高竞争力、盈利能力，或者公司及其产品的其他价值。在软件领域，这通常是在你的解决方案集或者产品本身中需要的功能。如果 M&A的主要重点是目标公司的软件，收购获得的人才将是一个加分项。当M&A开始被初步讨论时M&A活动宣布开始，经过详尽的调查阶段，并继续把目标公司及/或收购的技术整合到母公司中。在这个过程中的工作量和工作范围，将取决于工作的规模和复杂性。应该指出的是,M&A并不总是包括目标公司的所有资源。它们可能包括某一软件产品的代码，或者对于收购公司来说是有吸引力的和价值的多个技术或产品。
8.7成功的关键因素
外部漏洞信息披露响应过程
发布后认证
第三方安全审查
任何架构变化或者代码重用的SDL周期
遗留代码、M&A和EOL产品的安全策略和过程
8.8可交付成果
外部漏洞信息披露响应过程
发布后认证
第三方安全审查
任何架构变化或者代码重用的SDL周期
遗留代码、M&A和EOL产品的安全策略和过程
8.9度量标准
以下度量指标应该作为SDL该阶段的一部分：
应对外部披露的安全漏洞的时间(以小时为单位)
每月全职员工(Full-Time Employee, FTE)处理对外披露过程需要的小时数
产品发布后发现的安全问题的数目(按严重程度排列)
每月客户报告的安全问题数目
任意SDL活动中，客户报告的安全问题没有确定的数目
九、将SDL框架应用到现实世界中
9.1引言
软件安全依赖于一系列正确执行的任务。没有执行起来能够提供“足够”软件安全的“尚 方宝剑”式的任务。安全必须从开发生命周期的早期开始设计。同时每个寻找缺陷的活动都 是互补的。遗漏一个活动的同时其他活动仅仅为了补偿这个遗漏就需要付出很多。软件项目 之前的区别在于哪些任务提供最安全的投资回报；一些系统的一些活动都是无关紧要的。当 一些SDL安全任务的应用程序依赖于每一个项目特定的属性时，其他的SDL任务隐藏在安 全开发的核心当中。这些任务是开发软件的关键，这些软件可以被依赖而且也是自我保护的。 不管在什么情形下，该组核心活动适用于任何一个保持安全状态的软件项目。这些活动可以 应用到任何一个项目上。
9.2安全地构建软件
编写安全的代码
每个程序有(至少)两个目的:一个是程序要实现什么，另一个是程序不实现什么。
测试显示的是存在的bug，而不是不存在的bug。
当可接受的对象集，如文件名或URL，有限或已知时，创建了从一组固定的输入值（比如数字id)到实际文件名或URL 的一个映射，并拒绝所有其他输入。
在使用前，所有输入必须用Validator.*方法进行严格的白名单验证。
一对程序员在一起编程，他们不仅一起做测试用例，还一起投身到系统设计中去。变化并不局限于任何特定的区域。结对编程增加了系统分析、设计、实现、测试的价值。结对编程无处不在地增加了系统所需要的价值。
人工代码审查
静态分析
静态代码分析是运行一个自动化的工具的过程，它读取源代码或者源代码编译后产生的目标代码。静态代码分析工具通过预处理和错误检测功能来扫描代码正文。因为，正如已经指出的那样，计算机语言的表达能力就是我们所知的计算机科学世界的“重要”问题。静态分析，不仅要了解语言的合法性和语义(跟编译器的工作一样)，还必须了解典型的结构和这些结构下产生的错误与误用。此外，静态分析必须创建一个包含所有可能交互的图，以便于囊括有漏洞的交互。用一个有限的、简化的方式来描述现代代码静态分析技术就是:编译器可以发现代码里哪些是非法的，或者哪些是被禁用的。建立在合法性规则上的静态分析器能发现哪些是“不建议的”。再者，如果这个功能捆绑在一个工业级静态分析器上，它就过于简单了。
9.3确定每个项目的正确行为
七个确定性问题：
1.提出的变化是什么?(以下答案是互相排斥的;选择只有一个。
a.架构将是全新的或者是一个重大的重新设计。 b.架构有望改变。 c.安全特性或功能将添加到设计中。 d.如果必要,既不改变架构也不增加了安全功能(即,以上都不是)。
2.会添加一些第三方软件吗?是或否
3.会添加一些客户数据(个人识别信息[PII])?是或否
4.这个组织或其合作伙伴操作过其他系统吗?是或否
5.是否包含Web服务器?是或否
6.程序会有其他的输人吗?(即，非 Web输人、配置文件、网络监听器、命令行接口，等等)。是或否
7.这是一个主要版本吗?
9.4架构和设计
安全架构具有特定的特征：
安全架构都有自己的方法。这些方法可能是一个离散的安全方法的基础。
安全架构有自己的离散的看法和观点。
安全架构提出的非规范化流经过系统和应用程序。
安全架构经过系统和应用程序引入自己的规范流。
安全架构引入独特、专用组件的设计。
安全结构要求IT架构师具有独特的技能。[12]
9.5测试
功能测试
动态测试
网络扫描
模糊测试
攻击和渗透测试
独立测试
十、集成:应用 SDL防止现实的威胁
10.1战略、战术和特定于用户的软件攻击
理解：
(1)由个别网络支持的业务功能和流程
(2）网络之间的业务联系
(3)在承包商、供应商和目标实体之间共享战术攻击数据。对于这些业务关系的攻击所获取的信息用来指导和进行战略攻击。
战略攻击
战术攻击
特定于用户的攻击
10.2应用适当设计、管理和集中的SDL克服组织与业务挑战
我们概述了一个带有相关角色和责任的组织架构，这些角色和责任特定于在SDL模型里概述的任务，本书的作者已经实地检验和优化了这些任务。本书先前描述的结构能够有效地创建，实现和控制本书中的最佳范例，同时它也能够通过SDL模型中的A1 ～A5来实现成功的买进和任务的管理。使用提到的组织架构有个附加的好处，就是你能够实现在第8章提到的发布后支持任务，这些任务通常不是你自己完成的，而是由别的组织完成。通过使用在SDL模型的每一部分提到过的指标，你不仅能够有效地管理和跟踪你的软件安全方案，而且能为公司管理、内部客户和方案的当前状态提供仪表盘。这个仪表盘也能够用来识别职员总数、资金和其他资源的缺口。最重要的是，通过内置安全性，你能够在发布后最大限度地避免发现软件中的安全漏洞。在某些情况下，当它们发生时，同时也能增加你成功管理这些安全漏洞的能力。
10.3软件安全组织的现状和影响力
为相关的软件安全冠军提供集中的软件安全小组处理和管理。
指导在安全性架构和安全性审查中的软件安全冠军。
在每一条软件产品生产线的指导下支持相关业务组的软件安全冠军。
为早期和及时的安全需求协调产品管理。
帮助计算项目安全风险。
帮助保证软件安全冠军创立合适和完整的安全性测试。
保证合适的安全性测试工具(静态、动态、模糊）可用于SDL 中合适的地方。
10.4通过合理的政府管理克服SDL审计和法规挑战
第2章给出了ISO/IEC 27034的概述。除了书中提到的各种安全软件成熟度模型以外,这将是第一个软件安全标准。未来它将会有第三方认证并且认证行业将围绕它来组建。由于这个标准没有作为一个特定的国家安全标准定义应用程序，而是作为一个过程定义它，组织可以进行应用控制和测量，以管理使用的风险，我们相信我们的模型是符合本标准的。这个标准为把安全整合到管理应用程序的过程中提供了准则在详细说明、设计、开发、测试、实现和维护应用系统中的安全功能和控制过程中，需要一个明确的实现过程。ISO/IEC 27034里面特定的要求和过程并没有要求隔离实现，但是需要集成到一个组织现有的过程中。将ISO/IEC 27034 准则与SDL实践或者书中先前提到的成熟模型整合，将会让你自如地应对审计、监管或者管理的挑战，因为坚持规范将可能由后者驱动的指导来驱动。