策略与指标

1 级策略与指标

策略&与指标实践包含计划、分配职务和职责、确定软件安全目标、决定预算,以及确定指标和关卡。  

[SM1.1: 81] 发布流程并作必要完善。

向所有利益相关者通报处理软件安全的流程已经发布,以便所有人都知道相关计划。目标、角色、职责和活动得到明确界定。多数组织都会选择现有方法,例如 Microsoft SDL 或 Synopsys Touchpoints,然后再定制该方法来满足自己的需求。安全 SDLC 流程必须适应其管辖的开发流程(例如,瀑布、敏捷、CI/CD、DevOps 等)的细节,因为它会配合组织和安全布局进行完善。很多情况下,该过程都是由 SSG 控制并且仅在内部发布;不需要在公司外部公开宣传以产生预期的影响。除了发布流程外,一些公司还将其作为工作流编码到应用程序生命周期管理 (ALM) 工具中。

[SM1.2: 66] 设立传播职务并开展内部营销。

SSG 指定人员必须担任传播角色,以便在整个组织构建软件安全支持。这种内部营销职能有助于保持高管和其他利益相关者随时了解软件安全问题的重要性及其解决方案的要素。例如,熟悉安全流程的敏捷指导员可以帮助团队在转变为敏捷方法时采用更好的软件安全实践。传播人员会与包括高管在内的内部团队进行会谈,向知名专家发出邀请,为内部消费撰写白皮书,或者在内部网站上创建一系列文件、书籍和其他资源,并促进其使用,借此增进了解并建立信誉。早在 2002 年,比尔•盖茨的安全备忘录启动微软的新安全战略后不久,迈克尔•霍华德就在微软扮演了这样一个传播人员的角色。

[SM1.3: 73 教育高管。

定期向高管展示软件安全不足的后果及其可能给组织带来的负面业务影响。还要向他们展示别的企业怎样获得成熟的软件安全,包括如何处理未经监督就采用“当今特色”工程方法带来的风险。了解问题及其相关解决方案之后,高管就能支持将 SSI 作为风险管理的必要条件。最危险的方法是借助恶意黑客或公共数据泄漏事故的实例开展安全教育。SSG 最好在所有涉及因素均获许可的受控环境中(例如,通过如实展示遭到利用的情况及其业务影响)展示最坏的情况。某些情况下,向董事会演示有助于为正在开展的 SSI 争取资源。邀请外部大师通常有助于提升高管的关注度。将教育与移动或云服务等特定发展领域,或 CI/CD 和 DevOps 等特定方法联系在一起可能帮助说服领导层接受 SSG 建议,否则高管可能会偏好更快的发布时间或其他优先事项,而忽视这些建议。

[SM1.4: 107] 确定关卡的位置并收集必要工件。

软件安全流程包括 SDLC 中一个或多个点(或更可能是多个 SDLC)的发布关卡(或检查点、防护栏、里程碑等)。建立安全专用发布关卡的前两步是确定与现有开发实践兼容的关卡位置,然后开始收集决策所需意见,决定是继续还是停止。重要的是,这些关卡可能不会执行。例如,SSG 可以在发布之前为每个项目收集安全测试结果,然后提出审慎的意见,建议充分或合格的测试结果应该包含的内容,而不是试图阻止项目继续进行。在执行 CI/CD 的组织中看到的更短的发布周期往往需要创造性的方法来收集正确的证据,并严重依赖于轻量级,超快速的自动化。首先确定关卡,稍后再执行这一想法非常有助于推动软件安全的开发,而不会经历重大困难。将关卡推向社会,然后在大多数项目都知道如何成功时立刻打开关卡,这是一种循序渐进的方法,无需强制要求就能鼓励养成良好的习惯。

2 级策略与指标

[SM2.1: 49] 内部发布软件安全数据。

为了促进作出改善,SSG 在内部发布数据,介绍组织内的软件安全状态。这些信息可以采用面板的形式,为高管和软件开发管理人员提供度量标准。有时,这些发布内容并不会与公司的所有人员分享,而只是与相关高管分享,而他们随后就会在组织内推动做出改变。其他情况下,秉承公开是最好的预防措施这一理念,执行开放式管理并向全体利益相关者进行数据发布有助于让所有人了解工作进展。如果组织的文化提倡团体之间开展内部竞争,这些信息就能增添一个安全维度。与 CI/CD 相关联的时间压缩需要快速准确地进行测量,测量最初可能较少关注历史趋势(例如,每个版本的缺陷)而更多关注速度(例如修复时间)。

[SM2.2: 53] 通过测量执行关卡并追踪异常。

每个项目都执行了软件生命周期安全关卡,所以项目必须满足既定测量标准或取得豁免,才能通过一道关卡。现在,即便是顽固的项目团队也必须遵守规则,而且 SSG 也会跟踪例外情况。有时,关卡与法规、合同协议和其他义务直接相关,并且将会根据法定或监管推动机构要求跟踪异常。而有时,关卡的测量可产生用于管辖流程的关键性能指标。不经适当考虑就允许任何项目自动通过或自动授予豁免,违背了执行关卡的目的。即便是看似无害的软件项目(例如现有后端的新移动客户端,或从内部数据中心移植到云环境的应用程序),也必须顺利通过规定的安全关卡,才能继续。同样,API、框架、库、定制代码、微服务、容器配置等等都是必须通过安全关卡的软件。请记住,在开发过程之前和之后都可以执行关卡,而且关卡的执行通常非常有用。

[SM2.3: 52] 创建并培养卫星。

组建分布在整个组织中的一群人,他们在安全方面的兴趣或技能高于平均水平,被称为卫星。组建这群倡议者,有时也称拥护者,是朝着创建一个社交网络的方向迈出的一步,这个社交网络可以加速软件工程中安全性的采用。一种组建初始团队的方法就是在入门培训课程中发现表现突出的人员;参见 [T3.6 通过培训确定新的卫星人员]。另一种方法是招募志愿者。如果采用偏于自上而下的方法,则会指定最初的卫星成员,以确保全面覆盖所有开发/产品团队,但是卫星成员只有做出实际工作才能保留成员身份。强大的卫星团队是 SSI 成熟的典型标志。在新兴或快速发展的技术领域,卫星成员可以帮助将软件安全技能与可能在 SSG 中不具代表性的域知识结合起来。敏捷指导员和 DevOps 工程师是非常有帮助的卫星人员,在检测和消除流程冲突方面尤其有帮助。

[SM2.6: 51] 要求执行安全签核。

组织拥有在整个初始计划中执行的接受安全风险和记录问责的流程,带有风险接收者针对所有软件发布前状态的签核。例如,签核政策可能要求业务部门负责人签核尚未缓解的关键漏洞或已跳过的 SSDL 步骤。签核政策必须同时适用于外包项目(例如,精品店移动应用程序),以及要部署在外部环境中的项目(例如,云)。非正式或未经告知的风险接受本身并不是安全签核,因为接受风险的行为经过形式化(例如,签名、提交表单等等)并记录下来以备将来查阅时,会更为有效。同样,只是声明某些项目从不需要签核,无法取得预期的风险管理结果。然而在某些情况下,风险接受者可以签核一组特定的软件项目验收标准,然后在自动化中执行这些标准,以确保即使在最快的流程中也能适用这些标准;然而,必须不断进行验证,以确保标准保持准确且自动化切实可行。

3 级策略与指标

[SM3.1: 21] 使用具有组合视图的内部追踪应用程序。

SSG 使用集中式跟踪自动化来跟踪其各个软件(无论采用何种开发方法)在其范围内的进度。自动化会记录计划中、进行中和已完成的安全活动。它包含了架构分析、代码审查和安全测试等活动(即便它们发生在闭合环路中)的结果。综合的库存和风险状况视图是最基本的。SSG 利用自动化针对多个指标生成组合报告,并且在许多情况下,至少要向高管发布这些数据。这样会通过内部竞争产生有趣的效果,具体取决于公司文化。随着计划的逐渐成熟和活动的更加分散化,SSG 会使用集中式报告系统跟踪所有行动部分。

 

[SM3.2: 6] 运行内部营销项目。

为了引起外部注意,SSG 帮助公司向内部团队以外推销 SSI。通过这种方式,软件安全的作用逐渐超出了降低风险的范围,而成为竞争优势或市场亮点。SSG 可能会发布有关其软件安全功能的论文或书籍,或者开立一个公共博客。其中可能提供外部会议或商贸展览的详细信息。有时,可以通过移动设备、云和制作重要软件安全研究案例的新技术安全项目,在公司外部发布和推广完整的 SSDL 方法。无论在任何场所,对外分享细节并征求意见都可以为公司带来新的视角。

[SM3.3: 14] 确定指标并以此促进制定预算。

SSG 及其管理层会选择指标,以量化定义和测量 SSI 的进展。这些测量结果又反过来推动计划的预算和资源分配,因此简单的计数和脱离环境的测量在这里是不够的。其中一个指标可能会是缺陷密度,其降低即表示补救成本逐渐下降。回想在敏捷方法中,早期收集的指标是最好的,并且通常都采用轻量化方式收集。关键是通过明确而明显的方式将技术结果与业务目标联系起来,从而证明获得资金的合理性。因为安全概念对很多商业人士而言已微不足道,所以明确建立联系会有所帮助。

[SM3.4: 0] 集成软件定义的生命周期管理。

组织开始使用基于软件的交付平台替换传统的文档、演示文稿和基于电子表格的生命周期管理。人们(有时借助工具辅助)不再推动从各个生命周期阶段前进到下一阶段。相反,组织依靠自动化推动使用 ALM/ADLM 软件(如 Spinnaker)的管理和交付过程,而人员(通常是可选的)则会异步参与(如,提供维修服务)。自动化常常超出 CI/CD 的范围,涵盖交付的功能性和非功能性方面,包括健康检查、故障切换、回滚到已知的优质软件、缺陷发现和管理、合规验证,以及确保遵循政策和标准的方法。一些组织也在改进生命周期管理方法,通过整合他们的合规和缺陷发现数据,开始从一系列基于时间点确定继续还是停止的决策(例如,在每个关卡进行一次安全测试),转变为持续积累保证数据(例如,嵌入到开发和生产中的传感器输出)的未来状态。