应用安全的十二个最低参照基准

应用程序安全方法论和最佳实践已经有十多年的历史，其中“安全开发成熟度模型”(BSIMM)是被企业采用多年，用来跟踪安全开发成熟度进度的重要模型。

[[345157]]

上周，Synopsys发布了基于BSIMM11模型的报告，对基于金融服务、软件、云计算和医疗等9个垂直行业的130家公司的软件安全实践进行了分析，揭示了以下四个应用安全趋势：

• 工程导向的软件安全性工作正在成功地推动DevOps价值流追求弹性;
• 软件定义的安全治理不再只是抱负;
• 安全性正在成为质量实践的一部分，而质量实践则被视为可靠性的一部分，而这一切都是为了追求弹性;
• “左移”正变成“无处不在”。

BSIMM11模型将121种不同的软件安全性指标归纳为四个主要领域：治理、情报、安全软件开发生命周期(SSDL)接触点和部署，企业可通过模型的专有标准对软件安全实践进行衡量。上述每个领域都可进一步细分为三个实践类别，其中包含从简单到非常成熟的众多活动。

与先前的报告类似，BSIMM11分析显示，大多数企业都达到了基本要求，包括执行外部渗透测试以及在整个开发过程中进行基本软件安全培训之类的活动。

以下，是BSIMM11报告中企业安全开发实践中最常见的十二项活动(上图)，可以作为企业保持行业安全同步的最低参照基准：

治理：策略和指标

活动：实施生命周期治理

组织中最常见的基础活动之一是实施生命周期治理，其中包括发布条件，例如入口、检查点、围栏和里程碑。根据BSIMM11，有90%的组织已实施生命周期治理。而且许多组织正走得更远，并且也执行治理策略。例如，47%的组织还通过度量和跟踪异常来验证发布条件。

治理：合规与政策

活动：确定PII(个人身份信息)义务

大约86%的组织可通过明确其对个人身份信息(PII)的义务来满足法规要求。这是最常见的合规性活动，同时，有72%的组织能在所有监管标准中统一其观点和实践。BSIMM11表明，随着时间的推移，组织也将通过履行其义务来逐步提高其合规能力。在过去两年中，积极在其应用程序组合中建立受保护的PII存储库的企业的数量已增加了10个百分点，达到42%。同样，在同一时间范围内，实施和跟踪合规控制措施的组织所占比例从36%上升到47%。

治理：培训

活动：进行安全意识培训

在组织范围内进行某种形式的安全意识培训已成为企业应用开发组织的行业规范，但即便如此仍然有很多企业未能遵守。据BSIMM11称，只有大约64%的企业对其软件相关人员进行了至少一个安全意识入门课程的培训，即使这些课程是针对特定受众量身定制。同时，针对特定角色的安全意识培训已经很常见，但还尚未成为主流，只有29%的组织从事此活动。

情报：攻击模型

活动：创建数据分类方案和清单

当今，大多数软件组织在威胁建模、开发滥用案例以及攻击者思维方面的成熟度还很低。据BSIMM11报告，只有63%以上的组织能够做到这方面的最低要求，即通过创建数据分类方案和清单，根据存储的数据和对攻击者的吸引力来优先考虑应用程序的重要性或风险级别。同时，只有8%的组织建立了与潜在攻击者相关的攻击模式和滥用案例，在过去几年中，这一比例一直保持稳定。

情报：安全功能和设计

活动：集成并提供安全功能

为了满足安全性可重复的需求，许多组织接受了提供主动指导和代码以提供预先批准的安全性功能的实践，这些安全性功能包括以模块方式提供的功能，例如身份验证、角色管理和加密。这样，开发人员不必每次在项目中添加这些标准功能时重新发明车轮。根据BSIMM11，大约78%的组织参与了此应用安全活动。在安全功能和设计方面，仍有很大的发展空间。例如，尽管许多组织向开发团队提供这些功能资源，但只有11%强制要求使用规定列表或存储库中的批准的安全功能和框架。

情报：标准和要求

活动：将合规性约束转换为需求

认识到开发人员不是法规遵从专家(这也不是他们的本职工作)，当今许多安全组织正在承担将诸如PCI DSS标准之类的内容解释为软件需求的重任。根据BSIMM11，今天大约有72%的组织在这样做。将近72%的组织创建了安全标准，以解释从基于身份的身份验证到如何配置开发人员基础结构的所有事务遵守企业策略的必需方法。

SSDL接触点：架构分析

活动：执行安全功能审查

根据BSIMM11，现在大约88%的组织会对所开发的软件执行某种安全功能审查。通常，这仍然是大多数组织分析其软件体系结构安全性的唯一方法，但是业界正在此基础上发展。在过去的两年中，对高风险应用程序进行设计审查的组织所占的比例已提高了5个百分点，达到32%。

SSDL接触点：代码审查

活动：使用自动化工具以及手动审核

DevSecOps运动和安全拥护者的多年倡导，提高了业界对代码审查过程自动化的重视。据BSIMM11称，出于效率和一致性的考虑，现在将近77%的组织将静态分析合并到代码审查过程中。对自动化的使用更是五花八门，有些组织将自动化审查构建到代码管理或交付管道工作流程中。但是，这些代码审查工具并不是始终如一地强制执行。只有38%的组织要求所有项目都必须进行代码审查。

SSDL接触点：安全性测试

活动：确保质量检查支持边缘/边界值条件测试

代码审查只是对已部署软件的安全性进行可靠审查的第一步。其他安全性测试(例如黑盒测试)可检测软件构建过程中的漏洞。据BSIMM11称，至少有八成组织的质量检查团队超出了功能测试范围，可以执行基本的对抗性测试，并探查简单的边缘情况和边界条件。但是在其他许多方面仍然有很大的发展空间。例如，只有32%的组织将黑盒安全工具集成到质量检查流程中。

部署：渗透测试

活动：使用外部渗透测试人员来发现问题

使用外部渗透测试人员是大多数软件团队进行渗透测试的必选项。根据BSIMM11，近88%的人使用外部渗透测试人员来提供代码和配置中可利用漏洞的证据。此外，有77%的企业将这些测试的结果用于漏洞管理和缓解系统，并有68%的人通过红队测试和其他内部引导的渗透测试来作为外部渗透测试结果的备份。

部署：软件环境

活动：确保主机和基础网络安全措施到位

BSIMM11发现，主机和网络安全基础安全措施是所有组织中最常见的软件安全措施。大约93%的组织表示首先要确保的是运行软件的数据中心和网络资产的安全性，因为该报告指出：“在主机和网络的安全性没有确保之前，谈论应用安全性就像先穿鞋后穿袜子。”

部署：配置管理和漏洞管理

活动：创建事件响应或与事件响应交互

尽管许多组织在跟踪和修复软件错误方面非常挣扎，但至少83%的企业已在开发人员和安全事件响应人员之间建立了某种形式的接口。此外，有78%的受访者还报告说，他们通过运行监控发现了软件缺陷，并将其反馈给开发人员。但是，更高级的活动(例如使用运营中识别的错误信息来运行软件事件响应模拟，以改善安全软件开发生命周期)仍然难以实现，只有8%的人从事这项活动。

【本文是IDC.NET专栏作者“安全牛”的原创文章，转载请通过安全牛（微信公众号id:gooann-sectv）获取授权】

戳这里，看该作者更多好文