降低软件漏洞风险(软件实践开发漏洞代码)

美国国家标准与技术研究院

2020年4月23日

写在前面：安全软件开发方面，以前所知的主要是微软的SDL，威胁建模、攻击平面等概念，OWASP 安全编码指南，再就是代码安全测试AST工具了。
和客户沟通时，也了解了客户的一些管理制度，流程要求等。
本文主要是最佳实践的总结和组合，更偏向于管理，很多客户都已经落实了其中的部分要求，只是没这么全面。

文中已定义了两类读者，如果让我补充一些的话，从一个产业工作者的角度，我觉得做软件开发管理，开发安全评估，开发安全咨询的厂商也可以参考此框架，细化文中内容，做一个SSDF模板，帮助用户规范开发流程中的安全行为。
这个模板虽然不属于行业合规要求，但由于其全面性，还是很有帮助和参考意义。
内容分成了组织准备，保护软件，生产安全软件，响应漏洞这四部分，逻辑是开发前准备、开发过程中、开发后需要注意的各个方面。

感谢陈能技老师推荐原文。

摘要

几乎没有软件开发生命周期（SDLC）模型在细节部分，明确地解决了软件安全问题，因此在SDCL模型中，常常需要添加安全软件开发实践，保证开发的软件安全可靠。
本白皮书推荐了一组核心的高水平安全软件开发实践，称之为安全软件开发框架（SSDF），并集成到每个SDLC实践中。
本文促进了组织内部业务所有者、软件开发者、项目管理者和领导、网络安全专家之间的关于安全软件开发实践的交流。
遵循这些实践，将有助于软件生产人员减少发布软件的漏洞数量，减轻利用未发现或未解决漏洞的潜在影响，并找到这些漏洞的根本原因，防止未来复现。
此外，框架提供了安全软件开发通用术语，软件消费者能使用它在购买流程及其他管理活动中和供货商沟通。

本文读者

这份白皮书有两类读者。
第一类是软件生产者（例如，商用现货产品供货商，政府现货产品软件开发人员，定制软件开发人员），不论规模、部门 、成熟度水平。
第二类是软件消费者，包括联邦政府机构和其他组织。
为了理解文档，读者并不要求是安全软件开发的专家，但实施推荐的实践，需要有安全软件开发方面的专业知识。

来自国家网络安全教育倡议（NICE）网络安全劳动力框架劳动力范畴和专业领域的个人，最有可能发现本文的好处：

正文

1 介绍

软件开发生命周期（SDLC）是一个正式或非正式的软件（包括植入硬件的代码）设计、生成和维护的方法。
有很多种SDLC模型，包括瀑布式、螺旋式、敏捷、开发和运维（DevOps）。
但几乎没有SDLC模型在细节上明确解决软件安全，因此，SDLC模型常常需要添加和集成安全软件开发实践。
不管使用哪种SDLC模型开发软件，有三个理由，需要集成安全软件开发实践：减少发布软件的漏洞，减轻未检测或未解决的软件漏洞的潜在影响，找到漏洞根本原因，阻止未来重复发生。
大多数安全问题可以在SDLC内的多个环节解决，但一般而言，在SDLC内，越早解决安全问题，最终实现同等安全水平所需的成本和工作量越低。
不管对于哪种SDLC，这个原则，也被称之为左移，都非常重要。

当前关于安全软件开发实践有很多资料，包括本文参考资料部分所列。
本白皮书没有引入新的实践或者定义新的术语；相反，它基于已有的标准、指南、安全软件开发实践文档，介绍了一个高水平实践的子集。
这些实践，统称为安全软件开发框架（Secure Software Development Framework，SSDF）。
对想实现安全软件开发目标的读者特别有帮助。
需要注意的是这些实践仅限于直接的安全软件开发（例如，保护开发框架或管道本身，超出了此范围）。

本文希望作为讨论安全软件开发框架概念的起点，因此，并没有提供安全软件开发框架的整体视图。
将来的工作也许扩展本文中的资料，可能包括安全软件开发框架（SSDF）在不同的软件开发方法中如何应用和变化，以及组织如何从当前软件开发方法过渡到SSDF中所包含的实践。
很可能未来的工作将以用户案例的形式，以便将包含的实践更容易应用到某种类型的开发环境中。

本文介绍了安全软件开发实践，但没有明确规定如何实现他们。
重点是部署这些实践，而不是用来实现的工具、技术和机制。
例如，一个组织也许实现了某些步骤自动化，其他也许使用人工流程。
在高的层面上指定这些实践的优点包括：

本文也提供了通用语言来描述基本的安全软件开发实践。
与提高关键基础设施网络安全框架（即NIST 网络安全框架）的方法类似。
理解本实践并不要求有安全软件开发的专业知识。
这有助于推动组织内部和外部参与者之间沟通安全软件实践。
包括如下述参与者：

本白皮书的实践，不是基于所有组织都有同样的安全目标和优先级的假设；相反，推荐反映了每个软件生产者也许有独特的安全假设，每个软件使用者也许有独特的安全需要和要求。
虽然我们的愿望是对每个软件生产者，遵循所有适用实践，期望每个实践实施的程度，和实施的形式根据生产者的安全假设不同而有变化，实践为实施者提供了灵活性，但也很明智地避免过多解释空间。

2 安全软件开发框架（SSDF)

本白皮书基于已有的安全软件开发实践文档，介绍了一个基本的、可靠和安全的软件开发实践的安全软件开发框架。
为了实现此白皮书的目的，实践被分成四组：

每个实践用下列元素来定义：

尽管大多数实践都与任何软件开发工作相关，一些实践也不总是适用的。
例如，如果开发一个特定软件，不涉及使用编译器，也就不需要遵循配置编译器提高可执行文件安全的实践。
有些实践更加基本，其他的更加高级，也许依赖一些已经实现的基本实践。
此外，在任何案例中，实践也不总是同等重要。
决定使用哪个实践，在每个实践上花费多少时间和资源都要考虑风险。
最后，没有指定执行重复实践的频率，因为，对任何特定情况，合适的频率取决于风险和其他因素。

下边是定义实践的列表。
记住，这些实践只是组织需要工作的一个子集，帮助组织实现安全软件开发的目标。
实践没有按重要性顺序列出。
由于空间问题，列表中所列信息有限，每个实践的更多信息，可见参考：

•BSIMM10: Building Security in Maturity Model (BSIMM) Version 10 [3]

在成熟度模型中打造安全

•BSA: BSA, Framework for Secure Software [4]

BSA，安全软件框架

•IDASOAR: Institute for Defense Analyses (IDA), State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation 2016 [5] 防御分析机构（IDA）

防御分析研究所，软件漏洞检测、测试、评估的最新资源

•ISO27034: International Organization for Standardization/International Electrotechnical Commission (ISO/IEC), Information technology – Security techniques – Application security – Part 1: Overview and concepts, ISO/IEC 27034-1:2011 [6]

国际标准化组织/国际电工委员会（ISO/IEC），信息技术-安全技术-应用安全-第一部分：概述和概念，ISO/IEC 27034-1:2011

•MSSDL: Microsoft, Security Development Lifecycle [7] 微软安全开发生命周期

•NISTCSF: NIST, Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1 [2]

NIST 关键基础设施安全改进框架 Version 1.1

•OWASPASVS: OWASP, OWASP Application Security Verification Standard 4.0 [8]

OWASP 应用安全验证标准4.0

•OWASPTEST: OWASP, OWASP Testing Guide 4.0 [9]

OWASP 测试指南4.0

•PCISSLRAP: Payment Card Industry (PCI) Security Standards Council,Secure Software Lifecycle (Secure SLC) Requirements and Assessment Procedures Version 1.0 [10]

支付卡行业安全标准委员会，安全软件生命周期要求和评估步骤 Version 1.0

•SAMM15: OWASP, Software Assurance Maturity Model Version 1.5 [11] OWASP，软件保证成熟度模型 Version 1.5

•SCAGILE: Software Assurance Forum for Excellence in Code (SAFECode),Practical Security Stories and Security Tasks for Agile Development Environments [12]

卓越代码软件保证论坛（SAFECode），

SAFECode，敏捷软件开发环境中，实用安全故事和安全任务

•SCFPSSD: SAFECode, Fundamental Practices for Secure Software Development: Essential Elements of a Secure Development Lifecycle Program, Third Edition [13]

SAFECode，安全软件开发基本实践：安全开发生命周期程序的基本元素，第三版

•SCSIC: SAFECode, Software Integrity Controls: An Assurance-Based Approach to Minimizing Risks in the Software Supply Chain [14]

SAFECode，软件完整性控制：基于保证的方法，最小化软件供应链风险，

•SCTPC: SAFECode, Managing Security Risks Inherent in the Use of Third-Party Components [15]

SAFECode，管理使用第三方组件内在的安全风险

•SCTTM: SAFECode, Tactical Threat Modeling[16] SAFECode，战术威胁建模

•SP80053: Joint Task Force Transformation Initiative, Security and Privacy Controls for Federal Information Systems and Organizations, NIST Special Publication (SP) 800-53 Revision 4 [17]

NIST SP80053 联邦信息系统和组织安全和隐私控制联合工作组转型倡议

•SP800160: NIST, Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems, NIST SP 800-160 Volume 1 [18]

NIST SP800160 系统安全工程：可信安全系统工程方法中多学科方法考虑

•SP800181: NIST, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST SP 800-181 [1]。

NIST SP800181国家网络安全教育倡议（NICE） 网络安全劳动力框架

组织准备（Prepare the Organization，PO）

实践

任务

实例用例

参考

定义软件开发安全需求（PO.1）：

在任何时间，保证软件开发的安全需求为大家所知，在整个SDLC流程中得到考虑，因为可以一次收集并共享需求信息，最小化重复工作。
包括内部来源（例如，组织策略、业务目标，风险管理战略）和外部来源（适用法律和法规）

PO.1.1针对组织通用软件开发，确定所有适用的安全需求，并随着时间进展，维护这些需求。

.定义组织软件要满足的安全需求的策略，包括开发人员遵循的安全编码实践。

.定义指定软件架构需求策略，例如生成代码模块，加速代码重用和容易更新，以及在代码执行时，从其他功能中隔离安全功能。

.定义保护开发基础设施的策略，如开发人员工作站和代码仓库。

.保证策略覆盖整个软件生命周期，包括提示用户软件支持时间和软件生命结束日期。

.使用一组众所周知的安全需求设置作为结构或定义组织需求的词汇表。
这个集合可以对应到组织也需遵守的第三方安全需求。

.每次漏洞事件响应之后，检查和更新需求。

.对所有安全需求，定期检查（至少每年一次）

.及时审查新的外部需求，更新现有的外部需求。

.就需求中将要发生的变化，对受影响的个人进行教育。

BSIMM10: CP1.1, CP1.3, SR1.1

BSA: SC.1-1, SC.2, PD.1-1, PD.1-2, PD.1-3, PD.2-2

ISO27034: 7.3.2

MSSDL: Practice 2

NISTCSF: ID.GV-3

OWASPTEST: Phase 2.1

PCISSLRAP: 2.1

SAMM15: PC1-A, PC1-B, PC2-A, SR1- A, SR1-B, SR2-B

SCFPSSD: Planning the Implementation and Deployment of Secure Development Practices; Establish Coding Standards and Conventions

SP80053: SA-15

SP800160: 3.1.2, 3.3.1, 3.4.2, 3.4.3

SP800181: T0414; K0003, K0039, K0044, K0157, K0168, K0177, K0211, K0260, K0261, K0262, K0524; S0010, S0357, S0368; A0033, A0123, A0151

实践

任务

实施用例

参考

实施角色和责任（PO.2）:保证组织内部和外部涉及到SDLC的每个人，准备履行他们和安全软件开发框架有关的角色和责任。

PO.2.1:生成新的角色和改变现有角色的责任，以包括SSDF所有部分。
定性检查已定义角色和责任，根据需求更新他们。

.针对软件开发团队所有成员，定义安全软件开发框架相关的角色和责任。

.在软件开发团队中加入安全角色。

.在SDLC中涉及到的所有角色：安全团队，安全冠军，项目管理者和领导，高级管理人员，软件开发人员，软件测试人员/质量保证人员，产品所有者，其他有关人员，定义他们的角色和责任。

.所有角色和责任，每年检察一次。

.角色和能力有变化时，教育受到影响的个人。

BSA: PD.2-1, PD.2-2

BSIMM10: CP3.2, SM1.1

NISTCSF: ID.AM-6, ID.GV-2

PCISSLRAP: 1.2

SCSIC: Vendor Software Development Integrity Controls

SP80053: SA-3

SP800160: 3.2.1, 3.2.4, 3.3.1

SP800181: K0233

PO.2.2:对软件安全开发有责任的个人，提供角色相关的培训。

定期检查特定角色的培训，根据需要进行更新。

.记录每个角色培训的预期成果。

.为每个角色制定培训计划。

.为每个角色购买或创建培训；购买的培训，也许需要根据组织要求定制。

BSA: PD.2-2

BSIMM10: CP2.5, SM1.3, T1.1, T1.5, T1.7, T2.6, T2.8, T3.2, T3.4

MSSDL: Practice 1

NISTCSF: PR.AT-

PCISSLRAP: 1.3

SAMM15: EG1-A, EG2-A

SCAGILE: Operational Security Tasks 14, 15; Tasks Requiring the Help of Security Experts 1

SCFPSSD: Planning the Implementation and Deployment of Secure Development Practices

SCSIC: Vendor Software Development Integrity Controls

SP80053: SA-8

SP800160: 3.2.4

SP800181: OV-TEA-001, OV-TEA-002; T0030, T0073, T0320; K0204, K0208, K0220, K0226, K0243, K0245, K0252; S0100, S0101; A0004, A0057

PO.2.3:安全开发得到上级管理层承诺，并将承诺传达给有关角色和责任。

.提高上级管理的意识

.协助上级管理层，将安全开发支持纳入到和SSDF相关角色责任沟通。

.教育所有相关人员，了解安全开发框架对组织的重要性和上级管理层对安全开发的承诺。

BSIMM10: SM1.2, SM1.3 PCISSLRAP: 1.1 SAMM15: SM1.A

SP 800-181: T0001, T0004

实践

任务

实施用例

参考

实施支持工具链（PO.3）:使用自动化减少所需人工，提高SDLC中安全实践的准确性、连续性和整体性，同时提供一种方法记录和演示这些实践的使用。
工具链和其他工具也许在组织的不同级别使用，如组织范围内或特定项目。

PO.3.1：指定每个工具链中包含哪些工具或工具类型，哪一个是强制的。
还有工具链组件互相如何集成。

.定义工具链类别，指定每个类别内强制使用的工具或工具类型。

.确定集成到开发人员工具链内的安全工具。

.使用自动化技术，管理和编排工具链。

BSA: TC.1, TC.1-1, TC.1-2

MSSDL:Practice 8

SCAGILE: Tasks Requiring the Help of Security Experts 9

SP80053: SA-15

SP800181:K0013, K0178

PO.3.2：遵循可靠的安全实践，部署和配置工具，把他们集成在工具链内，做为一个整体维护单个工具和工具链。

.评估、选择和购买工具，评估每个工具的安全性。

.把工具和其他工具及现有的软件开发流程和工作流集成。

.更新、升级和替换当前工具。

.监控工具和工具日志，发现潜在的操作和安全问题。

BSA: TC.1-1, TC.1-6

SCAGILE: Tasks Requiring the Help of Security Experts 9

SP80053: SA-15

SP800181: K0013, K0178

PO.3.3：配置工具收集支持安全软件开发实践的证据和工件。

.使用组织当前的工作流或问题追踪系统，生成所执行的安全开发相关行为的审计追踪。

.决定收集信息进行审计的频率，实施执行审计的流程。

BSA: PD.1.6

MSSDL: Practice 8

PCISSLRAP: 2.5

SCAGILE: Tasks Requiring the Help of Security Experts 9

SP80053: SA-15

SP800181: K0013

实践

任务

实施用例

参考

定义软件安全检查的标准（PO.4）：通过定义开发期间软件安全检查标准，帮助保证来自SDLC的软件成品，符合组织的期望。

PO.4.1:定义SDLC中，软件安全检查的标准。

.保证标准合适地指明，如何有效地管理安全风险。

.定义安全软件KPI

.在现有检查中增加软件安全标准（例如在敏捷SDCL方法中，“完成的定义”）。

.作为软件开发工作流系统的一部分，检查生成的工件，确定是否符合标准目标。

.记录安全检查批准、拒绝、例外请求，作为工作流和跟踪系统的一部分。

BSA: TV.2-1, TV.5-1

BSIMM10: SM1.4, SM2.2

ISO27034: 7.3.5

MSSDL: Practice 3

OWASPTEST: Phase 1.3

SAMM15: DR3-B, IR3-B, PC3-A, ST3-B

SP80053: SA-15

SP800160: 3.2.1, 3.2.5, 3.3.1

SP800181: K0153, K0165

PO.4.2:实施流程、机制等。
收集支持标准的必要信息。

.使用工具链，自动搜集通知安全决策的信息。

.如果需要，部署额外工具支持信息收集和生成，信息要支持标准。

.使用标准，自动化决策流程。

BSA: PD.1-6

BSIMM10: SM1.4, SM2.2

SP80053: SA-15

SP800160: 3.3.7

SP800181: T0349; K0153

保护软件（Protect Software，PS）

实践

任务

实施用例

参考

保护所有形式的代码，防止未授权访问到篡改(PS.1):帮助阻止未授权更改代码，不管是无意的还是有意的，它能否定和避开软件预期的安全特性。
对不希望公开访问的代码，有助于阻止软件被盗，使攻击者发现软件漏洞的难度加大或耗时变长。

PS.1.1:存储所有形式的代码，包括源代码和可执行代码，基于最小权限原则，保证只有授权人员拥有必要的访问形式。

.在代码仓库中存储所有源代码，根据代码特性，限制访问。
例如，有些代码也许用于公开访问，在这种情况下，应该保护完整性和可用性；其他代码也需要保密性保护。

.使用代码库版本控制功能，跟踪开发人员账户所有代码变化的责任。

.检查和批准代码所有更改。

.使用代码签名，帮助保护可执行文件的完整性和来源。

.使用加密（例如加密哈希值）保护文件完整性。

.对生成的每个软件包，创建和维护软件组成清单（SBOM）

BSA: IA.1, IA.2-2, SM.4-1

IDASOAR: Fact Sheet 25

NISTCSF: PR.AC-4 OWASPASVS: 1.10, 10.3.2, 14.2 PCISSLRAP: 6.1

SCSIC: Vendor Software Delivery Integrity Controls, Vendor Software Development Integrity Controls

提供验证软件版本完整性机制(PS.2):帮助软件消费者保证他们购买的软件是合法的，没有被篡改。

PS.2.1:向软件消费者提供验证信息

.在安全的网站上，发布软件文件的哈希值。

.使用已有CA，对代码做签名，消费者能证实签名的有效性。

.定期检查代码签名流程，包括证书更新和保护。

BSA: SM.4.2, SM.4.3, SM.5.1, SM.6.1

BSIMM10: SE2.4

NISTCSF: PR.DS-6

PCISSLRAP: 6.2

SAMM15: OE3-B

SCSIC: Vendor Software Delivery Integrity Controls

SP800181: K0178

存档和保护每个软件发布版本(PS.3):帮助确认、分析和消除软件发布之后发现的漏洞。

PS.3.1:安全归档每次发布版本和组件的拷贝（例如，代码、包文件、第三方库、文档），及其版本完整性验证信息。

.在软件库中存储所有文件，限制对他们的访问

BSA: PD.1-6

IDASOAR: Fact Sheet 25

NISTCSF: PR.IP-4

PCISSLRAP: 5.2, 6.2

SCSIC: Vendor Software Delivery Integrity Controls

SP80053: SA-15

生产安全软件（Produce Well-Secured Software，PW）

实践

任务

实施用例

参考

设计满足安全要求和减轻安全风险的软件（PW.1）:确定和评估软件设计适用的安全需求；弄清产品操作时，软件可能面对的安全风险，以及通过软件设计如何转移这些风险；任何基于风险的决策情况，说明应该放松或放弃安全需求。
在软件设计（设计保证安全）时解决安全需求，有助于让软件开发更高效。

PW.1.1:使用风险建模的方式，例如威胁建模、攻击建模、或攻击面映射，帮助评估软件的安全风险。

.培训开发团队（特别是安全冠军），或和威胁建模专家合作，生成威胁模型和攻击模型，分析如何使用基于风险方法解决风险和实施缓解措施。

.在高风险区域，执行更严格评估，如保护敏感数据和保护身份、认证和访问控制，包括凭证管理

.检查以前软件的漏洞报告和统计报告。

BSA: SC.1-3, SC.1-4

BSIMM10: AM1.3, AM1.5, AM2.1, AM2.2, AM2.5, AM2.6, AM2.7

IDASOAR: Fact Sheet 1

ISO27034: 7.3.3

MSSDL: Practice 4

NISTCSF: ID.RA-

OWASPASVS: 1.1.2, 1.2, 1.4, 1.6, 1.8, 1.9, 1.11, 2, 3, 4, 6, 8, 9, 11, 12, 13

OWASPTEST: Phase 2.4

PCISSLRAP: 3.2

SAMM15: DR1-A, TA1-A, TA1-B, TA3-B

SCAGILE: Tasks Requiring the Help of Security Experts 3

SCFPSSD: Threat Modeling

SCTTM: Entire guide

SP80053: SA-8, SA-15, SA-17

SP800160: 3.3.4, 3.4.5

SP800181: T0038, T0062, T0236; K0005, K0009, K0038, K0039, K0070, K0080, K0119, K0147, K0149, K0151, K0152, K0160, K0161, K0162, K0165, K0297, K0310, K034

实践

任务

实施用例

参考

检查软件设计，验证是否符合安全需求和风险信息（PW.2）:帮助确保软件符合安全需求，令人满意地解决已发现的风险信息。

PW.2.1：让不参与软件设计的有资格个人检查，证实符合所有安全需求，令人满意地解决发现的风险信息。

.检查软件设计，确认符合所有的安全需求

.检查软件设计时生成的风险模型，确定是否能够充分地识别风险

.检查软件设计，证实是否满意地解决了风险模型识别的风险。

.让软件设计者纠正错误，符合需求。

.如果安全需求得不到满足，改变设计和/或风险响应战略。

BSA: TV.3, TV.3-1, TV.5

BSIMM10: AA1.2, AA2.1

ISO27034: 7.3.3

OWASPTEST: Phase 2.2

SAMM15: DR1-A, DR1-B

SP800181: T0328; K0038, K0039, K0070, K0080, K0119, K0152, K0153, K0161, K0165, K0172, K0297; S0006, S0009, S0022, S0036, S0141, S0171

实践

任务

实施用例

参考

验证第三方软件符合安全需求(PW.3):降低使用购买软件模块和服务的风险，可能是潜在的漏洞源。

PW.3.1:和可能给组织提供软件模块和服务的第三方沟通需求，供组织自己的软件重用。

.定义一套核心的安全需求，包含在采购文件、软件合同、和第三方其他协议中。

.定义选择商用和开源软件与安全有关的标准。

.要求商用软件和服务的提供商提供他们产品和服务符合组织的安全要求的证据。

.当第三方软件模块和服务不符合安全需求时，建立和遵循解决风险的步骤。

BSA: SM.1, SM.2, SM.2-1, SM.2.4BSIMM10: CP2.4, SR2.5, SR3.2

IDASOAR: Fact Sheets 19, 21

MSSDL: Practice 7

SAMM15: SR3-ASCFPSSD: Manage Security Risk

Inherent in the Use of Third-Party ComponentsSCSIC: Vendor Sourcing Integrity Controls

SP80053: SA-4, SA-12

SP800160: 3.1.1, 3.1.2

SP800181: T0203, T0415; K0039; S0374; A0056, A0161

PW.3.2：使用合适的方式验证商业、开源、所有第三方软件模块和服务符合要求。

.查看在软件中，是否有公开已知、厂家还未修复的漏洞。

.保证每个软件和模块仍然得到主动维护，应该包括正在修复的软件发现新的漏洞。

.对不再维护或未来不可用的第三方软件和服务制定行动计划。

.使用商用服务的结果，仔细检查软件模块和服务。

.[参考检查和/或分析人工可读代码，发现漏洞，验证符合安全需求（PW.7）]

.[参考测试可执行代码，发现漏洞，验证符合安全需求（PW.8）]

BSA: SC.3-1, TV.2

IDASOAR: Fact Sheet 21

MSSDL: Practice 7

OWASPASVS: 10, 14.2

PCISSLRAP: 4.1

SCAGILE: Tasks Requiring the Help of Security Experts 8

SCFPSSD: Manage Security Risk Inherent in the Use of Third-Party Components

SCSIC: Vendor Sourcing Integrity Controls

SCTPC: 3.2.2

SP80053: SA-12

SP800160: 3.1.2, 3.3.8

SP800181: SP-DEV-002; K0153, K0266

[See (PW.7)]

[See (PW.8)]

实践

任务

实施用例

参考

可行情况下，复用已有的、安全的软件，而不是复制功能（PW.4）:降低软件开发成本，加快软件开发，减少引入其他漏洞的可能性。
这些对包含安全功能的软件尤其正确，例如加密模块和协议。

PW.4.1:从第三方购买安全可靠的组件（例如软件库、模块、中间件、框架）供组织软件使用。

.根据第三方软件的预估用途，对其检查和评估。
如果在将来以截然不同的方式使用，记住在新环境中再次检查和评估。

.建立整个组织范围内的软件库，存储经过批准和仔细检查的开源组件。

.维护组织批准的商用软件组件及版本清单。

.在将要开发的软件中，指定必须包含的组件。

BSA: SM.2, SM.2.1

IDASOAR: Fact Sheet 19

MSSDL: Practice 6

SAMM15: SA1-A

SCTPC: 3.2.1

SP80053: SA-12

SP800181: K0039

PW.4.2:第三方组件无法满足需求时，根据SDLC流程，生成良好保护的软件组件，符合常见的内部软件开发需求。

.遵循组织建立好的安全实践。

.对这些组件，维护组织范围内的软件库。

. 在将要开发的软件中，指定必须包含的组件。

BSIMM10: SFD1.1, SFD2.1

IDASOAR: Fact Sheet 19

OWASPASVS: 10

SP800181: SP-DEV-001

PW.4.3:合适情况，支持使用标准化安全功能和服务（例如，集成日志管理、身份管理、访问控制和漏洞管理系统）而不是生成专有的安全功能和服务。

.维护整个组织范围内软件模块库，支持标准化安全功能和服务。

. 在将要开发的软件中，指定必须包含的组件。

BSA: SI.2, EN.1-1, LO.1

MSSDL: Practice 5

OWASPASVS: 1.1.6

SCFPSSD: Establish Log Requirements and Audit Practices

实践

任务

实施用例

参考

遵循安全编码实践生成源代码(PW.5):降低软件中安全漏洞的数量，减少源代码生成时的漏洞来降低成本。

PW.5.1:根据开发语言和环境，遵循所有安全编码实践。

.验证所有输入，验证和正确编码输出。

.避免使用不安全函数和调用。

.得体地处理错误

.提供日志和跟踪功能。

.使用鼓励或要求使用安全编码实践的开发环境。

.遵循步骤，人工保证遵循安全编码实践。

.检查常见的开发语言和环境其他漏洞。

BSA: SC.2, SC.4, SC.3, SC.3-2, EE.1, EE.1.2, EE.2, LO.1,

IDASOAR: Fact Sheet 2

ISO27034: 7.3.5

MSSDL: Practice 9

OWASPASVS: 1.5, 1.7, 5, 7,

SCFPSSD: Establish Log Requirements and Audit Practices, Handle Data Safely, Handle Errors, Use Safe Functions Only

SP800181: SP-DEV-001; T0013, T0077, T0176; K0009, K0016, K0039, K0070, K0140, K0624; S0019, S0060, S0149, S0172, S0266; A0036, A0047

PW.5.2:开发人员检查他们自己人工可读代码，分析他们自己人工可读代码，和/或测试他们自己可执行代码，补充（而不是替代）其他人执行的代码检查、分析和测试。

.[参考检查和/或分析人工可读代码，发现漏洞，验证符合安全需求（PW.7）]

.[参考测试可执行代码，发现漏洞，验证符合安全需（PW.8）]

[see （PW.7）]

[see（PW.8）]

实践

任务

实施用例

参考

配置编写和构建过程，提升可执行文件安全（PW.6）：减少软件中安全漏洞的数量，测试之前消除漏洞来降低成本。

PW.6.1：使用能够提高可执行文件安全的编译器和构建工具。

.使用最新的编译器和构建工具

.验证编译器和构建工具的完整性和可用性。

BSA: TC.1-1, TC.1-3, TC.1-4, TC.1-5

MSSDL: Practice 8

SCAGILE: Operational Security Task 3

SCFPSSD: Use Current Compiler and Toolchain Versions and Secure Compiler Options

SCSIC: Vendor Software Development Integrity Controls

PW.6.2：决定使用哪个编译器和构建工具功能，如何配置，对编写和构建工具、流程实施经过批准的配置。

.启用编译器功能，对编码过程中低水平安全编码报警。

.实施“干净构建”概念，所有编译器报警都被认为是错误并需要消除。

.提供编译器随机化功能，例如内存寻址，否则很容易被预测并利用。

.执行测试，保证功能按照预期执行，不会轻易引起操作或其他问题。

.验证已批准的配置用于编辑、构建工具和流程。

.在开发人员能够访问和搜索的知识库中，记录编辑和构建工具配置信息。

BSA: TC.1, TC.1-3, TC.1-4, TC.1-5 OWASPASVS: 1.14.3, 1.14.4, 14.1

SCAGILE: Operational Security Task 8

SCFPSSD: Use Current Compiler and Toolchain Versions and Secure Compiler Options

SCSIC: Vendor Software Development Integrity Controls

SP800181: K0039, K0070

实践

任务

实施用例

参考

检查和分析人工可读代码，发现漏洞，验证对安全需求的符合性(PW.7):帮助发现漏洞，在软件发布之前得到修改，防止受到攻击。
使用自动化方法降低检测漏洞所需工作量和资源。
人工可读代码，包括源代码和任何其他形式代码。

PW.7.1:决定是否使用代码检查（个人直接查看代码，发现问题）和/或代码分析（使用工具发现问题，完全自动化方法或和人力配合）。

.当代码检查应该执行或如何执行时，遵循组织策略或指南。
这包括第三方代码和组织内部可重用代码模块。

.遵循组织策略或指南，何时执行代码分析或如何执行。

SCSIC: Peer Reviews and Security Testing

SP80053: SA-11

SP800181: SP-DEV-002; K0013, K0039, K0070, K0153, K0165; S0174

PW.7.2:基于组织的安全编码标准，执行代码检查或代码分析。
在开发团队的工作流或问题跟踪系统中，分类问题，推荐修复。

.执行代码同行检查，检查已有的代码，查看、分析或测试结果。

.使用同行检查，检查代码后门和其他恶意内容。

.使用同行检查工具，加速过程，记录所有讨论和反馈。

.使用静态分析工具，自动检查代码漏洞和组织安全编码要求的符合性，有必要的话及时修复。

.使用检查清单，验证代码符合要求。

.当人工可读代码进入代码库时，持续使用自动化工具发现和修复验证过的不安全软件实践。

.发现和记录每次发现问题的根本原因。

.在开发人员可以访问和搜索的知识库中记录代码检查和分析中学习到的经验。

BSA: PD.1-5, TV.2, TV.3

BSIMM10: CR1.2, CR1.4, CR1.6, CR2.6, CR2.7

IDASOAR: Fact Sheets 3, 4, 5, 14, 15, 48

ISO27034: 7.3.6

MSSDL: Practices 9, 10

OWASPASVS: 1.1.7, 10

OWASPTEST: Phase 3.2, Phase 4.1

PCISSLRAP: 4.1

SAMM15: IR1-B, IR2-A, IR2-B

SCAGILE: Operational Security Tasks 4, 7

SCFPSSD: Use Code Analysis Tools to Find Security Issues Early, Use Static Analysis Security Testing Tools, Perform Manual Verification of Security Features/Mitigations

SCSIC: Peer Reviews and SecurityT esting

SP80053: SA-11, SA-15

SP800181: SP-DEV-001, SP-DEV-002; T0013, T0111, T0176, T0267, T0516; K0009, K0039, K0070, K0140, K0624; S0019, S0060, S0078, S0137, S0149, S0167, S0174, S0242, S0266; A0007, A0015, A0036, A0044, A0047

实践

任务

实施用例

参考

测试可执行代码，发现漏洞和验证安全需求的符合性（PW.8）:帮助发现漏洞，在软件发布之前得到纠正，防止利用。
使用自动化方法降低检测漏洞的工作量和资源。
可执行代码包括二进制，直接执行字节码，直接执行源代码，组织认为可执行的任何其他形式代码。

PW.8.1:决定是否应该执行可执行代码测试，如果是，使用哪种类型。

.何时执行代码测试以及该如何执行，遵循组织的策略和指南。
包括第三方可执行代码和组织自己编写的可复用执行代码及第三方可执行代码。

BSA: TV.3

SCSIC: Peer Reviews and SecurityT esting

SP80053: SA-11

SP800181: SP-DEV-001, SP-DEV-002; T0456; K0013, K0039, K0070, K0153, K0165, K0342, K0367, K0536, K0624; S0001, S0015, S0026, S0061, S0083, S0112, S0135

PW.8.2:设计测试，执行测试，记录结果。

.执行安全功能健壮性测试。

.在项目自动化测试套装中，集成动态漏洞测试。

.在项目自动化测试套装中，包括测试以前报告过的漏洞，保证问题没有被重复引入。

.使用自动化模糊测试工具，发现输入处理中的问题。

.如果有资源，使用渗透测试模拟高风险场景中，攻击者攻击软件。

确定和记录每次发现问题的根本原因。

.在开发人员能够访问和搜索的知识库中，记录代码测试学习到的经验。

BSA: PD.1-5, TV.3, TV.5, TV.5-2

BSIMM10: PT1.1, PT1.2, PT1.3, ST1.1,

ST1.3, ST2.1, ST2.4, ST2.5, ST2.6, ST3.3, ST3.4

IDASOAR: Fact Sheets 7, 8, 10, 11, 38, 39, 43, 44, 48, 55, 56, 57

ISO27034: 7.3.6

MSSDL: Practice 11

PCISSLRAP: 4.1

SAMM15: ST1-B, ST2-A, ST2-B

SCAGILE: Operational Security Tasks 10, 11; Tasks Requiring the Help of Security Experts 4, 6, 7

SCFPSSD: Perform Dynamic Analysis Security Testing, Fuzz Parsers, Network Vulnerability Scanning, Perform Automated Functional Testing of Security Features/Mitigations, Perform Penetration Testing

SCSIC: Peer Reviews and Security T esting

SP80053: SA-11, SA-15

SP800181: SP-DEV-001, SP-DEV-002; T0013, T0028, T0169, T0176, T0253, T0266, T0456, T0516; K0009, K0039, K0070, K0272, K0339, K0342, K0362, K0536, K0624; S0001, S0015, S0046, S0051, S0078, S0081, S0083, S0135, S0137, S0167, S0242; A0015

实践

任务

实施用例

参考

将软件设置为缺省的安全设置(PW.9)：帮助提高软件安装时候的安全性，减少软件由于较弱安全设置，导致更大的风险的可能性。

PW.9.1:决定如何配置每个对安全有影响的设置，保证缺省的设置安全，不会减弱平台、网络基础设施和服务提供的安全功能。

.执行测试，保证设置，包括缺省设置，按照预期工作，不会无意地导致安全弱点，操作问题或其他问题。

BSA: CF.1, TC.1

IDASOAR: Fact Sheet 23

ISO27034: 7.3.5

OWASPTEST: Phase 4.2

SCAGILE: Tasks Requiring the Help of Security Experts 12

SCSIC: Vendor Software Delivery Integrity Controls, Vendor Software Development Integrity Controls

SP800181: SP-DEV-002; K0009, K0039, K0073, K0153, K0165, K0275, K0531; S0167

PW.9.2:实施缺省的设置（可行的话，缺省的设置组）记录软件管理员的每个设置。

.验证批准的软件配置是否就位

.记录每个设置的目的、缺省值、安全相关性、潜在操作影响，和其他设置的关系。

.记录软件管理员如何实施每个设置。

IDASOAR: Fact Sheet 23

OWASPTEST: Phase 4.2

PCISSLRAP: 8.1, 8.2

SCAGILE: Tasks Requiring the Help of Security Experts 12

SCFPSSD: Verify Secure Configurations and Use of Platfor

响应漏洞 （Respond to Vulnerabilities，RV）

实践

任务

实施用例

参考

在持续的基础上，发现和证实漏洞(RV.1):确保更快的识别漏洞，以便更快的纠正他们，减少攻击者的机会窗口。

RV.1.1:从客户和公开源收集软件和软件使用任何第三方组件中漏洞信息，调查所有可信报告。

.建立漏洞响应程序，方便安全专家很容易了解你的程序，报告可能的漏洞。

.通过手动或自动的方式监控漏洞数据库、安全邮件清单、其他漏洞报告数据源。

.使用威胁情报源，更好的理解常见漏洞是如何被利用的

BSA: VM.1-3, VM.3

BSIMM10: CMVM1.2, CMVM3.4

PCISSLRAP: 3.4, 4.1, 9.1

SAMM15: IM1-A

SCAGILE: Operational Security Task 5

SCTPC: 3.2.4

SP800181: K0009, K0038, K0040, K0070, K0161, K0362; S0078

RV.1.2:检查、分析，和/或测试软件代码，发现或确认以前未检测到的漏洞。

.配置工具链，定期执行自动化代码分析和测试。

.[参考检查和/或分析人工可读代码，发现漏洞，验证和安全符合需求（PW.7）]

.[参考测试可执行代码，发现漏洞，验证和安全符合需求（PW.8）]

BSA: VM.1-2

ISO27034: 7.3.6

PCISSLRAP: 3.4, 4.1

SP800181: SP-DEV-002; K0009, K0039, K0153

[See (PW.7)]

[See (PW.8)]

RV.1.3:具有团队和流程处理漏洞报告和事件的响应。

.制定策略解决漏洞暴露和修复，实施必要的流程支持策略。

.已有安全响应手册，处理常见报告的漏洞，零日报告，被利用的漏洞，涉及到多方的主要持续事件。

BSA: VM.1-1, VM.2, VM.2-3

MSSDL: Practice 12

SAMM15: IM1-B, IM2-A, IM2-B

SCFPSSD: Vulnerability Response and Disclosure

SP800160: 3.3.8

SP800181: K0041, K0042, K0151, K0292, K0317; S0054; A0025

实践

任务

实施用例

参考

评估、确定优先级和修复漏洞(RV.2):帮助保证漏洞尽快被修复，减少攻击者的机会窗口。

RV.2.1:分析每个漏洞，收集足够的信息，计划它的修复。

.使用问题追踪软件（有的话使用现有软件）记录每个漏洞。

.估计需要多少工作量修复漏洞。

.估计漏洞被利用的潜在影响。

.如果还没有实现，估计武器化漏洞需要的资源。

.估计计划漏洞修复的其他相关因素。

BSA: VM.2, VM.2-1, VM.2-2

PCISSLRAP: 4.2

SCAGILE: Tasks Requiring the Help of Security Experts 10

SP80053: SA-10

SP800160: 3.3.8

SP800181: K0009, K0039, K0070, K0161, K0165; S0078

RV.2.2:对每个漏洞开发实施和修复计划。

.对每个漏洞，做出基于风险的决策，是否需要修复还是通过其他其他方式解决（例如，风险接受和风险转移）。

.每个需要修复的漏洞，决定修复优先级。

.如果漏洞没有永久解决手段，如何在长期方案出来之前暂时缓解，并将暂时修复措施加入到计划中。

BSA: VM.1-1, VM.2-3, VM.2-4

PCISSLRAP: 4.1, 4.2

SCAGILE: Operational Security Task 2

SCFPSSD: Fix the Vulnerability, Identify Mitigating Factors or Workarounds

SP800181: T0163, T0229, T0264; K0009, K0070

实践

任务

实施用例

参考

分析漏洞，确定根本原因(RV.3):有助于减少未来漏洞的频率。

RV.3.1:分析所有发现的漏洞，确定每个漏洞的根本原因。

.记录每个发现问题的根本原因。

.在开发人员可访问和搜索的知识库中，记录从根本原因分析中得到的教训。

BSA: VM.2-1

PCISSLRAP: 4.2

SAMM15: IM3-A

SP800181: T0047, K0009, K0039, K0070, K0343

RV.3.2:分析根本原因随着时间的变化，确定特征，例如当特定安全编码实践没有持续得到遵循。

.在开发人员可访问和搜索的知识库中，记录从根本原因分析中得到的教训。

.增加工具链自动化检测将来类似例子的机制。

BSA: VM.2-1, PD.1-3

MSSDLPG52: Phase Two: Design

PCISSLRAP: 4.2

SP800160: 3.3.8

SP800181: T0111, K0009, K0039, K0070, K0343

RV.3.3:根据报告问题的其他实例，检查软件，主动修复，而不是等待外部报告。

.[参考检查和/或分析人工可读代码，发现漏洞，验证符合安全需求（PW.7）]

.[参考生成符合安全编码实践的源代码（PW.5）]

BSA: VM.2

PCISSLRAP: 4.2

SP800181: SP-DEV-001, SP-DEV-002; K0009, K0039, K0070

RV.3.4:检查SDLC流程，根据需要更新，阻止（或减少可能性）类似原因再发生。

.在开发人员可访问和搜索的知识库中，记录从根本原因分析中得到的教训。

.规划和实施合适的软件安全开发框架实践变更。

BSA: PD.1-3

BSIMM10: CMVM3.2

MSSDL: Practice 2

PCISSLRAP: 2.6, 4.2

SP800181: K0009, K0039, K0070

（完）

本文转载自：安全行者老霍

原文链接：https://mp.weixin.qq.com/s/osdf3hZ-UW7TdtFcjS-dGw

如有侵权，请联系我们第一时间处理~