标准和要求

标准 &要求实践涉及向组织征求明确的安全要求、确定推荐哪种 COTS、针对主要安全控制措施(如认证、输入验证等)建立标准、为在用技术创建安全标准,以及创建标准审查委员会。

1 级标准和要求

[SR1.1: 83] 创建安全标准。

SSG 创建标准,解释遵守政策和开展以安全为中心的操作时采用的公认方式,满足组织的安全指导需求。一项标准可能描述如何执行 Android 设备的认证或如何判定软件更新的真实性,通过 SSG 提供安全标准参考实施方式。通常,非应用程序的软件需要有自己的标准(例如,API 或微服务架构)。标准可以通过多种方式部署,才能保持可操作性和相关性。可以将标准自动部署到开发环境中(例如,部署到 IDE 或工具链中),或者可以显式链接到代码示例甚至容器中。在任何情况下,只有予以执行的标准才会被视为标准。

[SR1.2: 81] 创建安全门户。

组织拥有众所周知的中心位置,可提供软件安全信息。通常这会是 SSG 维护的一个内部网站,人们可以通过网站了解最新和最好的安全标准和要求,以及 SSG 提供的其他资源(如培训)。一个交互式维基 (wiki) 要比一个有着鲜少变更的指导文件的静态门户更实用。组织可以采用邮件列表和面对面会谈补充这些资料。开发团队越来越多地将软件安全知识直接放到组织外部的工具链和自动化中(例如,GitHub),但这并没有消除对 SSG 领导的知识管理的需求。

[SR1.3: 85] 将符合性约束条件转化为要求。

针对各个项目,将符合性约束条件转化为软件要求。这是组织符合性策略的关键:将符合性约束及其要求明确地表示出来,表明符合性成为可管理的任务。例如,如果组织定期构建处理信用卡交易的软件,PCI DSS 合规性可以在 SSDL 需求阶段发挥作用。在其他情况下,为实现国际互操作性而构建的技术标准可以包括满足合规需求的安全指导。将这些标准呈现为要求还有助于促进审核时的可追溯性和可见性。将可重复使用的代码或容器规范的要求进行编码尤其有用。

2 级标准和要求

[SR2.2: 52] 创建标准审查委员会。

组织创建了一个审查委员会,实现标准制定流程正规化,并确保所有利益相关者都有机会参与。可以指定任何拟议标准的拥护者来运作该标准审查委员会。该拥护者有义务证明标准符合目标要求,并且获得审查委员会批准和采纳。企业架构师或企业风险团队有时承担创建和管理标准审查委员会的职责。当这些标准直接作为软件实现时,负责的拥护者可能是 DevOps 经理、发布工程师,或者拥有相关容器或服务注册中心的任何人。

[SR2.4: 46] 确定开源。

需确定并审查软件组合中包含的开源组件,以真正理解它们的依赖关系。发现具有已知漏洞的旧版组件或同一组件的多个版本并不罕见。用于查找开源代码的自动化工具,无论是整个组件还是大量的借用代码,都是执行此活动的一种方法。一次非正式的年度审查或仅仅依靠开发人员申请许可的流程不会产生令人满意的结果。

[SR2.5: 35] 创建 SLA 样板。

SSG 与法务部门合作,创建一个标准的 SLA 样板,用于与供应商和外包供应商(包括云提供商)订立合同,以要求提供软件安全保障工作。法律部门了解,样板还有助于防止发生合规性和隐私问题。根据协议,供应商和外包提供商必须符合公司强制执行的软件安全标准(参见 [CP2.4 在所有供应商合同中加入软件安全 SLA])。样板语言可能需要对软件安全工作(如 BSIMMsc 测量结果或 BSIMM 评分)进行客观的第三方详细审查。

3 级标准和要求

[SR3.1: 22] 控制开源风险。

组织可以控制其使用开源组件及其所有相关依赖关系的漏洞。可以将开源的使用限制在预定义的项目中,也可以限制在已经通过 SSG 安全筛选流程、修复了不可接受的漏洞、并且只能通过特定的内部存储库和容器提供的一小部分开源版本中。有时,政策可能会阻止任何开源的使用。由于与 GPL 代码相关的“病毒”许可证问题,法务部门通常会施加额外的开源控制。通常,让法务部门了解安全风险可以帮助组织改进其开源风险管理实践,而这些实践必须应用于整个软件组合才能有效。

[SR3.2: 11] 向供应商传达标准。

SSG 为供应商提供培训,推广组织的安全标准。然而,仅通过合同语言并不能保证与供应商维持健康的关系,因此 SSG 应该与供应商接洽,讨论供应商安全实践,并以具体的术语(而不是法律术语)解释组织对供应商的期望。只要是供应商采纳组织的安全标准,就是进步的明确标志。与公开 SSDL 的公司针对软件安全预期进行沟通会容易一些。同样,分享内部实践和测量指标可以使预期更加明确。

[SR3.3: 9] 使用安全编码标准。

安全编码标准可帮助组织的开发人员避免最为明显的漏洞并为代码审查提供基本规则。此类标准必须特定于编程语言或平台,并且可以提出使用热门框架和库。平台可能包括移动或 IoT 运行时、云服务提供商 API 和 SaaS 平台(例如,Salesforce、SAP)。如果组织已有其他用途的编码标准,则应当基于此类标准构建其安全编码标准。一套明确的安全编码标准是指导人工和自动代码审查的好方法,同时还可以提供相关的安全培训示例。一些团队可能选择将他们的安全编码标准直接集成到自动化中,但他们仍然必须将违反这些标准的情况视为需要修复的缺陷。请记住,如果安全编码标准不是特定的和强制的,就不会有效。

[SR3.4: 24] 为技术栈创建标准。

组织针对特定技术栈实施了标准化。对于 SSG,这意味着工作负荷的降低,因为团队不需要针对每一个新项目探索新的技术风险。理想的情况是,组织为每个技术栈创建安全基础配置,进一步降低安全使用技术栈所需的工作量。技术栈可能包含一个操作系统、一个数据库、一个应用程序服务器和一个运行时环境(例如,LAMP 栈)。在其他情况下,堆栈可能是应用服务器和开发框架包(例如 MEAN),甚至可能是云环境中的第 1 层到第 6 层(例如,功能即服务)。安全边界是寻找附着点的好地方;移动技术栈和平台、IoT 设备和基于云的技术栈是特别注重安全性的领域。基于容器的方法可以使标准化更具可扩展性(参见 [SE3.4 使用应用程序容器])。