标准和要求

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

1 级标准和要求

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

软件安全要求远远多于安全功能,但安全功能也是工作中的一部分。SSG 创建标准,解释遵守政策和开展以安全为中心的操作时采用的公认方式,满足组织的安全指导需求。一项标准可能描述如何执行 Android 设备的认证或如何判定软件更新的真实性(参见 [SFD1.1 构建并发布安全功能],了解 SSG 提供安全标准参考实施方式的一个案例)。通常,不是应用程序的软件必须具备自己的标准。标准可以通过各种方式进行部署。有时,标准和指南可在开发环境中实现自动化(例如,加入 IDE 中),而有时,指南可明确关联代码示例,甚至关联容器,加强其可执行性和相关性。没有获得广泛采用和完善的标准就不是真正的标准。

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

组织拥有众所周知的中心位置,可提供软件安全信息。通常这会是 SSG 维护的一个内部网站,人们可以通过网站了解最新和最好的安全标准和要求,以及 SSG 提供的其他资源(如培训)。一个交互式维基 (wiki) 要比一个有着鲜少变更的指导文件的静态门户更实用。组织可以采用邮件列表和面对面会谈补充这些资料。

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

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

2 级标准和要求

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

组织创建了一个标准审查委员会,实现标准制定流程正规化,并确保所有利益相关者都有机会参与。可以指定任何拟议标准的拥护者来运作审查委员会。该拥护者有义务证明标准符合目标要求,并且获得审查委员会批准和采纳。企业架构师或企业风险团队有时承担创建和管理标准审查委员会的职责。

[SR2.3: 23] 为技术栈创建标准。

组织针对特定技术栈实施了标准化。对于 SSG,这意味着工作负荷的降低,因为团队不需要针对每一个新项目探索新的技术风险。理想的情况是,组织为每个技术栈创建安全基础配置,进一步降低安全使用技术栈所需的工作量。技术栈可能包含一个操作系统、一个数据库、一个应用程序服务器和一个托管语言的运行时环境。安全边界是寻找附着点的好地方。目前,移动技术栈和平台以及基于云的技术栈是特别关注安全的领域。  

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

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

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

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

3 级标准和要求

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

组织可以控制其使用开源组件及其依赖群体相关的漏洞。使用开源可以将使用限制在预定义的项目,或已经通过 SSG 安全筛选流程、修复了不可接受的漏洞,并且只能通过内部存储库提供的开源版本中。由于与 GPL 代码相关的“病毒”许可证问题,法务部门通常会施加额外的开源控制。通常,让法务部门了解安全风险可以帮助组织改进其开源实践。当然,这一控制必须应用于整个软件组合。

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

SSG 为供应商提供培训,推广组织的安全标准。仅仅依靠合同语言无法保障与供应商的健康关系。SSG 与供应商进行交流,与供应商讨论安全实践,并采用朴实的措辞(而非法律术语)说明组织对其供应商的期望。只要是供应商采纳组织的安全标准,就是一次明确的胜利。与公开 SSDL 的公司针对软件安全预期进行沟通会容易一些。同样,分享内部实践和测量指标可以使预期更加明确。如果供应商的安全政策水平低于贵公司,请勿与其合作。

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

安全编码标准可帮助开发人员避免最为明显的漏洞并为代码审查提供基本规则。安全编码标准必须是特定于编程语言或平台的,并且可以提出使用热门框架和库,但移动平台要有自己的特定编码标准。如果组织已有其他用途的编码标准,则应当基于此类标准构建安全编码标准。一套明确的安全编码标准是指导人工和自动代码审查的好方法,同时还可以通过相关示例加强安全培训。请记住,指南不可作为标准。