软件透明度
在《软件透明度:软件驱动社会中的供应链安全》一书中,由资深信息安全专家组成的团队对软件供应链安全进行了专业处理。在本书中,您将探索有关如何保护自己的组织免受内部和外部攻击的真实示例和指导。它包括涵盖的主题包括软件透明度运动的历史、软件物料清单和高保证证明。
前言
我们中的许多人都会记得2021年12月,我们在亲戚家的客房里,弯腰驼背地坐在小型旅行笔记本电脑前,应对 Log4j 危机。Apache 软件基金会开发的开源 Java 日志框架中的这个漏洞被官方...
引言
我们生活在一个软件触及社会方方面面的时代。软件涉及从关键基础设施、数字商务到国家安全的各个方面。事实上,截至本文撰写之时,世界经济论坛 (WEF) 预测,到2022年底,全球60%的国内生产总值...
第一章 软件供应链威胁的背景
本章概述了核心主题,例如攻击者的诱因、软件供应链攻击的剖析以及相关的里程碑式案例。
1.1 攻击者激励因素
供应链攻击规避了传统的外围防御,使其对攻击者非常有吸引力。组织在防火墙、入侵防御和访问控制方面投入了大量资金。这些保护措施是针对直接针对组织基础结构的“推送”式攻击的防御措施。供应链攻击助长了一...
1.2 威胁模型
威胁建模是一个经常被谈及的主题,但根据作者的经验,大多数组织很少在实践中执行。作为一个行业,我们经常以相当通用的方式讨论威胁,而从未探索正确建模这些威胁所需的软件或系统的背景。然而,这些活动的核...
1.3 里程碑案例一:SolarWinds
如果不讨论 SolarWinds 网络攻击,那么现代软件供应链安全事件的讨论就不完整。SolarWinds 是市场上最大的数字系统管理工具提供商之一。2019 年,SolarWinds 开始遭受...
1.4 里程碑案例二:Log4j
虽然 SolarWinds 网络攻击是针对软件供应商的,但 Log4j 事件却大不相同,因为它针对的是广泛使用的开源软件 (OSS)。Log4j 事件于 2021 年 12 月 9 日开始引起公...
1.5 标志性案例三:Kaseya
另一个值得讨论的非常突出的软件供应链攻击是 Kaseya 勒索软件攻击。Kaseya (http://kaseya.com) 是一家统一的 IT 管理和安全软件公司,专门为托管服务提供商 (MS...
1.6 案例的启示
从这些案例中得出的最重要的结论是,专注于传统的“最后一英里”防御措施(如散列和代码签名)是远远不够的,而且可能会给人一种虚假的安全感。最成功的攻击发生在这些过程的上游,签署恶意代码可能比根本不签...
1.7 小结
在本章中,我们讨论了软件供应链威胁的背景以及攻击者的一些相关诱因。我们还讨论了软件供应链攻击的潜在结构。我们介绍了威胁建模的基础知识及其在防止软件供应链攻击中可以发挥的作用。最后,我们讨论了一些...
第二章传统的供应商风险管理
传统的供应商风险管理方法历来用于了解软件和产品供应商的安全软件开发实践。其理念是,要求供应商回答一系列关于他们如何处理某些安全控制的问题,这可能是确定他们是否了解他们应该做什么、是否有记录在案的...
2.1评估
首先,这些评估面临着巨大的潜在挑战。企业每年如何进行数百甚至数千次评估来执行风险管理计划?最常见的方法是利用一份标准问卷,将其发送给所有供应商,向他们提出相同的问题,以便将供应商相互比较。但哪些...
2.2 软件开发生命周期评估
软件开发生命周期(Software Development Life Cycle,SDL)评估更侧重于了解供应商的流程。虽然这个框架可能类似于传统的供应商风险评估,但通常由合格的应用安全顾问进行...
2.3应用程序安全成熟度模型
与SDL评估类似,查看诸如构建安全成熟度模型(Building Security in Maturity Model,BSIMM)或软件保证成熟度模型(Software Assurance Ma...
2.4 应用程序安全保证
传统上,应用程序安全实践集中在应用程序测试的概念上,我们在这里称之为应用程序安全保证。在这里,应用程序安全超越了治理和流程等较软的主题,旨在回答有关应用程序技术风险的问题。我们在这里讨论五种主要...
2.5哈希和代码签名
使用加密验证的历史可以追溯到几十年前,通过诸如MD5和SHA-256之类的算法构建单向哈希。其理念是由于这是不可逆的加密,不能被操控,并且因为哈希理论上应该是唯一的,可以用于表示文件的完整性。如...
2.6总结
在本章中,我们讨论了一些与传统供应商风险评估、第一方与第三方证明挑战以及应用程序成熟度模型相关的历史背景。我们还讨论了一些常见的应用保障和安全措施工具和方法,以识别并促进缓解应用程序中的漏洞和缺...
第三章 漏洞数据库和评分方法
关于应用程序安全和漏洞管理的对话的一个关键方面是对漏洞进行分类和评分的方法。这是推动软件透明度的一个重要方面,更重要的是,软件安全。如果不了解存在哪些软件漏洞以及这些漏洞的评分方式,组织就很难确...
3.1公共漏洞与暴露
“公共漏洞与暴露”(CVE)是一个项目,旨在识别、定义和编目公开披露的影响软件或硬件的网络安全漏洞。作为一个组织,CVE涉及国际研究人员和组织的参与,这些合作伙伴帮助发现和发布漏洞,并以标准化格...
3.2国家漏洞数据库
漏洞有助于指导软件生产者和消费者降低风险,并为行业提供广泛的关于生态系统中存在的漏洞的知识。虽然行业中有多个漏洞数据库,但最著名的例子之一是NIST的国家漏洞数据库(NVD; https://n...
3.3软件标识格式
推动软件供应链安全性和软件透明度的一个基本方面是需要有效的方法来识别软件组件,包括拥有足够的信息来唯一地识别每个软件组件。然而,这种需求远不是一个微不足道的问题,因为软件领域由数千个不同的软件供...
3.4 Sonatype OSS索引
随着OSS的采用不断增长,并日益对现代应用程序和产品的重要部分做出贡献,人们越来越需要了解与OSS组件相关的风险。超声型OSS指数已经成为一个帮助解决这个问题的著名来源。该索引提供了数百万个OS...
3.5 开源漏洞数据库
2021年,谷歌安全发布了(https://security.googleblog.com/2021/02/ launching-osv-better-vulnerability.html)开源...
3.6 全球安全数据库
尽管 CVE 计划得到了广泛采用,但许多人指出该计划存在问题,其方法以及无法跟上动态技术格局。随着云计算的兴起,云安全联盟 (CSA;https://cloudsecurityalliance....
3.7 公共漏洞评分系统
虽然CVE计划提供了一种识别和记录漏洞的方法,NVD丰富了CVE数据并将其呈现在一个强大的数据库中,但通用漏洞评分系统(CVSS)则评估安全漏洞的严重性并分配严重性分数。CVSS致力于捕捉软件、...
3.8 漏洞预测评分系统
基于对CVSS的批评,一些人呼吁使用漏洞预测评分系统(Exploit Prediction Scoring System, EPSS)或将CVSS与EPSS结合,以使漏洞指标更具可操作性和效率。...
3.9 EPSS模型
EPSS旨在帮助安全从业者及其组织改进漏洞优先级排序工作。在当今的数字环境中,识别出的漏洞数量呈指数增长,这一数量因系统和社会的数字化程度提高、对数字产品的审查增加以及研究和报告能力的提高而不断...
3.10 EPSS的批评意见
与CVSS类似,EPSS也受到业界和学术界的批评。卡内基梅隆大学软件工程研究所(SEI)博客上的一篇文章《Probably Don’t Rely on EPSS Yet》(https://ins...
3.11 CISA的观点
随着关于漏洞优先级排序和管理的讨论日益激烈,像CISA这样的组织也对此发表了看法。2022年11月发表的一篇题为《Transforming the Vulnerability Managemen...
3.12 行动意见
CISA 指导意见优先考虑的步骤包括使用 CSAF 自动化安全公告,并通过 VEX 等资源告知软件消费者漏洞利用的影响。然而,同时也明确指出,需要主观的网络安全专业知识,尤其是在复杂的决策树中。...
3.13 小结
在本章中,我们了解了行业漏洞数据库和评分方法。这包括传统漏洞数据库及其潜在的局限性,以及整个漏洞生态系统中新兴的数据库。我们还审视了常见的软件身份格式及其带来的挑战,以及为缓解这些挑战所提出的解...
第四章 软件物料清单的兴起
本章讨论了 SBOM 概念的起源,包括早期的失败和成功,以及为其成熟做出贡献的美国联邦和行业组织。我们还将深入探讨 SBOM 格式、特定字段以及漏洞利用交换 (VEX) 出现的一些细节
4.1 法规中的SBOM:失败和成功
尽管行业内可能存在一系列与软件物料清单 (SBOM) 相关的动态,但达到当前这一点是经过了多年的努力,涉及了各种政府和行业组织的参与。最值得注意的是,最近的 SBOM 动态发生在国家电信和信息管...
4.2 行业努力:国家实验室
为应对特定行业的需求,几个概念验证(PoC)小组作为NTIA SBOM研讨会的一部分被建立。医疗PoC至少经历了三次迭代,此外还成立了汽车PoC和其他几个小组。这些小组中有些对公众开放,有些仅限...
4.3 SBOM格式
为使 SBOM 的采用标准化和成熟化,各方努力围绕几种主要的 SBOM 格式开展工作。迄今为止,三种主要的 SBOM 格式是软件识别 (SWID) 标签、CycloneDX 和软件包数据交换 (...
4.4 行动建议
正如我们所讨论的,SBOM 计划从 NTIA 转移到网络安全基础设施安全局 (CISA),与此同时 SBOM 的倡导者和领导者 Allan Friedman 也转移到了 CISA。自此之后,CI...
4.5 将 SBOM 与其他证明结合使用
SBOM 只是一种证明;它是一份包含其内部声明证据的文件。它通过附加到这些声明上的加密验证的质量和真实性得以强化。因此,通过数字签名将 SBOM 连接在一起的概念变得可行,这使得即使是不完整的 ...
4.6 总结
在本章中,我们讲述了 SBOM 的兴起,以及其从 NTIA 等机构开始的早期努力,现阶段则转移至美国联邦的 CISA。我么讨论了不同的 SBOM 格式,还提到了 VEX 概念的出现,这有助于减少...
第五章 软件透明度的挑战
在美国国家电信和信息管理局 (NTIA) 软件物料清单 (SBOM) 计划的早期讨论中,设备的 SBOM 主题作为一个复杂的因素出现。目前,人们的共识是,SBOM对许多组织来说是一个新概念,因此...
5.1 固件和嵌入式软件
我们将这一类别分为几个讨论领域:作为操作系统的固件、嵌入式设备的固件,以及 SBOM 在某些特定设备场景(如医疗设备)中的应用。 Linux 固件 作为操作系统的固件,特别是 Linux 固...
5.2 开源软件和专有代码
在软件领域,代码主要分为两类——开源软件(OSS)和专有软件——这使得讨论软件供应链中的透明性变得复杂。OSS 与任何人都可以查看、使用和贡献 OSS 代码有明显不同。尽管存在一些所谓的“源代码...
5.3 用户软件
用户软件与设备固件或用于管理网络和安全的企业级产品相比,往往带来截然不同的视角。通常情况下,这些软件被认为不是关键性的,因此常常未能引起足够的关注。然而,用户软件和常见工具却经常成为攻击的目标。...
5.4 遗留软件
如果我们看看开源生态系统中为解决供应链问题而推出的所有优秀项目,包括现代应用开发框架和工具,这无疑展现了一个特别乐观的前景。但是,这对于遗留软件意味着什么呢? 特别是在关键基础设施或国防领域——...
5.5 安全传输
在供应链风险管理的核心是信任的概念,或信任的验证。这包括对软件来源或出处的信任,相信它不包含超出我们风险容忍度的组件或库,相信在到达我们之前没有发生变化,相信我们即将安装的是我们所预期的产品。 ...
5.6 总结
总结起来,尽管推动软件透明度背后有着巨大的动力,但仍然有几个问题需要解决,而这些问题的解决可能具有挑战性。在本章中,我们讨论了一些问题,如嵌入式和遗留软件、开源软件及其各种许可类型,以及数据传输...
第六章 云和容器化
虽然在传统的本地基础架构中追求软件物料清单 (SBOM) 和软件透明度具有挑战性,但在使用云服务和云原生架构时,挑战就大不相同了。在本章中,我们将讨论围绕云和容器化增长的一些指标,以及云计算背景...
6.1 共担责任模型
如果不涉及共享责任模型 (SRM),关于云的安全性和风险的讨论就不完整。许多企业领导者仍然会问“云安全吗?”,这是一个错误的问题。更合适的问题是“作为安全团队和组织,我们是否确保了我们在云消费中...
6.2 云原生安全的4C
将云原生生态系统情境化的一种有用方法是通过 Kubernetes 文档中描述的“云原生安全 4C”,此处讨论的图 6.2 中所示的容器编排器。 图6.2 在此特定于容器及其编排的上下文中,您拥有...
6.3 容器
云原生生态系统延续了物理服务器和虚拟机 (VM) 等传统计算模型,广泛使用容器。因此,当涉及到容器及其相关的编排系统(如 Kubernetes)时,我们必须讨论容器和相关的软件供应链问题。 随着...
6.4 Kubernetes
容器编排通常被定义为自动执行操作工作以运行容器化工作负载和服务。虽然有几种潜在的容器编排工具可供选择,但 Kubernetes 在采用和使用方面无疑是行业领导者 (https://kuberne...
6.5 无服务器模型
在VMs和容器的计算抽象和演化的基础上,一些组织根据它们的用例进一步采取了他们的采用过程,并已经开始使用所谓的无服务器模型。更高级的说法是,无服务器模型允许开发团队构建和运行云本地的应用程序,而...
6.6 SaaSBOM及API复杂度
为所包含的实体创建一个SBOM可能会很复杂,例如在本地交付的软件或容器映像。为具有云和SaaS等无数相互关系的动态且快速变化的环境创建SBOM可能是另一个级别的难度。 关于SaaS的SBOM的概...
6.7 在DevOps和DevSecOps中的应用
随着云和云原生架构的出现并继续流行,另一个趋势发生了:从传统的瀑布式软件开发到DevOps时代,或者最近的DevSecOps时代的转变。在不进行哲学辩论的情况下,DevOps可以概括为一套弥合软...
6.8 小结
总之在《2022年DevOps状态报告》中、DORA团队的软件工件供应链水平(SLSA)和NIST的SSDF确定了与保护软件供应链相关的流程和实践。我们探讨了DevOps和DevSecOps为何...
第七章 现有和新兴商业指南
随着围绕软件供应链安全的对话日趋成熟,许多组织已开始为行业提供强大的指导、框架和资源,以加强其针对此类攻击的安全态势。在接下来的章节中,我们将讨论其中一些资源以及提供这些资源的组织,其中包括云原...
7.1 软件制品的供应链等级
随着软件供应链攻击的增加,很明显,需要一个全面的端到端框架来定义软件供应链袭击和缓解方法。2021年6月,谷歌开源安全团队推出了软件工件(SLSA)工作该工作的目标是确保软件工件的完整性在整...
7.2 用Google Graph理解制品组合
在SLSA框架的一个巧妙命名的后续行动中,谷歌与花旗和普渡大学等合作伙伴还宣布了一项名为“理解工件组成图”(GUAC)的开源软件(OSS)工作,如图7.5所示。根据他们的声明,“GUAC解决...
7.3 CIS软件供应链安全指南
随着行业不断成熟的软件供应链实践,我们看到了NIST、开源安全基金会(OpenSSF)和互联网安全中心(CIS)等组织的指导。在本节中,我们将讨论最近发布的CIS软件供应链安全指南(https:...
7.4 CNCF的软件供应链最佳实践
在有关软件供应链安全的讨论中经常引用的另一个行业指导来源是 CNCF 的软件供应链最佳实践白皮书 https://github.com/cncf/tag-security/blob/main/s...
7.5 CNCF的安全软件工厂参考架构
对许多人来说,将软件生产与工厂这一术语联系起来可能看起来有些奇怪。大多数人仍将工厂与收集、处理和制造物理材料如钢铁、汽车或消费电子产品联系在一起。然而,讽刺的是,现代大多数工厂环境的运作依赖...
7.6 微软的安全供应链消费框架
作为开源软件(OSS)的主要贡献者和消费者之一,微软推出了一个名为安全供应链消费框架(Secure Supply Chain Consumption Framework,S2C2F)的软件供...
7.7 S2C2F 实践
如前所述,S2C2F包括一系列解决方案和供应商无关的实践,这些实践可以帮助组织确保其开源软件供应链的安全使用。合规、安全、工程管理人员以及首席信息安全官(CISO)等领导者可以参考这些实践,...
7.8 S2C2F 实施指南
如图 7.12 所示,与 SLSA 等其他框架一样,S2C2F 也围绕四个成熟度级别展开,从最基本的开放源码软件治理一直到高级威胁防御,每个级别都有自己的相关活动。 第1 级包括基本活动,如内部...
7.9 OWASP 软件组件验证标准
与 NIST 的安全软件开发框架(SSDF)等由政府组织创建的框架不同,OWASP 的软件组件验证标准(SCVS)是一项由社区推动的工作,重点关注软件供应链。它主要通过确定可在整个软件供应链生命...
7.10 开放源码安全基金会评分卡
每个人都知道Marc Andreessen在十多年前提出的“软件正在吞噬世界”(https://a16z.com/2011/08/20/why-softw-is-eating-the-world...
7.11未来之路
虽然开源软件提供了巨大的好处,但许多关注和研究发现,自由/开源软件开发人员在很大程度上没有优先考虑安全性。Linux基金会的OpenSSF和哈佛大学创新科学实验室的一项研究发现,自由/开源软件开...
7.12 总结
在本章中,我们讨论了现有的和新兴的软件供应链安全指南。这包括SLSA的努力以及来自微软、CNCF和其他机构的资源。在下一章中,我们将讨论来自政府实体的现有和新出现的指导意见。
第八章 现有和新兴政府指南
在本章中,我们将讨论政府和公共部门组织针对软件供应链安全的现有和新兴出版物。这些出版物建立在我们在上一章中讨论的现有商业指南的基础上,并考虑了国防部 (DoD)、美国联邦民事行政部门 (FCEB...
8.1 系统和组织的网络安全供应链风险管理实践
2020年初,美国国家标准与技术研究院(NIST)首次发布了特别出版物(SP) 800-161,“系统和组织的网络安全供应链风险管理(C-SCRM)实践”。然而,与本书中讨论的许多其他资源一样,...
8.2 软件验证
NIST 网络行政命令第 4 部分指南的另一个关键组成部分是发布指南,为供应商测试其源代码推荐最低标准。它包括手动和自动测试,例如代码审查工具、静态应用程序安全测试 (SAST)、动态应用程序安...
8.3 NIST 的安全软件开发框架
正如本书的几个部分所讨论的那样,网络安全行政命令 (EO) 14028 对零信任、云计算以及软件供应链安全等领域产生了广泛影响。作为网络安全行政命令的一部分,政府必须“只购买安全开发的软件”。行...
第九章 运营技术中的软件透明度
运营技术 (OT) 运行着世界上最关键的流程,从导弹平台和防御任务,到水处理厂和电力,再到关键制造、机场等。通常,这些环境使用气隙隔离网络高度隔离,并且可能有限制外部连接、云或移动功能。正因为如...
9.1软件的动力学效应
EO 14028最引人注目的举措之一就是采取行动来界定“关键软件”。正如我们之前讨论过的,这些定义可能很难搞清楚。有人可能会认为所有的软件都有潜力成为关键软件,关键在于如何使用它。我们过去使用的...
9.2遗留软件风险
同样,正如我们之前所讨论的,这些软件中的很多都非常陈旧 在验证传统产品时也会遇到类似的挑战。OT 系统的一个主要特点是需要有弹性。著名的 ICS 安全专家丹尼尔-艾伦瑞克(Daniel Ehre...
9.3控制系统中的梯形逻辑和设定点
可编程逻辑控制器 (PLC)、远程终端装置 (RTU) 和类似的 OT 设备可运行基本的自动化程序。通常使用梯形逻辑、功能块图或其他方法进行编程。它们描述了一系列输入和输出,包括用于决策的逻辑或...
9.4 ICS攻击面
如前所述,与企业 IT 相比,ICS 的攻击面通常最小。大多数环境都被严格分割,能源部在《2020财年国防授权法案》第5726条的指导下,通过安全能源基础设施执行任务组(Security Ene...
9.5 智能电网
智能电网是传统电网的现代化、数字化版本,它使用先进技术来提高电力系统的效率、可靠性和灵活性。它使用传感器、通信网络和控制体系来监测和控制电力的流动,从而实现可再生能源的整合和需求管理。这使得分布...
9.6 总结
在这一章中,我们讨论了软件的行为效应以及可能对社会产生的物理影响。我们也涉及到了与工业控制系统中的遗留软件和梯形逻辑相关的风险。我们进一步探讨了工业控制系统攻击面的性质及其对关键基础设施、国防和...
第十章 供应商实务指南
虽然我们已经讨论了许多来自私营和公共部门组织的新兴行业指导来源,但接下来的几章将努力为供应商和消费者提供一些实用的指导。这将包括来自我们讨论的来源的指导的综合,以及基于作者专业经验的行业最佳实践...
10.1 漏洞披露和响应 PSIRT
如前所述,SSDF 呼吁各组织实施合理的实践,以帮助实现安全的软件开发。它将这些实践分为四组:组织准备、保护软件、生产安全可靠的软件和应对漏洞。这四组中的一个关键主题是组织和供应商披露和应对影响...
10.2 产品安全事件响应团队 PSIRT
另一项与 SSDF 和产品与软件供应商行业最佳实践相关的重要建议是建立产品安全事故响应小组(PSIRT)。PSIRT 类似于网络安全事件响应小组 (CSIRT),但 PSIRT 并不是面向内部的...
10.3 分享还是不分享,多少才算太多?
在推动软件透明度的过程中,软件供应商可能会发现自己会问的一件事是,他们到底需要共享什么,或者他们是否应该共享这些数据。虽然每个组织的决策过程和分析看起来都不同,但有一点是明确的,由于软件供应链攻...
10.4 版权所有,许可问题和“原样”代码
正如我们在第 5 章“软件透明度的挑战”中所讨论的,许可也是许多供应商关注的一个关键问题,特别是当它与开放源码软件及其应用的许可有关时。许多软件供应商可能关注的一种许可方法就是所谓的 Copyl...
10.5 开源项目办公室
正如我们所讨论的,各种形状、规模和行业的组织都在拥抱开源软件(OSS)。金融、医疗和制造业,甚至国家安全,现在都使用OSS来支持其最关键的应用和活动。这包括软件供应商,他们通常使用OSS作为其产...
10.6 产品团队之间的一致性
如果不能在组织的各个产品团队中一致地实施,那么推动软件透明度和提供 SBOM 和证明等工件就不可能有效。对于非常大的组织或具有全球影响力的组织来说,拥有多个产品团队的情况并不少见,其中一些团队拥...
10.7 手动工作量与自动化和准确性
供应商必须考虑的一个关键点是自动化的作用与提供给消费者的信息准确性的需求形成鲜明对比。对于大型软件公司来说,进行软件保障成为一种可扩展性的练习,尤其是那些在数百甚至数千个软件产品中部署计划非常快...
10.8 小结
在本章中,我们鼓励消费者广泛而深入地思考软件供应链安全的挑战以及 SBOM 的作用。我们解释了为什么组织需要或应该希望 SBOM 以及更广泛地说,供应商的软件透明度,以及如何使用 SBOM 并大...
第十一章 消费者实务指南
软件供应商的另一面是软件消费者。这些消费者正试图理解正在出现的一系列指导、最佳实践和要求,这些指导、最佳实践和要求不可避免地涉及供应商和消费者之间关系的推拉动态。每个都有不同的观点、激励措施和目...
11.1 深思熟虑
虽然本章关于消费者指南的内容包括与软件物料清单 (SBOM) 相关的讨论和建议,但我们想强调的是,SBOM 只是软件供应链安全更广泛讨论中的一种新兴工具和资源。然而,鉴于其对行业的高度关注,我们...
11.2 我真的需要一个SBOM吗?
随着围绕 SBOM 的所有炒作和混乱,一些软件消费者可能会问自己是否需要 SBOM。当然,虽然软件行业几十年来一直没有使用 SBOM,但这并不意味着没有挑战,而且随着 OSS 和第三方组件的使用...
11.3 我该怎么处理它
你已经从软件供应商那里收到了SBOM,或者基于内部开发工作开始创建SBOM。现在,如何让这些SBOM变得有价值且可操作? 正如我们之前讨论的,SBOM在多种应用场景中具有价值,例如漏洞管理、依赖...
11.4 接收和管理大规模SBOM
虽然单独来看,SBOM的概念及其用于揭示产品所涉及的软件组件和被消耗的软件组件的用途显得合乎逻辑,但在大型企业环境中跨越数百或数千个开发团队和众多第三方软件供应商的大规模实施,这个想法很快就会变...
11.5 减少噪声
拥有SBOM是一个很好的开始,但如果没有关于漏洞实际可利用性的上下文信息,它很大程度上会成为额外的噪声,增加消费者及其各种利益相关者的负担。因此,获取关于软件组件的详细信息(例如可利用性)是关键...
11.6 分歧的工作流程——我不能只是应用一个补丁?
正如我们在前面的部分中讨论的那样,现实情况是,尽管供应商的软件和产品中存在漏洞,但消费者通常无法简单地获取可用的修复补丁。 这可能是由于供应商面临的资源限制、修补和纠正时间表、竞争性功能积压,或...
11.7 小结
在本章中,我们为软件消费者提供了实用的指导,包括广泛而深入地思考其软件消费的范围以及相关的各种来源和潜在攻击向量。我们还讨论了软件物料清单(SBOM)的出现及其对软件消费者的意义,同时强调了一些...
第十二章 软件透明度预测
到现在为止,应该很清楚的是,软件透明度和加强更广泛的软件供应链安全态势的努力绝不是转瞬即逝的。我们看到全球公共和私营部门在法规、工具、技术和框架方面做出了无数努力
12.1 新兴的努力、法规和要求
在新兴法规和要求方面,现在应该清楚的是,世界各国政府都意识到了软件对其机构、组织和整个社会的重要性。软件已与现代社会的几乎每个方面密不可分,从简单的日常休闲活动到最关键的基础设施和国家安全,无所...
12.2 美国政府供应链影响市场的力量
虽然数字因来源而异,但不可否认,美国政府的IT和软件支出市场意义重大。来源估计,美国联邦政府在2023财年的预算超过650亿美元(www.whitehouse.gov/wp-cont/uploa...
12.3 供应链攻击加速
虽然我们在第1章“软件供应链威胁的背景”中讨论过一些指标,但在本文结束之际,我们认为再次强调软件供应链攻击的趋势只会继续加速是有必要的。这是由于多种因素造成的,例如现代数字环境和生态系统的复杂性...
12.4 数字世界日益密切联系
社会上最明显的趋势之一是数字连接设备的快速持续增长。正如我们整本书多次说到的,我们社会几乎每一个方面都与数字连接设备和软件相关联,从无害的生活用品(例如:家庭设备、智能手表和医疗设备等)到关键基...
12.5 接下来会发生什么?
预测未来是非常困难甚至不可能的,但对软件透明度日益增长的推动几乎是可以感受到的。易受攻击软件对普通公民、政府和社会构成的风险再也无法忽视。 软件深入到从我们最基本的个人奢侈活动到我们最关键的基础...