跨境合规 · SaaS · 2026 年 5 月

中国 SaaS 的软件供应链安全：美国客户必查的 6 个进入点与 SBOM 实战手册

SOC 2 刚过，美国客户的安全团队又发来三个新要求：提供产品的软件物料清单（SBOM）、说明你怎么监控和修复开源组件漏洞、确认有没有来自实体清单企业的代码。你打开仓库，看到 1400 多个 npm 包，没人知道里面装了什么。这是一份基于 14 家中国 SaaS 客户真实项目整理出来的软件供应链安全实战手册。

本文要点

• 美国客户问「软件供应链安全」时，问的不是一个问题，而是 六类：SBOM、开源依赖治理、构建管道完整性、第三方代码来源、密钥与制品仓库、漏洞响应 SLA
• SBOM（软件物料清单）已经从「加分项」变成「必答项」。美国 14028 号行政令和 NIST SSDF 推动之下，越来越多企业客户把它直接写进采购合同
• 一个典型的中国 SaaS 产品平均依赖 1000 至 1800 个开源组件，其中 60% 到 80% 是你从没主动安装过的「传递依赖」
• 中国 SaaS 在供应链安全上多一道别人没有的题：地缘政治尽职调查。美国客户会问代码在哪里构建、由谁构建。回避不如用构建溯源（provenance）主动回答
• SCA 工具（Snyk、Trivy、Dependabot）能自动化 35% 到 45% 的工作，但 依赖治理策略、漏洞 SLA、构建管道加固仍需人工设计
• 一份两页的「软件供应链安全说明」加可下载 SBOM 放进信任门户，能把供应链相关的问卷题答复时间 从数小时压到数分钟

美国客户的安全团队说「请提供软件供应链安全信息」时，这不是一道题，而是一整张清单。过去两年里，几乎所有美国大企业都把供应商问卷里的供应链部分从两三道题扩展成了独立板块。我们把它归纳成六类。回答之前，先看清楚对方到底在问什么：

这六类问题背后只有一个核心诉求：你能不能证明自己的产品里装了什么，以及当其中一个组件出事时你多快能反应。把它们拆开看你会发现，第 1、4 两类是文档问题，第 2、6 两类是流程问题，只有第 3、5 两类真正需要动技术。中国 SaaS 团队往往一上来就担心要重做 CI/CD，其实六类里有四类靠整理材料和写清流程就能完成。先认清这点，下面五步会轻松很多。

要回答好客户的问题，先得知道攻击者会从哪里下手。软件供应链攻击的逻辑很简单：与其攻破你的产品，不如污染你产品所依赖的某个环节，让恶意代码顺着你的构建管道自己流进去。过去两年里曝光的 xz-utils 后门，攻击者潜伏了两年多，靠的就是污染一个被无数项目间接依赖的压缩库。几年前的 Log4j 漏洞之所以波及面那么广，也是因为它是一个深藏在传递依赖里的组件。下面是六个最常见的进入点：

这六个进入点不需要同时全部加固。我们在 14 个项目里发现，真实发生的供应链事件超过七成集中在进入点 1 和 2，也就是开源依赖本身。所以优先级很清楚：先把依赖治理（第四步）和 SBOM（第三步）做扎实，再处理构建管道（第五步）。如果你的预算和时间有限，把 80% 投在前两个进入点上，是最划算的分配。

SBOM（Software Bill of Materials，软件物料清单）就是你产品的「配料表」。它用机器可读的格式列出产品里每一个软件组件的名称、版本、来源和许可证。两年前它还是个加分项，现在不一样了：美国 14028 号行政令要求向联邦政府供货的软件提供 SBOM，NIST 的安全软件开发框架（SSDF，SP 800-218）把它写进了基线，连带着商业采购方也开始在合同里要求它。我们最近接触的美国中大型企业里，大约一半已经在供应商问卷里明确点名要 SBOM。

好消息是，生成 SBOM 本身并不难。业界两个主流格式分别是 SPDX（Linux 基金会维护）和 CycloneDX（OWASP 维护），美国客户两个都接受。用 Syft 这类开源工具，对着代码仓库或容器镜像跑一条命令，几分钟就能产出一份 CycloneDX 格式的 SBOM。难的不是生成，而是让它持续准确、并知道怎么对外交付。下面是美国 NTIA 公布的 SBOM 最小要素，以及每一项的实务做法：

交付方式上，不要把 SBOM 当成邮件附件来回发。最佳做法是在每次产品发布时由 CI 自动生成一份新的 SBOM，存进信任门户，客户签了保密协议后自助下载。这样它永远是最新的，你也不必每次被问就手动导一遍。把 SBOM 做对，等于一次性回答掉了客户六类问题里的第一类，并为第二类（依赖治理）打好了地基。

一个典型的中国 SaaS 产品平均依赖 1000 至 1800 个开源组件，其中 60% 到 80% 是传递依赖：你从没主动 install 过，是被你装的某个库间接拉进来的。美国客户问「新漏洞出现时你多久能定位并修复」，问的就是你对这一两千个组件有没有治理能力。治理不是「把所有库都审一遍」，那不现实，也没必要。它是建立一套可重复、可被审计师和客户验证的流程。我们用一个四级成熟度模型来定位你现在在哪、下一步该补哪一格：

从 L1 升到 L2 是性价比最高的一步，技术上一两周就能搞定：在 CI 里接入一个 SCA（软件成分分析）工具，让它每次构建都扫一遍依赖。工具不必贵，开源的 Trivy 完全够用，GitHub 自带的 Dependabot 对公开和私有仓库都免费。商业工具如 Snyk 体验更顺、误报更少，按开发者数量计费，小团队一年大概 USD 3,000 到 8,000。但要记住，工具只解决 35% 到 45% 的工作：它能告诉你「这里有个高危漏洞」，但「多久必须修完」「谁来决定能不能延期」「修不了的怎么记录豁免」这些是策略，要人来定。

这是中国 SaaS 比美国本土同行多出来的一道题。美国客户的安全团队，尤其是涉及政府、金融、关键基础设施行业的客户，越来越常问一类问题：你的代码在哪里写、在哪里构建、谁有权限改动构建管道、产品里有没有来自美国实体清单企业的组件。我们的建议很明确：这类问题回避只会让客户更不安，正确的做法是用技术证据把它变成一个可以坦然回答的问题。

技术上的抓手叫「构建溯源」（build provenance）。它是一份由构建系统自动生成、密码学签名的记录，说明这个产物是用哪段源代码、在哪个构建环境、经过哪些步骤产出的。业界用 SLSA 框架（Supply-chain Levels for Software Artifacts）来衡量构建管道的可信程度。你不需要一上来就冲最高级，理解三个等级、先做到中间一级，就足以回答绝大多数客户的问题：

这里要说一句实话：中国 SaaS 在这道题上确实多花功夫，但这不是劣势，反而可以是差异化。我们见过的情况是，主动把构建溯源、第三方组件来源声明、构建管道访问名单整理好的中国 SaaS，给美国客户留下的印象往往比含糊带过的美国本土小厂更专业。客户怕的从来不是「你在哪里」，而是「你说不清楚」。中国国内的 GB/T 36637《ICT 供应链安全风险管理指南》和网络安全法对供应链安全本就有要求，把国内已经做的这部分工作，翻译成美国客户能验证的语言，是这一步的核心动作。

前五步做完，你手里已经有了一堆资产：SBOM、依赖治理流程、漏洞 SLA、构建溯源、组件来源声明。最常见的浪费是把它们散落在各处，每来一个客户问卷就重新翻找拼凑一次。正确的做法是一次性整理成一套标准交付物，放进信任门户，让供应链相关的问卷题答复时间从数小时降到数分钟。下面是六份核心交付物：

把这六份交付物做出来，你就完成了一个身份转换：从「被客户的问卷追着跑」变成「主动递给客户一套完整答案」。美国采购团队对供应商的信任，很大程度来自「这家公司似乎早就准备好了」这种感觉。一份结构清晰的供应链安全说明，传递的不只是合规，而是专业度。这也是为什么我们一直说，供应链安全不是成本，是销售材料。

Atlant Security 如何帮你

中国 SaaS 的软件供应链安全落地

我们专门为 30 至 300 人的中国 SaaS 搭建美国客户认可的软件供应链安全体系。从 SBOM 自动化管道、SCA 工具接入、依赖治理策略、漏洞响应 SLA、构建管道加固，到信任门户的供应链页面，整套交付物一站式完成。中文沟通，按美国合规标准交付，可单独做，也可并入 SOC 2 项目同步推进。

• 固定价格 USD 12,000 起（供应链安全模块，可并入 SOC 2 项目）
• 4 至 8 周交付：SBOM 管道 + 依赖治理策略 + 构建管道加固
• 14 家中国 SaaS 客户实战经验
• 双语供应链安全说明 + 可下载 SBOM 信任门户页
• 交付物上线后付款（首付 30% 启动）

预约 30 分钟咨询 →

软件供应链安全这道题，五年前还只是少数高敏感客户才问，现在已经是美国企业采购的标准动作。对中国 SaaS 来说，它比 SOC 2 多一层地缘政治的考量，但底层逻辑完全一样：你能不能说清楚产品里装了什么，能不能证明它从源码到上线没被动过手脚，能不能在组件出事时按承诺反应。这三个问题答好了，地理位置就不再是客户拒绝你的理由。

真正的好消息是，这套体系是一次性投入、长期复用的资产。第一次把 SBOM 管道、依赖治理、构建溯源、信任门户搭起来，通常需要 4 至 8 周。搭好之后，它每次产品发布自动更新，每来一个新客户的供应链问卷，你只需要把信任门户的链接发过去。把第一次的骨架搭对，后面每一笔美国合同都会因此走得更快。

想聊聊你公司的具体情况？预约 30 分钟咨询，或直接发邮件给 alexander@atlantsecurity.com。