目前，国外广泛采用的是NIST SP800-64 标准《信息安全开发生命周期中的安全考虑指南》。该《指南》介绍了把安全纳入信息系统开发生命周期的所有阶段(从初始阶段到最终处理阶段)的框架。引用NIST SP800-64 的《指南》作为参考， SDLC 基本上可分为6 个主要阶段，各阶段的安全措施与步骤如图7-11 所示。

相比信息系统的安全问题而言，实施和部署系统的成本收益问题才是信息系统管理层所希望关注和了解的，并且也是容易理解的问题。在考虑成本时，针对的对象包括整体过程和具体措施两部分。整体过程具体措施可以细化为每一项安全控制或者安全解决方案，通过对安全控制或者安全解决方案进行成本收益分析。
一般而言，管理人员和安全专家将一起采用成本收益分析方法，将实施和部署新系统及配套的其他培训等措施所需的技入作为成本，采取了这种安全措施后所产生的对信息系统业务目标的支持及带来的收益和减少的风险损失等作为收益进行综合考虑，以实现信息系统实施的业务和成本吕标。由于对人员的安全培训是贯穿于SDLC 始终的，因此安全培训也不仅限于某一所段，也不能完全归类为安全控制。所谓的目标应是符合成
本效益的保证，以满足组织保护其信息资产的需求。无论处于何种情况，在从系统安全
中得到的任务性能的收益与运行系统所产生的风险之间应该有一个平衡。
除了实施和部署系统需要考虑成本平衡问题之外，在SDLC 的整个过程中也需要考虑成本平衡问题。整个SDLC 的成本，包括实现成本和使用期间的管理成本，这些都必须考虑。这就存在一个平衡，例如，采购阶段增加了成本要在系统运行时节约成本。在安全方面的替代架构和技术也应该予以考虑。
安全开发包括两部分内容，分别是控制开发和安全编码。
安全控制是为了应对风险。在开发安全控制中选择和使用安全技术时，也应基于"目标一策略一机制/手段"的分析顺序，先了解具体的安全需求和目标需求所应对的风险，然后选择应对风险的策略，再选择适当的安全控制手段，包括所需的具体安全技术。应对风险的策略可分为承受风险、规避风险、转移风险和限制风险4 种。当选定了具体应对风险的策略后，再选择适当的安全控制手鼓，包括技术性、操作性和管理性的机制和手段来具体实施。在最终确定所选择的安全控制手段之前，还需要理解每一种控制的目标、应用领域，以及所需的配套性技术性控制、管理性措施等。在"设计阶段"的"安全控制开发"步骤中也包括了"安全解决方案"的确定和实施。在确定和实施"安全解决方案"时，要确保构成"安全解决方案"的所有安全控制彼此之间不存在严重冲突，同时也要进行成本考虑。
当安全规划和安全控制决定之后，就可以开始具体的系统安全编码工作了。安全编码是开发阶段里需要主要关注的环节。开发一个薪版本软件的过程需要有效的安全控制。安全控制必须在部署新版软件之前进行测试和评估，来保证控制系统正常和有效地工作。在信息系统中的所有模块都必须执行并遵守安全测试的内容，在测试结束阶段须输出各模块的安全测试执行报告。
实施部署是SDLC 的第4 阶段，在这一阶段中，信息系统将要安装在操作环境中并对它进行检查评估。检查与验收是指信息系统方对信息系统安装进行检查，然后对验收并交割付款这一过程做出决定。由信息系统或者独立的审定与核查的第二方来做检测，以判断这一系统是否满足规格要求。
检查和验收的主要内容包括系统安装和系统相关文挡检查。这一阶段是在系统正式发布之后，由信息系统或者可信第三方来检查。因此，系统制造方人员并不会参与本阶段的检查验收工作，但需要捏针对检查与验收的检查表提前准备好，同时要全程记录该阶段的情况，最终输出检查与验收结果报告。
系统集成在将要部署信息系统的业务现场出现。集成和验收测试在系统的交付和安装后开始。系统集成的检查人员包括信息系统或可信第二方人员，以及开发方人员。
在最终系统部署之前，作为系统开发过程中的一部分的安全认证应该被实施，以此来确定安全控制己经按照安全需求建立了。此外，在信息系统中，必须对安全控制进行定期测试和评估，以此来确认这些安全控制实施是否有效。除了安全控制有效性以外，安全认证也揭露并描述了信息系统真实的脆弱程度。
安全认证将自信息系统或者可信第三方的安全专家进行，主要包括以下内容:安全功能需求认证、安全保障需求认证、安全级别认证。这一阶段是在产品进行系统集成之后，由客户或者可信第三方来检查的。因此，产品制造方人员并不会参与本阶段的认证工作，但需要把针对认证的检查表提前准备好，同时要全程记录该阶段的情况，最终输出安全认证结果报告。
安全评审是在产品己基本完成且将要交付给信息系统方时，由安全评审团队进行的从安全和隐私等角度进行的最终评估审核活动。该环节应在产品开发、测试都己结束后进行，进行安全评审后的系统才能正式发布。安全评审团队不能是项目组的技术人员和管理人员，应该自信息系统的安全专家和质量监督专家组成。安全评审包括以下内容:安全功能需求评审、安全保障需求评审、威胁模型评审、未修复的安全bug 评审、残余风险评审、各阶段文档评审、评审异常处理。本步骤将输出安全评审结果报告，报告将包括上述内容。安全评审结果报告将作为产品是否能正式发布的依据之一。
运行维护是SDLC 的第5 阶段。在这一阶段，信息系统到位并开始运行，对这个已经开发或者测试过的系统进行改进或者修理，以及对硬件或软件的补充或更换。当修复或者更改被确定是必需时，信息系统也许会重新进入SDLC 的下一个阶段。管理信息系统的配置、进行持续性监视，并提供安全响应是在这一阶段里的关键性安全步骤。
配置管理与控制一般由信息系统或者可信第三方人员负责，信息系统的制造方人员只需实时提供各种技术支持即可，因此，本步骤无须安全相关检查项目。
持续性监视一般由信息系统或者可信第二方人员负责，信息系统的制造方人员只需实时提供各种技术支持即可，因此，本步骤无须安全相关检查项目。
安全响应是指，在信息系统实际运行中出现漏洞时，由信息系统制造方人员及时提供响应等技术修复和改进的持续性活动。安全响应主爱由信息系统项目的开发人员、测试人员、专门的客户联络代表、信息系统项自安全专家等组成，主要包括以下步骤:漏洞报告、漏洞分析及处理、补丁发布及更新、漏洞记录及追踪。每进行一次安全响应活动都必须输出漏桐分析及处理结果报告和漏洞记录及追踪报告。
最终处理阶段是SDLC 的最后一个盼段，规定了系统的处理。信息系统方一般会选择自己的工作人员来操作和维护系统。通常， SDLC 并没有一个最终的结束点。系统演变或者转型到下一代作为需求变更或者技术改进的一个结果。一般而言，系统的所有者应该对关键信息进行存档，对存储信息的媒介进行消毒，然后再处理软硬件。
信息存储一般由信息系统自身负责，信息系统制造方人员只需实时提供各种技术支持即可。信息处理一般由信息系统自身负责，信息系统制造方人员只需实时提供各种技术支持即可。硬件和软件可以按照所规定的适用法律或法规卖掉、送出或者丢弃。软件的处理应该遵守许可的或者其他的与开发商所达成的协议，并遵守政府法规。
软件处理时，系统开发方应派出专门的安全专家与信息系统共同处理，以确保信息系统的版权获得有效保护。本步骤主要包括以下内容:软件备份检查和软件代码检查。本阶段要求输出软件处理结果报告。