相信关注软件安全的人,对 BSIMM(软件安全构建成熟度模型)都不会陌生。
从 2008 年第一版开始,BSIMM 的版本迭代就一直由新思科技 (Synopsys) 和 BSIMM 社区双方协力完成。其中,新思科技主要负责企业的调研、数据采集工作;BSIMM 社区则基于 BSIMM 首版形成的软件安全框架 (SSF)和企业打分情况,对 BSIMM 活动进行更新,并从行业视角,形成对软件安全计划 (SSI) 实施情况的最新洞见。
2019 年 10 月,BSIMM 模型的第十个版本(中文报告)正式发布。新思科技软件质量与安全部门的高级安全架构师杨国梁在新思科技北京的办公区,对 BSIMM10 做了详细的介绍和解读。
从 BSIMM8 开始,安全牛就有对 BSIMM 的更新进行跟踪报道。作为参会媒体中为数不多的信息安全专业媒体,从安全角度(而不是开发角度),我们能看到些不一样的内容。因此,此篇着重介绍的不是 BSIMM10 的更新内容,而是 BSIMM 模型之于软件安全工作推行的意义和思路。
BSIMM 是一种描述模型。企业通过参与 BSIMM 的评估,不仅可以更加具体的了解自身 SSI 的执行情况,还可以从行业视角明确所处的具体位置。
也就是说,BISMM 模型,是一把衡量企业在软件开发阶段构建软件安全能力的标尺。
BSIMM10 使用的评估框架 SSF 内容上涵盖四个大域(分别为治理、情报、SSDL 触点和部署),对应 12 个实践模块,包含 119 项活动。
BSIMM10-SSF
作为一种描述性模型,BSIMM 唯一的目标就是观察和报告。据统计,在过去的十年间,总计有 185 家企业参与过 BSIMM 的评估。其中有 50 家企业开展了至少 2 次评估,21 家开展了 3 次,8 家开展了 4 次,2 家开展了 5 次,评估次数总计 450 次。
因为每年 BSIMM 模型评估框架,都会根据参与企业情况适时进行 “活动” 的更新 (例如 BSIMM10 就新增了集成软件生命周期管理、监控自动资产创建和自动验证运营基础架构的安全性,三项活动),以保证 BSIMM 模型的评估结果不会滞后于行业对最佳 SSI 实践的认知。而且如果连续超过 36 个月没有参与,企业之前的评估结果也不再被 BSIMM 社区承认。所以,持续参与的积极意义是非常明显的。对于企业 SSG(软件安全小组)负责人而言,BSIMM 的评估结果是其向高层阐述 SSI 实施效果、汇报工作的重要工具;从供应链安全角度,虽然不能把 BSIMM 作为一个认证或是 PR 指标来对待,但其可以在一定程度证明该供应商对软件开发安全的重视和实践程度。
此次 BSIMM10 的评估,有 122 家公司参与。相较于 BSIMM9 的 120 家企业,此次 BSIMM10 的 122 家企业是通过剔除 17 家,增加 19 家形成的。基于 119 项活动相对频率,可以经常观察到的定义为 “第1级”,不能经常观察到的为 “第3级”,形成各家企业 BSIMM10 评估的记分卡。最终基于样本总集,形成此次评估的观察结果。
当然,评估结果包含趋势洞见,也有严格数据驱动的的 “蛛网图”(对应 12 个实践模块的均值)。其中,“蛛网图”还会从垂直视角(如:云计算、物联网、高科技、金融服务、医疗保健、保险、零售等)将122家企业按照所属行业拆分成不同子集,给出子集的均值。企业不仅可以明确在所有122家企业样本总集的相对位置,也可以获知在所属行业的位置。虽然处于隐私保护,企业无法知道其它企业的具体情况,但对于SSG工作的评估,以及后续工作的开展,都是有指导性的。
蛛网图-9个垂直行业数据
新思科技首席科学家 Sammy Migues 表示,领导一个有效的软件安全计划是富有挑战性的,而 DevOps 和 CI/CD 带来的巨大技术和组织变革并没有使这项任务变得更加容易。而 BSIMM 以及其社区,无论是企业的软件安全工作处于哪一位置,都会是宝贵的资源。
能够辅助高层对 SSI 实施情况进行评价,是企业愿意进行 BSIMM 评估的重要驱动力。所以帮助明确企业 SSI 的现状,确定有效的发展方向,是 BSIMM 的重要价值所在。
此次 BSIMM10,对于软件安全工作的一个重要价值,就在于首次明确定义了 SSI 的三个阶段——兴起、发展和优化。
报告认为,无论企业文化如何,企业在建立并完善企业SSI的过程中,通常都会经历这三个阶段。在“兴起”阶段,企业往往被迫从头启动新的 SSI,或将之前临时的软件安全活动变为整体策略。这个全新的 SSI 将包括初始策略、基础活动、人员和预算等受限资源,以及 12 至 24 个月的发展路线图。但在开展后续工作时,处于 “兴起” 阶段的 SSI 可能会迫于合规或其它高管要求,而不断添加新的活动。
“兴起” 之后是 “发展” 阶段。在这个阶段,企业已经拥有了软件安全方法,但管理层希望进一步管理软件安全风险,并沿着 SSI 路线图扩充新的功能。所以在不断完善的过程中,SSI 的领导者可能会一边继续提高现有活动的深度、广度和成本效益,一边减少新添加的活动数量。
第三个阶段是 “优化” 阶段。在这个阶段,企业希望可以优化并发展现有的安全能力,明确运营目标和相关指标,是安全能够适应技术变化并为业务赋能。SSI 领导者也可能会经历从技术主管到业务推动者的变化。
经验表明,企业 SSI 是否能达到 “发展” 阶段是取决于开展软件安全活动的适宜性,而非总数量,尤其在需要发展或优化的活动相对复杂时,尤为明显。此外,这三个阶段也不是完全按照时间顺序演进的,而是会出现数次经历相同的阶段,或是 SSI 的功能可能不会同时发展到相同状态。
此外,企业自身文化是确定 SSI 演进的方法、工具和方式的考虑因素。
BSIMM 社区一直有两种截然不同的文化并存,一是由高层自上而下推动,专注于合规、测评和风险管理。这在银行、保险、医疗保健等强监管行业是较为常见的。另一种,是由工程部门发起,但企业会创建高层的管理机构,创建和管理开发过程的安全标准。这种文化常见于高新技术企业,或独立软件供应商。但无论是哪种,几乎所有SSI都是治理导向的,核心都是通过开展主动开展软件安全活动降低相应风险。但对于开发、测试和运营团队,治理导向的SSI更多是麻烦。
BSIMM10 的另一个重要意义,是反应了工程导向的安全文化新浪潮。
迫于现代软件交付的需求和压力,敏捷开发、持续集成/持续交付、DevOps 等实践,正在影响企业实现软件安全的方式。工程师更加重视自动化而不是人力驱动的任务。这也就意味着,所有软件安全工作自开展时,经常不会考虑来自 SSG 的经验或教训。
治理导向的 SSI 通常是自上而下,进行积极、主动的风险管理,而且要求 “必须遵守既定规则”;但工程导向(往往是经验丰富的开发、运维人员)则更注重在关键路径上创建代码,或在基础架构层面实现安全功能。
为了能够跟上软件开发流程和技术架构的变化,BSIMM10 中提出,工程导向的安全文化正在区别与上述两种而独立演进。相对治理导向,工程导向的最大不同在于:倾向于将安全性视为软件功能和代码质量的保障工具(即安全性是质量的一个方面),并使用自己下载、集成的安全工具。他们认为制定安全标准是必要的,但在执行层面却倾向“治理即代码”而非人工审查的手动操作。这意味着,工程师往往可以将安全功能和框架构建到软件架构中,并在交付前像处理其它缺陷一样处理安全风险。而治理驱动的 SSI,则是根据高管的指示来更改策略、标准和流程,所以经常需要追赶工程师团队的脚步。
工程主导的新型实施方式,其优势在于可以很快看到收益,但劣势也很明显,就是依赖个人贡献,而且难以将持久收益制度化。
当然,这种文化的兴起,也只是在 BSIMM10 中首次被提及。后续,可能会看到更成熟工程导向的案例,以及在同一企业内部和治理导向SSI的融合。但这种新兴的软件安全的实践方式,不应被忽视。
从 BSIMM 模型及社区自身来看,其评估框架以及给出的结果,对企业评估自身的软件安全实践、判断行业所处位置、以及明确软件安全工作的可能的趋势和思路,都具有丰富、实际的借鉴意义。同时,结合新思科技(连续多年位于 Gartner 应用安全性测试领域的领导者象限)在软件质量与安全的积累,以及其对中文软件安全社区的重视(连续多个版本提供经过专业校对的完整中文报告),相信BSIMM会为更多企业的软件安全工作,提供实质性的帮助与支持。
www.bsimm.com/zh-cn/download.html