给CISO的软件供应链债务偿还指南

推出新性能和功能与偿还技术债务之间总是存在妥协，这些IT技术债务包括可靠性、性能、测试，当然也包括安全等等。

在这个“快速交付和破旧立新”的时代，累积安全债是组织机构自愿作出的决策。每个组织机构的 Jira 未完成清单中都塞满了安全任务，如部署安全补丁和运行最新版本、最稳定的编程语言版本以及框架等。做正确的事情需要花费时间，而由于团队优先推出新功能，希望推迟这些安全任务。首席信息安全官 (CISO) 工作的一大部分是在必须偿还安全负债时识别出这些时刻。

Log4j 的利用让 CISO 警醒的一个原因在于，他们意识到如此巨大的已累积的债务竟然不在自己的雷达区。它暴露了开源项目和创建者、维护人员、包管理器和组织机构用户之间的隐藏的安全差距。

软件供应链安全是安全债均衡表上的一个唯一项，但CISO 可组建一个连贯的偿还计划。

漏洞新类别

多数企业非常擅长锁定网络安全，但由于开发人员构建系统和他们用于编写应用程序的软件部件不存在信任机制或安全监管链，因此很可能存在一个新的利用链。

如今，任何有常识的人都会知道，由于安全风险的问题，不能随便捡起一个优盘就插入自己的电脑。但数十年来，开发人员一直都在下载开源包且无法知晓这些包是否安全。

恶意人员正在利用这一攻击向量，因为它是新的低垂果实。他们意识到能够通过这些漏洞来获得访问权限，且一旦侵入，则可跳转到其它系统中，而这些系统有的正是他们用于获得访问权限的不安全部件的依赖。

锁定构建系统，停止更多安全负债

就像开发者指南《保护软件供应链》等材料中提到的那样，CISO 的基本出发点是开始使用开源框架如NIST推出的SSDF和OpenSSF 推出的SLSA。这些都是锁定供应链的基本规定步骤。SLSA 第1级是使用构建系统。第2级是导出某些日志和元数据（供后续查看并进行事件响应）。第3级是遵照一系列最佳实践。第4级是使用真正安全的构建系统。通过这些初始步骤，CISO 能够为构建默认安全的软件供应链创建一个强大的基础。

随着CISO 思考开发者团队如何使用开源软件而变得更为细节。开发人员如何了解公司对于“安全”的策略？他们如何了解所使用的开源软件（当前开发人员使用的大部分软件）确实未被篡改？

在环境中使用之前，通过锁定构建系统和创建可复用的软件部件证明方法，CISO 有效地停止为所在组织机构挖下更深的安全债务缺口。

如何偿还软件供应链安全旧债？

通过锁定基础镜像和构建环境停止挖更深的洞后，现在需要更新软件并修复漏洞，包括这些基础镜像版本在内。

更新软件和修复CVE漏洞非常繁琐、无聊且耗时。它是一种事务，一项工作。它是网络安全的“多吃有好处的蔬菜”。偿还这种债务要求CISO和开发团队深入协作。它也是两个团队达成更多关于安全、生产力工具和流程的共识契机，从而帮助组织机构的软件供应链是默认安全的。

就像有些人不喜欢改变一样，某些软件团队也不喜欢更新容器基础镜像。基础镜像是基于容器的软件用用的第一层。将基础镜像更新至新版本有时候可能会破坏软件应用，尤其是存在测试范围不当的时候。因此，某些软件团队选择保持现状，本质上是依靠一个可能每天都在累积CVE漏洞的可运行的基础镜像版本。

为避免这种漏洞的累积，软件团队应当尽可能更新一些小的图像改动，使用“生产中的测试”实践如金丝雀发布等。使用大小最小的加固的容器镜像，并通过关键软件供应链安全元数据如SBOM、证明和签名，有利于减轻对基础图像日常漏洞管理的痛苦。这些技术很好地平衡了维持安全和确保生产不掉线。

边前进边偿还

安全债务尤其令人不愉快的一点是，你寄望于“某一天”填坑，但它通常会在你最脆弱的时候露出头，不过至少是你可以偿还的。Log4j 漏洞在最为繁忙的假日电商周期出现，让很多工程和安全团队一直忙到下一年。没有一个CISO喜欢突然冒出的安全惊吓。

每个CISO 都应该投入最小，实现更安全的构建系统，在开发人员将软件带入环境前使用多种软件签名方法设立对软件的证明，而加固的最小容器基础镜像减少了软件和应用基础的攻击面。

更加深入地了解这个庞大的软件供应链安全债务的回报后，CISO 面临着在前进时（通过持续更新内含漏洞的基础镜像和软件）有多大意愿希望开发人员进行偿还与拖延债务并实现可接受漏洞程度的两难选择。