美国 CISA（网络安全和基础设施安全局，下称 CISA）发布了一份新的警报，旨在预警开源工具被用来窃取国防工业基地部门组织的敏感数据这一威胁。

在 2021 年 11 月至 2022年 1 月，高级持续性威胁（APT）团体入侵了一家国防公司，并在其网络上潜伏了数月。CISA 称，这些团体破坏了一个用于管理该组织的微软 Exchange 服务器的管理员账户，并使用一个名为 Impacket 的开源工具包来扩大他们在网络中的落脚点并试图破坏它。

APT 小组使用了一个被劫持的管理员账户来获得访问权，允许他们在连接到 VPN 的情况下，两次访问网络的 EWS 的 API。访问 EWS API 后，威胁者可以在 3 天内使用命令行与该组织的网络互动，包括收集敏感数据。正是在这一时期，APT 组织利用 Impacket 在系统中横向移动。CISA 的警报将 Impacket 定义为一个 "Python 工具箱，用于在另一个系统上以编程方式构建和操纵网络协议"。

目前 CISA 尚未确定这些团体是如何进入网络的。

分析

随着现代软件和基础设施对第三方资源的依赖，针对软件供应链的攻击正以每年 4-5 倍的速度增长，仅在 2021 年就发生了几千次。根据 Sonatype 2021 年的报告，29%的常用开源项目包含了已知的第三方库安全漏洞，足以可见安全漏洞存在的普遍性。开源软件的漏洞对于企业经营会造成极大的损失。根据网络安全风险公司（Cybersecurity Ventures）的数据，全球每 11 秒就会发生一次勒索软件攻击，去年全球经济损失约为 200 亿欧元。
从上述攻击事件也可以看出，开源软件的漏洞对于国家国防关键基础设施的威胁也不言而喻。对于与国防相关的基础设施都包含巨大的风险和漏洞，一般商业化企业自身的信息安全往往无法与这类组织相比，实际上我们可以说企业内部有漏洞的开源资产数量更多、危害性更大。

对于开源风险或者供应链风险的治理，我们一定会提到 SBOM（软件物料清单，下称SBOM）。可以说 SBOM 是针对此类风险治理的基础，也是最为关键的地方。

趋势

“SBOM 是管理现代软件部署的复杂性和安全性的基础。” Gartner 分析师 Mark Driver 在一份研究报告中写道：“产品领导者必须满足对技术、最佳实践和解决方案日益增长的需求， 以支持 SBOMs 的交付。”

Gartner 估计，软件项目中 40%到 80%的代码行来自第三方。“这些外部代码大部分来自于无数的开源项目；其余的专有代码来自于供应商，这些供应商几乎不对任何软件组成的透明度给予澄清。更为严峻的是，许多开源依赖呈现管理不足，人员不足的状态。”

Gartner 认为，到 2025 年，在具有采购关键任务软件解决方案的组织中，60%的组织将会在其许可和支持协议中强制要求披露 SBOM，而 2022 年这一比例还不到 5%。Gartner 进一步强调，如果软件供应商想在市场上保持竞争力，就必须准备向他们的客户提供SBOMs。

但仅仅有 SBOM 并不是万能的，因为组件的信息、漏洞和许可证信息随时都可能发生变化，理想的 SBOM 应该是动态的且实时更新的。只有在与企业研发流程和相关工具（如 SCA， 软件成分分析工具）相结合之后才能发挥更大的作用，甚至通过代码签名的流程和工具来确保其完整性也是软件供应链不可或缺的一部分。

启示

在这份报告中，Gartner 给出了以下几点启示：

1、软件供应商需要走在需求的前列

即使客户暂时没有要求披露 SBOM，软件供应商也应该对内部的软件资产建立一个清单。作为第一步，软件供应商可以准备一个最基础版本的 SBOM（比如按照 NIST 给出的最基础 SBOM 中的规范），然后根据不同行业的需求和动态进行调整。

该报告还建议供应商将他们的每项资产归类为 "商业机密 "或 "完全公开"。供应商可以决定将商业机密排除在 SBOM 之外，或将其公开，但可以通过客户许可协议中的保密协议来保护其商业机密。

报告中还建议创建一个所有外部依赖关系的完整清单。与资产供应商有关并受 SLA 制约的依赖关系应被归类为 “商业化支持”，都需要完整的 SBOM 披露。没有商务属性 SLA 的依赖应归类为 “自我支持”。此外，应该为这些依赖关系建立一个自我支持的 SLA。该 SLA 应包括发现和跟踪一个完整的 SBOM。

2、因为不透明产生的安全隐患亟待解决

报告还建议软件供应商确保他们有能力为其自主开发的软件资产创建一个完整的SBOM。软件供应商需要超越客户对 SBOM 的最低要求来创造更大的价值，比如深度融合到 DevSecOps 体系和流程中，并且在产品的路线图中考虑 SBOM 的扩展和发展。

Mark 强调：“软件供应商不应仅仅停留在 SBOM 上。我们的最终目的是提供构成这些解决方案的软件资产的洞察力，并且及时纠正通过 SBOM 披露发现的安全和质量问题，以避免网络犯罪分子将其用作攻击媒介，来消除因为不透明产生的安全风险。”

3、现代软件开发需要一种新的模式

实际上，我们需要 SBOM 信息的原因是我们并没有处于一个完美的场景中。在一个完美的场景中，我们不需要共享 SBOM 信息，因为我们在这种场景下的预设立场是软件供应链所有的环节都各司其职，保证其代码质量和安全。

但这显然是不可能的。

在一个严重依赖开源软件的技术生态系统内，许多组件缺乏足够的商业支持。因 此，各供应商对于软件质量和安全检查的做法大不相同；供应链中每个节点的做法的严格程度也不尽相同，而且这种情况也随着时间不断变化。作为最上游的消费者需要一种方式来信任供应商提供的代码，SBOM 就提供了这样的基础信息。

总结

SBOM 是不可或缺的，各企业组织现在就应该行动起来

SBOMs 正在成为软件开发组织的必要条件。Mark 认为在未来三年内，为软件解决方案提供完整、准确和最新的 SBOM 的要求将成为大多数客户的强制性要求。不能或不愿意提供 SBOM 披露的产品将发现自己的竞争力越来越小。

SCA 工具的采用将会越来越广泛

当今世界，开源软件的使用成为了软件开发的主流，据不完全统计，世界上不同来源的开源组件有数千万种。面对如此庞大的开源组件来源，通过人工记录的方式显然是不现实的，并且这种方式基本不具有追踪、检索的可能性。Log4j 的漏洞给几乎所有的互联网企业都造成了人力、物力、财力的影响，如果类似的漏洞再次发 生，企业如何快速定位受影响的组件？SCA 工具提供了这样的一个高效且准确的方式。一款优秀的 SCA 工具应该具有以下特点：

1）扫描大型项目快速且可以识别各种形式的开源引入（如修改过的代码片段）

2）匹配逻辑高效且准确，降低误报率和漏报率

3）拥有全面的知识库，包含足够多的组件、代码片段、漏洞、许可证等信息