构建可信开源软件供应链：微软OSS SSC框架最佳实践全解读
引言
为什么需要关注OSS供应链安全？
在现代软件开发中，开源软件（Open Source Software, OSS）扮演着不可替代的角色。无论是互联网巨头，还是初创公司，几乎所有的软件工程项目都依赖于开源组件来加快开发节奏、降低研发成本。然而，开源组件带来的不仅是便利，也可能成为攻击者渗透整个软件供应链的突破口。
近年来，针对开源生态系统的攻击手法层出不穷，例如依赖混淆（Dependency Confusion）、名称拼写欺骗（Typosquatting）、恶意代码注入、维护者账户被劫持、构建链污染等，这些攻击极具隐蔽性，往往直到产品上线运行后才被发现，给企业带来严重的合规与安全后果。
微软自2019年起，在全公司范围内部署了OSS安全供应链框架（OSS Secure Supply Chain Framework，简称OSS SSC），并于2022年正式发布了对外版本，该框架系统梳理了OSS安全风险、防御实践、成熟度模型和工具链支持，是目前业界最成熟、最具实操性的开源供应链安全治理指南之一。
本文将系统解读该框架的核心理念与八大安全实践，结合真实案例与工具推荐，为组织建立可信的OSS治理体系提供全面指导。
框架概述
微软OSS SSC的核心理念
微软的开源软件安全供应链框架的目标是解决三个问题：
为开源软件合规提供一个强大的流程；
降低解决已知开源软件漏洞的MTTR（平均修复时间）；
阻止受攻击或恶意开源软件包引入到开发项目。
这个框架围绕三大理念构建：
1. 控制所有制品输入
如今开发者引入开源组件的方式五花八门，包括：git clone、wget 下载、复制粘贴源码、将二进制直接提交到代码仓库、从公开包管理器直接安装、将开源包打包成 zip 文件、使用 curl、apt-get、或 git submodule 等方法。
如果开发团队在使用开源组件时没有统一的流程和规范，将难以实现整个组织的供应链安全防护。因此，构建一个有效的开源供应链安全策略，必须要求全公司统一OSS的引入方式，确保所有开发者通过受管控的流程来获取开源组件，统一开源软件的获取方式，避免野蛮拉包，即不分对象、不分目标、不分渠道拉取制品包引入开发项目；
2. 持续过程改进
为了引导组织逐步优化其开源软件安全流程，微软将该框架设计为分级的成熟度模型，帮助企业按优先级逐步实施各项安全要求。
考虑到安全风险具有动态变化性，新的攻击手段可能随时出现，因此框架强调：组织必须持续评估自身的安全控制措施，并根据新威胁或新技术的出现不断优化调整。通过引入成熟度模型，实现安全实践的渐进式部署。
3. 可规模化落地
微软在设计该框架时特别考虑了企业实践中大规模实践的需求。一些组织试图通过搭建内部私有仓库或私有服务器（central internal registry）来集中管控开源软件的依赖，但现实中总会有开发者绕过流程，比如直接从如 PyPI、NPM等公共源拉取包，而这类绕行行为很难完全阻止，除此之外还会有涉及到开发人员自身使用的开源工具或开源项目无法通过统一的内部私服覆盖。
更何况，集中式管理还需要额外人力维护流程、系统，额外增加了管理和技术成本。因此，在该框架中微软鼓励的做法是：在不依赖集中式仓库或治理机构的前提下，提供支持大规模开发团队安全使用开源软件的机制。
综上，开源软件供应链安全（OSS SSC）框架是一个供各类组织采纳的综合性体系，结合了具体的安全要求与支持工具。它不仅提供了一套用于安全引入开源软件的标准流程，还设计了清晰的能力成熟度路径图（maturity roadmap），帮助企业逐步构建安全可信的开源依赖使用机制。通过该框架，组织可以有效防范开源软件供应链中的安全威胁，同时建立起完善的开源治理体系，实现对开源组件使用的全流程管理与控制。
八大安全实践详解
在实践层面，框架提出了八项核心安全实践，构成一个从获取到部署、从扫描到修复的闭环流程。
1. 统一纳入，掌控源头（Ingest It）
这个阶段的核心目标是确保外部开源软件的官方来源即便遭受破坏或不可用，企业也依然能够使用和交付已有的开源软件制品。
这个阶段所对应的典型风险场景包括：
Docker Hub 被攻击或污染，下载的镜像含有恶意代码；
遭遇依赖混淆攻击（Dependency Confusion），例如开发者使用了名称相同但源不同的恶意包；
云平台服务不可用（如 Azure 停机），导致无法访问上游依赖；
关键依赖被删除（如著名的 left-pad 事件），构建链断裂。
想要构建一个可信的软件供应链，第一步就是控制开发中引入的所有开源软件制品来源。在实践中，开源软件主要以两种形式存在：打包好的制品（Packaged Artifacts）与源代码制品（Source Code Artifacts），它们分别需要对应的引入机制。
对于打包好的组件（如NPM包、Docker镜像、NuGet包），必须通过可信的本地制品仓库（Artifact Store）进行管理，例如：
Linux软件包仓库（如 APT/YUM）
制品仓库（如 Nexus、JFrog、Azure Artifacts）
OCI（Open Container Initiative）镜像仓库
这些工具可以实现对上游源的透明代理与缓存，即制品首次被使用时都会自动保存一份副本，从而实现以下效果：
即使上游断供或断连，本地仍可继续构建；
确保所有开发者统一从内部源获取组件；
有效防止依赖混淆攻击，如CVE-2021-24105中所示的源优先级漏洞。
对于源代码制品（如GitHub项目、开源工具源码），建议将外部源代码仓库镜像到内部代码托管系统中（如GitLab、Azure Repos），其意义包括：
业务连续性与灾难恢复（BCDR）：当关键依赖上游消失时，组织仍拥有一份可用源代码。
支持主动安全扫描，包括查找后门、逻辑漏洞和0-day漏洞；
关键场景下允许内部自修：在极端情况下，如果上游长期未修复漏洞，组织可先行处理并临时替换。
2. 主动扫描，全面检测（Scan It）
这个阶段的核心目标是对所有OSS工件进行全面扫描，发现漏洞、恶意代码和异常行为，确保了解进入CI/CD流水线的开源软件制品是否存在漏洞或恶意行为。
这个阶段所对应的典型风险场景包括：
开发团队试图使用一个已知存在漏洞的开源包，即存在CVE漏洞的开源组件或开源软件包；
正在使用的某个开源组件最初没有发现安全风险，但后来被披露存在安全漏洞；
团队引入了一个包含恶意代码的组件（例如 event-stream 被发现会盗取比特币私钥）；
引入了被植入后门的依赖包，可能被远程触发恶意行为，比如3CX事件。
在上个阶段完成后，这个阶段的目的是主动发现开源软件中的安全风险，即不能盲目信任任何从外部引入的组件，而是要对每一个开源软件制品进行安全扫描。
对开源软件制品进行安全扫描的维度包括：
已知漏洞扫描（CVE）：检查开源组件是否存在公开安全漏洞；
恶意行为检测：检测恶意脚本、钓鱼逻辑、远程连接行为等；
异常/多余代码识别：包括未使用的代码、混淆逻辑、掩盖行为，比如Material-Theme事件；
其他已知或潜在问题：通过静态分析、模糊测试、代码审查等手段可发现潜在问题。
3. 构建清单，摸清家底（Inventory It）
这个阶段的核心目标是明确每个开源软件制品在哪些业务、项目、系统和代码库中被引入和被使用。
比如Log4j被爆出关键漏洞（如 CVE-2021-44228）后，安全应急响应团队需要迅速知道：我们有哪些线上服务的哪些系统和哪些代码库使用了log4j，以及是在哪个版本和分支中，又由哪个部门哪个人负责？
建立开源软件的部署清单（Inventory），也可以理解是建立开源软件的使用地图，其核心是：
不仅要知道引入了什么，还要知道它们最终部署到了哪里。
只有清晰掌握开源软件制品的部署情况，才能合理安排补丁计划、资源调度与优先级排序。
4. 快速修复，缩短窗口（Update It）
这个阶段的核心目标是在开源软件漏洞披露后的72小时内完成漏洞修复，并完成部署和更新。
比如某个开发团队使用了三个含有漏洞的NuGet包，但是全部更新这三个包需要非常大的工作量，因此他们选择先更新部署最为广泛的那个包，以迅速降低整体风险的暴露面。
在完成统一纳入、全面扫描和清单构建工作之后，我们需要基于前面三个阶段构建快速响应能力，从而能够基于漏洞情报、漏洞影响评估和制品分布，快速推动漏洞制品的更新和部署，对于官方的修复方式如果时间允许要尽可能进行patch review，避免无效的、错误的补丁或者不恰当的补丁影响生产环境。
许多漏洞被披露后会在几个小时到几天内就被大规模利用，因此MTTR（平均修复时间）就是漏洞管理的关键指标。
5. 可审计，可追溯（Audit It）
这个阶段的核心目标是确保所有生产环境中的开源软件可追溯，且是通过组织官方认可的供应链流程引入的。
这个阶段中的典型安全风险场景如下：
一位出于好意但不熟流程的开发人员绕过了官方工程流水线，在发布版本中手动更新了某个开源包，结果该版本包含已知漏洞；
一名攻击者通过网络权限故意绕过工程流程，将恶意代码部署到服务中。
在完成了前面的统一纳入、全面扫描、清单构建和快速更新后，当前阶段的工作是建立审计能力，即组织内部必须有能力验证每一个开源软件是否是通过规范流程引入的，是否来自可信来源，是否经过完整记录。这项能力可以确保所有制品必须来自官方的渠道，避免有任何的跳过流程的行为，如果可能，还需要对制品进行哈希校验与签名验证，以及通过SBOM（软件物料清单）建立组件的追溯性。
6. 强制执行，防止绕过（Enforce It）
这个阶段的核心目标是确保组织内所有开源组件的使用都来自受信任的来源，并通过官方推荐的流程进行引入。
在某些情况下，可能会有开发人员绕过了企业内部的工程流程，直接从互联网（如GitHub、npm、pypi）拉取了一个存在已知漏洞的开源包，最终该组件被部署到生产环境中，造成严重安全隐患。
该阶段的工作需要的是技术手段限制的强制执行，不能依赖员工的意识、观念、规则或引导建议，因此需要通过技术手段做到任何开源软件的引入都必须通过企业统一设定的、可控的供应链流程引入，否则CI/CD流水线中的构建和部署则进行阻断，这类限制的技术手段包括但不局限于配置构建流程中的依赖源检查、锁定pip.conf配置文件只允许从受信源拉取、通过DNS解析进行重定向限制只允许访问内部代理的依赖源、通过私有服务器或私有仓库的防火墙建立开源组件来源的防火墙等等。
7. 源码构建，确保可信（Rebuild It）
这个阶段的核心目标是从源代码重新构建每一个部署到生产环境中的开源制品，确保它的产物真实可信、未被篡改。
比如，团队使用了一个看似正常但实际被植入后门的开源包，其二进制内容与公开的源代码不一致。这类后门可能通过传统攻击方式、人为操控、政治施压，甚至恐吓手段植入；又或者，攻击者获得了构建系统的访问权限，在构建过程中篡改了产物，即使源代码是安全的，构建出来的二进制已被投毒，而原作者和使用者都可能毫不知情，比如PHP源代码被植入后门事件。
在此前的实践中，我们默认所有引入的组件都是从“作者发布的二进制包”获取的，然而对于以下两类情况，这种假设已不再安全：
业务关键组件：对稳定性、安全性要求极高的核心依赖；
高价值目标的依赖输入：如金融、能源、政务系统中的第三方组件。
因此，进一步保障供应链安全的措施是为所有关键开源组件构建“从源代码到产物”的完整控制链（Chain of Custody），不再依赖第三方构建环境提供的二进制包，包括：通过官方的源代码进行内部构建、编译，并对编译的制品进行签名、扫描、缓存，并在内部开源软件仓库或组件库进行注册。
8. 及时修复，贡献社区（Fix It + Upstream）
这个阶段的核心目标是当发现某个开源软件存在严重安全漏洞，而上游尚未及时修复时，企业能够在72小时内完成本地修复、构建、部署，并将修复建议以保密方式反馈给上游项目维护者。
在某些情况下，受限于上游项目维护者的精力、能力、热情等原因，当某个开源软件被披露存在严重安全漏洞后，一时之间无法发布修复补丁，这种情况下企业不能坐以待毙，必须进行临时的漏洞修复并部署上线，并尽可能将正式的修复方式通过开源社区反馈给项目维护者。
这种回馈开源社区的行为也是安全工作者的责任与担当，而企业依赖开源软件，也有相应的义务反哺开源社区、维护开源生态的安全和稳定。
实施策略
如何分阶段落地框架？
由于以上八项实践无法同时实施和落地，因此微软建议将八项实践按四个成熟度等级（Level 1-4）逐步推进，这能够让企业根据自身当前的安全实践进行自查、改进和完善。另外，四个成熟度等级同时也展示了在不同成熟度阶段所面临的威胁和要点。
Level 1：基础能力建设
第一级别组织应该具备最基本的开源软件供应链安全能力，主要包括：
使用开源包缓存方案（如私有仓库、本地代理）；
建立开源软件使用清单（Inventory），掌握开源软件制品或组件的分布；
对开源依赖进行漏洞扫描与手动更新。
这是目前软件行业中最普遍具备的开源安全能力组合，也是开源治理的起点。
Level 2：自动化与左移安全能力
第二级别强调“向左移动安全防线”，即更早期地在开发环节实施安全策略。核心能力包括：
加强开源软件引入配置的安全性（如源配置、版本锁定）；
缩短修复时间（MTTR），实现自动化更新流程；
建立基本的事件响应机制，快速识别和响应漏洞事件。
发生在2020年的SaltStack事件（CVE-2020-11651）显示，攻击者在漏洞披露后的3天内就开始大规模利用，而多数企业无法在如此短的时间内完成补丁部署。因此，Level 2的关键目标是：
实现比攻击者更快的修复速度（Patch Faster Than Attackers）。
Level 3：主动防御与源代码审查
第三级别重点在于提前发现风险、提升防御深度。关键能力包括：
在包下载前，对其进行 恶意行为扫描，防止污染引入；
对企业内高频使用的开源组件进行主动安全分析，包括克隆源代码至本地仓库；审查潜在漏洞、逻辑缺陷与隐藏后门；对关键组件执行安全审计与评估。
Level 3的关键目标是从“被动响应”迈向“主动预防”。
Level 4：可信重建与对抗高级威胁
第四级别是最高安全成熟度，旨在对抗最复杂的威胁，如构建阶段攻击（Build Time Attacks），即攻击者并不修改源代码，而是利用构建系统植入后门。
为此，组织必须做到和评估以下几个方面：
在可信环境中，从源码重建所有关键开源软件制品和组件；
验证构建产物是否与源代码一致（可复现性）；
解决构建中的一系列挑战：包括如何命名包以避免与上游冲突？如何确保开发者使用的是内部版本，而不是原始上游包？如何推广修复版本并实现组织内部范围的规模化部署？
Level 4虽然实施成本较高，但对于高度安全敏感的企业（如金融、政务、基础设施），这是对抗高级持续性攻击者（APT）所必须具备的防线。
企业应当如何进行成熟度评估
微软开源软件安全供应链（OSS SSC）框架建议所有组织以整体视角进行成熟度评估，评估范围应覆盖多个开发团队的开源组件使用实践，而不是局限于单个团队。在一个组织内部，不同开发团队的开源使用流程可能存在显著差异，因此应从公司层面评估整体的开源软件引入、管理与安全治理能力。以下是开展 OSS SSC成熟度评估的三个步骤：
第一步：准备评估
首先是理解OSS SSC框架的核心理念，熟悉其八大实践与四级成熟度模型，为后续与开发者、工程师访谈做好准备；接着，选择具有代表性的开发团队样本，确保被访谈团队在业务类型、开发技术、流程成熟度上具备多样性。
第二步：执行评估
在该阶段，你将根据下列问题评估组织在开源软件管理、安全性与使用流程等方面的成熟度水平。以下是建议的访谈问题清单：
你们项目中使用了哪些类型的开源软件？（如：C/C++原生库、NuGet、PyPI、npm 等）
你们是如何将开源软件引入项目的？（如：使用 Azure Artifacts 等包缓存方案、直接使用 curl 或 git clone、将开源软件包提交进仓库等）
你们主要从哪些来源获取开源软件？（如：nuget.org、npmjs.com、pypi.org 等）
项目是否混合使用了内部私有包和外部公共包？（这可能导致依赖混淆攻击）
你们的包源配置文件（如 nuget.config、pom.xml、pip.conf 等）是否配置了多个包源？（同样可能引发依赖混淆）
是否有任何非标准的开源软件引入方式？（如：使用项目的私有 fork、将 Go 组件打包为 NuGet 包等）
是否使用了包锁定文件？（如：packages.lock.json、package-lock.json 等）
团队是如何记录和管理开源软件使用清单的？使用了哪些工具？
团队是如何得知某个组件存在漏洞的？使用了哪些工具或告警机制？
在软件生命周期中哪个阶段会检测出漏洞？（如：发布后？构建中？PR 注释中？）
开源软件漏洞从发现到修复大概需要多长时间？（即 MTTR）
开源软件的更新是人工进行，还是自动化（如使用 Dependabot）？
团队是否进行集成测试，以确认依赖升级不会引入功能性问题？
是否在使用前对开源软件进行恶意软件扫描？
团队是否具备阻止已知恶意包被引入的能力？
是否会将开源软件代码克隆到内部仓库？
是否在使用前对开源软件进行安全审查或静态/动态分析？
是否向上游维护者提交Bug修复或安全补丁？
是否对某些开源软件包进行内部重建？
是否有应对恶意开源组件引入事件的预案或处置手册？
第三步：制定改进计划
根据收集到的访谈结果，可以判断企业当前在OSS SSC框架中的成熟度等级。注意，有些团队可能比其他团队更成熟，因此评估的重点应放在识别短板，发现成熟度落后团队所缺失的能力，而后推动组织内的开源软件使用流程与工具链标准化，最后是分阶段提升制定统一的安全治理目标，按框架等级逐步提升团队能力。
结语
随着供应链攻击日益猖獗，单纯依靠WAF、防火墙等外围防御手段已经无法满足企业对安全的诉求。构建内生安全、可验证、可审计的开源依赖治理体系，才是从根本上提升软件可信性的关键。
微软OSS SSC框架提供了一条清晰的路径，它不仅帮助企业识别开源使用中的盲区，更提供了工具、流程、策略等系统化的落地方案。无论CISO、安全工程师、开发负责人、还是合规经理，这一框架都值得深入学习与借鉴。