2.1.3 SAFE Code
软件保障卓越代码论坛（SAFECode）是一个非营利性、全球性、行业主导的组织，致力于通过推进有效的软件保障方法。SAFECode的使命是推广开发和提供更安全、更可靠的软件、硬件和服务的最佳实践。SAFECode组织发布了“安全软件开发的基本实践：安全开发生命周期计划的基本要素”指南，以促进整个行业的发展采用基本的安全开发实践。基本实践涉及保证-软件抵御试图利用设计或实现错误的攻击的能力。其指南中概述的八项基本做法如下所述：
1. 应用程序安全控制定义。SAFECode使用术语应用程序安全控制（ASC）来指代安全要求（请参阅第2.1.1节第2点）。同样，NIST 800-53使用短语安全控制来指代安全功能和安全保证要求。
ASC的输入包括以下内容：安全设计原则（见第2.1.3节第3点）;安全编码实践;应用程序需要遵守的法律和行业要求（例如HIPAA、PCI、GDPR或SCADA）;内部政策和标准;事件和其他反馈;威胁和风险。ASC的开发在设计阶段之前就开始了，并贯穿整个生命周期，以提供清晰和可操作的控制，并响应不断变化的业务需求和不断变化的威胁环境。
2. 设计。软件必须包含安全功能，以符合内部安全实践和外部法律或法规。此外，软件必须根据操作环境抵御已知威胁。（请参阅第2.1.1节第5点。威胁建模（请参阅第2.1.1节第4点）、架构评审和设计评审可用于在将设计缺陷实施到源代码之前识别和解决设计缺陷。
系统设计应包含加密策略（请参阅第2.1.1节第6点），以保护敏感数据在静态或传输过程中免遭意外泄露或更改。
系统设计应使用标准化的身份和访问管理方法来执行身份验证和授权。标准化提供了组件之间的一致性，并就如何验证是否存在适当的控制提供了明确的指导。验证主体（无论是人类用户、其他服务还是逻辑组件）的身份并验证执行操作的授权是系统的基本控制。已经开发了几种访问控制方案来支持授权：强制性、自由裁量权、基于角色或基于属性。这些都有优点和缺点，应根据项目特征进行选择。
日志文件在发生违规时提供取证分析所需的证据，以减轻否认威胁。在设计良好的应用程序中，系统和安全日志文件提供了了解应用程序行为及其随时使用方式的能力，并区分善意的用户行为和恶意用户行为。由于日志记录会影响可用的系统资源，因此日志记录系统应设计为捕获关键信息，同时不捕获过多数据。需要围绕存储、防篡改和监控日志文件建立策略和控制。OWASP为设计和实施日志记录提供了宝贵的资源1415.
3. 安全编码实践。意外的代码级漏洞是由程序错误引入的。这些类型的错误可以通过使用编码标准来预防和检测;选择最合适（和安全）的语言、框架和库，包括使用它们相关的安全功能（见第8节）;使用自动分析工具（见第2.1.1节项目符号9和10）;以及手动审查代码。
组织为安全编码提供标准和指南，例如：
(a)OWASP安全编码实践，快速参考指南
(b) OracleSecure Coding Guidelinesfor Java SE
(c)软件工程研究所（SEI）CERT安全编码标准
还必须特别注意通过记录事件的通用错误处理程序或异常处理程序以受控和优雅的方式处理意外错误。如果调用泛型处理程序，则应将应用程序视为处于不安全状态，以便不再将进一步执行视为受信任。
4. 管理使用第三方组件时固有的安全风险。见第2.1.1节第7点。
5. 测试和验证。见第2.1.1节第9-11点和第2.1.2节第1、3和4点。
6. 管理安全发现。前五个实践生成的工件包含或生成与产品安全性（或缺乏安全性）相关的发现。应跟踪这些工件中的发现，并采取措施修复漏洞，例如通用准则（请参阅第4.3节）缺陷修复程序中列出的漏洞[36].或者，当确定风险可接受时，团队可能会有意识地接受安全风险。必须跟踪风险的接受情况，包括严重性等级;补救计划、到期或重新审查截止日期;以及重新审查/验证的区域。
明确严重性定义对于确保所有参与者对安全问题及其潜在影响有一致的理解非常重要。可能的起点是映射到通用漏洞评分系统（CVSS）19使用的严重性级别、属性和阈值，例如10–8.5表示严重，8.4–7.0表示高等。严重性级别用于根据缓解措施的利用复杂性和对系统属性的影响来确定缓解措施的优先级。
7. 漏洞响应和披露。即使遵循安全的软件生命周期，由于不断变化的威胁，没有产品可以“完全安全”。漏洞将被利用，软件最终将受到损害。组织必须制定漏洞响应和披露流程，以帮助推动解决外部发现的漏洞，并让所有利益相关者了解进度。ISO为漏洞消除和处理提供了经过行业验证的标准20。为了防止漏洞在新产品或更新的产品中再次出现，团队应执行根本原因分析，并将经验教训反馈到安全软件生命周期实践中。有关进一步讨论，请参阅第2.1.1节第12点和2.1.2项目符号7。
8. 规划安全开发的实现和部署。一个健康和成熟的安全开发生命周期包括上述七种实践，但也包括将这些实践集成到业务流程和整个组织中，包括项目管理、利益相关者管理、部署规划、气象和指标，以及持续改进的计划。在规划部署安全软件生命周期时，需要考虑组织的文化、专业知识和技能水平。根据过去的历史，组织可能会更好地响应公司任务、自下而上的风浪方法或一系列试点计划。将需要培训（见第2.1.1节第1点）。应记录组织安全软件生命周期的规范，包括角色和职责。应制定合规性和过程运行状况计划（请参阅第4节）。
2.2 比较安全软件生命周期模型
2009年，德温等.比较了CLASP、Microsoft最初记录的SDL[3]和接触点（参见第2.1.2节），以便就它们的共性提供指导以及方法的具体性，并提出改进建议。作者将每个生命周期模型的153种可能活动映射到六个软件开发阶段：教育和意识;项目启动;分析和需求;架构和详细设计;实施和测试;以及发布、部署和支持。这些活动将第2.1.1–2.1.3节中的做法提升到更精细的粒度。作者指出了每个模型是否包括153个活动中的每一个，并就每个模型的优缺点提供了指导。作者发现模型中没有明确的全面“赢家”，因此从业者可以考虑使用指南来获得所有模型中所需的细粒度实践。
表1将第2.1.1-2.1.3节的实践分为DeWin等人使用的六个软件开发阶段。与之前的工作类似，这些模型在六个软件开发阶段的指导方面展示了优势和劣势。没有任何模型可以被认为是适用于所有情况的完美模型。安全专家可以考虑六个软件开发阶段实践的传播情况，为其组织定制模型。
