针对美国网络空间日光室委员会发现和建议的系列文章之九
软件责任只是起点
美国大西洋理事会学者特雷·赫尔撰文指出，软件责任管理体制是确保软件生态系统安全的有效方法。但让软件生产商承担责任只是最基本的要求，责任管理体制还应注重以下三个方面：一是要适用于整个软件行业，包括云服务提供商和运营技术公司；二是明确制定软件装配商必须践行的“注意义务”标准；三是直接与激励机制挂钩，使机构能够及时打补丁。文章全文翻译如下，供读者参考。
网络空间日光室委员会高度重视软件生态系统安全，并提出多个政策杠杆加以改善，包括提议让从事软件产品和服务的“最终商品装配商”对未能及时修补代码已知缺陷承担相关责任。责任并不是一个新概念，过去50年中，国内外学术刊物和政策中已经多次提及。一些供应商自盒装软件出现之初就反对承担责任，追责将有助于改变激励方式，促使其快速有效地修复软件缺陷。支持追责的隐形好处在于，随着时间的流逝，已修改激励措施将会带来更多更安全的软件，未修复的缺陷更难被利用。
不过，承担责任只是开始。要让软件生态系统发生有意义的改变，责任管理体制还应：
适用于整个软件行业，包括云服务提供商和运营技术公司，例如制造业和汽车公司。这些公司是软件供应链中的重要环节；
制定装配商必须践行的明确“注意义务”标准—软件提供商必须通过践行这样的安全实践和安全策略，让所生产的代码少有缺陷，即便有缺陷也能快速修补；
直接与激励机制挂钩，使机构能够及时打补丁。
责任制应适用于整个软件行业
软件行业不再是只有少量出售盒装光盘的公司。世界上一些最大的软件项目都由通用汽车、波音、洛克希德·马丁和西门子等公司管理，这些软件项目甚至比现代的操作系统还要大。像谷歌、亚马逊和微软这样的云提供商，所负责的代码将影响全球数十亿用户。“最终装配商”的提法是确定软件生态系统发展瓶颈的一种行之有效的方法，网络空间日光室委员会在其分析中也建议，要正确地区分软件装配商和硬件装配商。一旦采用了责任制并执行“注意义务（duty of care）”，决策者必须确保其适用于整个软件行业，包括运营技术和云计算领域，而不仅是过去十年的信息技术巨头。
重新制定安全代码生成与快速修补标准
责任是一种法律机制，它将使商品和服务提供商对其提供的商品和服务的质量和安全负责，而确定其商品和服务的质量和安全可否接受需要有明确的标准。法律术语中，这叫“注意义务”，即产品提供者确保其产品不会损害其用户的最低义务。“注意义务”对于确定最终商品装配商的预期行为标准至关重要。一项有效的标准能够适当地规定法律义务，以便设置软件的“寿命终止（EOL）”日期，取消影响安全研究的版权保护，或阻止使用某些软件语言。这些语言先天就有缺陷，或者利用这些语言编写代码很难不出现错误。
不过，正如美国国家标准技术研究所（NIST）2016年在报告中指出的那样，确定哪些是“‘粗心且容易避免’的错误”并非易事。即使避免犯这些简单错误，也不代表就能保证质量过关。为解决此问题，人们前前后后付出了许多努力。有些人关注特殊的高影响力领域，例如发电和配电以及医疗设备制造。其他人关注的则更为全面，例如微软的“安全开发生命周期”开发，这项努力持续了长达十年多的时间，从“安全代码（SAFE Code）”，到“安全软件开发基本实践”，到至今仍在进行的新的“安全软件框架”，它由商业软件联盟（BSA）演变而来。国家电信与信息管理局所提供的“软件物料清单（SBOM）”是一个补充，机构可据此了解如何跟踪所使用的代码，而不是如何开发或修补代码。
针对补丁的速度和质量的标准是一个更加模糊的领域。也许谷歌公司“零项目（Project Zero）”团队提出的90天披露要求是最有名的例子。“零项目”是谷歌内部一个少见的人才团队，负责研究和披露流行软件中的漏洞。长期以来，“零项目”团队要求问题公司必须在收到公开信息后90天内发布补丁。为能在复杂情况下保持更高的一致性，该团队最近将此项政策正式化，以激励企业发布更高质量的补丁。
谨记要采用补丁
世界上最快的补丁，如果不用也毫无用处。一种有效的责任管理体制必须考虑软件的整个生命周期，包括对应用补丁程序的激励措施。这里有三种方法可作为软件责任管理体制的补充。
首先，美国NIST可以制定补丁应用的标准，针对漏洞的严重性和可利用性，划分适当的类别，规定需要打补丁的软件和系统的类型以及提供补丁的组织的安全成熟度，确定成熟度可参考几种模式中的任何一种。尤其是，可利用性是一种主观决定，但将由安全工程团队和研究人员定期做出。
其次，国防部（DOD）和总务管理局（GSA）可以参照“服务水平协议（SLA）”对补丁应用效率进行测评。SLA是所有联邦技术采购合同所参照的标准，也许还可以参照上文提到的NIST标准。在评估合同绩效时，不遵守SLA的公司将受到罚款，这与联邦采购中提倡将安全性作为考评标准的方法类似。
第三，保险公司提供的产品线全部或部分覆盖网络安全的，可以根据自我报告的补丁采用率，对新客户进行部分风险评估，所参照的可以是上文提到的NIST标准，或其他达成共识的标准。对比类似客户的补丁使用率，可以洞悉客户的安全成熟度，并可间接了解不同最终产品装配商的补丁质量。
统计补丁并非检测代码安全的标准。了解哪些机构在应用补丁程序方面落后于同行，以及激励其更及时采用补丁程序，将提高其安全性。未来，补丁应用绩效可能进行更广泛的市场通告，特别是预期业务合作伙伴之间和供应链内部。不过，制定标准并在联邦企业中实施只是开始。
结论
责任是一个恼人的话题。许多年来，人们都期望其回归网络安全政策对话。在其他信息和通信技术产品中，欧盟牵头建立了软件安全认证管理体制，该管理体制将受益于什么是好代码的特别技术讨论以及如何有效修补代码。NIST制定安全软件开发框架的工作也可能会获得额外投入并成为工作重点，这对于标准组织是积极和及时的。
中小型软件开发人员、开源代码项目甚至学者都将从广泛使用（因此更容易实现自动化）的安全开发实践和工具中受益。从事软件开发业务的大型参与者也将从中受益。在脸谱或福特等大型技术公司，详细的外部标准将有助于内部努力统一和执行安全的开发实践。
最终，用户也会从中受益。软件已经吞噬了整个世界，使得提高代码质量和修复速度成为紧要任务，因为它已全面渗入我们的日常生活。正如今年早些时候，一种家用互联网路由器（补丁程序已经发布多年，但仍有许多人尚未使用）出现了一个令人讨厌的缺陷，即便我们购买的最小型设备，其安全性对于保护我们社区和保护我们的房屋同样重要。
关于软件责任的辩论只是一个起点，还需要将责任制推广到整个软件供应链，包括云提供商和运营技术公司。做到这样，必须要有明确的标准，并且这些标准应与激励机制相结合，促使补丁一旦发布就能被采用。通过采取适当的立法措施，辅以美国NIST科研工作者的大力帮助，加上国防部、国土安全部和特定部门机构在推动采用方面的努力，其输出一定是华盛顿最罕见的成果：确实有效的东西。
声明：文章仅供交流参考，不代表本机构立场。
声明：本文来自奇安网情局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
