Cursor 扩展市场中被篡改的 Claude Code 扩展，以及 Polymarket 上被劫持的供应商脚本，两起事件相隔仅几个小时。
10 月 29 日，两个截然不同的地方相隔几个小时先后出了问题。
上午，Cursor 的扩展市场开始分发一个被篡改的 Claude Code 扩展副本。其中几乎每个字节都是 Anthropic 的真实代码，只多了一个安装 SSH 后门的小型加载器。
当天下午，Polymarket 从其供应商 DebugBear 加载的一个性能监控脚本被替换。它不再测量页面速度，而是利用已登录交易者的会话卖出他们的持仓并转移他们的资金。分析人员追踪到约 $2.57 million 流入了攻击者的钱包。
没有人安装任何可疑的东西。开发者接受了一个熟悉扩展的更新，交易者打开了他们一直在用的网站。标签没有错，只是配方变了。
因此，本期要问的是：当别人可以改变“可信来源”所交付的内容时，“可信来源”还意味着什么？深度解析探讨扩展市场除了发布者名称之外还必须检查什么，技术研究则解释 Polymarket 钱包盗取脚本如何复用了页面自身的交易客户端。
本期内容
🌡️ 威胁等级：高度警戒
⚡ 新闻：FBI 将 Binance 被盗案归咎于朝鲜，LiteLLM 和 OVHcloud CLI 的发布版本遭调包，Storm-0940 借助一家备份供应商攻击 Microsoft 365 租户
🔎 深度解析：发布者是合法的，更新却遭到了篡改
🎣 这是钓鱼吗？
🔬 技术研究：它先测量页面速度，然后卖掉了您的持仓
🛠️ 本周工具：osquery
👏 本周人物：Paul McCarty
📅 本周活动：Open Source SecurityCon 2026
📚 本周书籍：Software Supply Chain Security
😅 本周梗图
❓ 离开前的一个问题
让我们开始吧。
🌡️威胁等级
⚡第 01 部分：新闻
加密货币，超大号
FBI 将 $6.3 billion 的 Binance 被盗案归咎于朝鲜
Binance 已确认被盗约 $6.3 billion，这是有记录以来规模最大的加密货币盗窃案。区块链情报公司 TRM Labs 和 Chainalysis 将其归因于朝鲜组织 TraderTraitor。10 月 31 日，FBI 证实了这一归因，并指出正是同一批人在 2025 年制造了 $1.5 billion 的 Bybit 黑客事件。
早期报道将事件归咎于一台被入侵的笔记本电脑。Binance 此后表示，其调查发现了更多的入侵点，入口至今仍不明确。Binance 称已用公司资金补足了约 90% 的被盗资金，Tether 则表示已冻结与此次盗窃相关的约 $1.57 billion 资产。
据 FBI 称，大部分被盗资产正在被转换为以太币（ether），预计其余资产将通过 DeFi 平台和即时兑换服务转移。
为什么重要：上一个纪录 Bybit 案正是由同一组织在不到两年前创下的，而这次盗窃的规模大约是它的四倍。TraderTraitor 并不是一个偶然走运一次的投机团伙，而是一个国家级单位，总能找到办法渗入持有最多资金的公司。
看看哪些能被阻止，哪些不能。Tether 之所以能冻结 $1.57 billion，是因为 Tether 可以冻结自己发行的代币。而以太币没有发行方可以求助。攻击者每多花一小时把被盗代币换成无人能冻结的资产，可追回的部分就少一分，这也是转换工作早已开始的原因。
关于入口的说法不断变化，这一点同样重要。“一台被入侵的笔记本电脑”是一个干净利落的解释，但它是错的，至少是不完整的。大型泄露事件的早期解释往往如此。在完整路径查明之前，没有人能说清是哪些控制措施失效了。
如果您在加密货币或金融科技领域工作，或与之相关，请将 TraderTraitor 有据可查的作案手法视为直接威胁：冒充招聘人员、居家编程测试，以及针对工程师的恶意软件包。让签名基础设施远离工程师日常使用的笔记本电脑，并在需要冻结之前（而不是之后）就与稳定币发行方建立联系。
阻止盗窃是第一道防线。一旦代币变成以太币，第二道防线的窗口就关闭了。
FBI 归因（BleepingComputer） · TRM Labs 和 Chainalysis 的归因 · Binance 调查进展（ITPro）
发布版本，回锅加热
LiteLLM 和 OVHcloud CLI 的发布版本被调包为密钥窃取程序
10 月 21 日，攻击者在获取 GitHub CLI 的 OAuth 令牌后，将 LiteLLM 1.107.0 版本的恶意构建发布到 PyPI，同时发布了被篡改的容器镜像。LiteLLM 是一个被广泛使用的网关，连接应用与 AI 模型提供商。PyPI 上的暴露窗口约为两小时。Microsoft 的分析发现，恶意载荷通过 Python 启动钩子运行，因此一台机器即使只是安装了该软件包、从未导入它，也可能泄露密钥。
两天前的 10 月 19 日，一名攻击者利用被劫持的贡献者账户，将 GitHub 上五个 OVHcloud CLI 发布版本（v0.11.0 至 v0.15.0）的下载文件替换为窃取密钥的构建，持续时间最长达 94 分钟。攻击者从未触及 OVHcloud 的构建流水线。由于发布不可变性（release immutability）功能处于关闭状态，这些文件可以被直接替换。OVHcloud 删除了这些文件，以不可变发布的形式发布了干净的 v0.16.0，并开启了该设置。
为什么重要：在这两起事件中，攻击都发生在最后一步：人们下载的发布版本。OVHcloud 的攻击者完全没有触碰构建流水线，而 LiteLLM 的构建则是用窃取的令牌发布的。审查源代码或加固 CI 都无法发现其中任何一起。
短暂的窗口并不像听起来那样令人安心。两小时和 94 分钟对人来说很短，但拉取最新版本的 CI 流水线一直在运行。而对于 LiteLLM，安装就已足够。每一台拉取了 1.107.0 的构建运行器和笔记本电脑都交出了其持有的所有密钥，其中包括 AI 网关本就负责管理的 API 密钥。
OVHcloud 事件还表明攻击者能等待多久。正如 Paul McCarty 所发现的（详见本期的本周人物），用于调包发布版本的账户早在七个月前就已被入侵。被盗的开发者凭据不会因为还没人使用就自动失效。
按哈希值而不仅仅是按版本号锁定依赖，并在可行的情况下，等待几天再采用全新的发布版本。如果您维护着一个项目，请开启不可变发布并使用短期有效的发布令牌。如果您在暴露窗口内安装过其中任一工具，请在一台干净的机器上轮换该机器可访问的所有密钥。
干净的代码仓库告诉您维护者写了什么，却无法告诉您您下载的是什么。
LiteLLM 遭入侵（SecurityWeek） · OVHcloud CLI 遭入侵（SecurityWeek） · 与 GlassWorm 的关联（Dark Reading）
备份服务，附赠访问权限
Storm-0940 利用一家备份供应商的应用访问权限攻击 2,250 个 Microsoft 365 租户
ConnectWise 于 10 月 16 日披露其 Cloud Backup 服务（前身为 SkyKick）遭到入侵。10 月 21 日，Microsoft 将后续活动归因于与中国有关联的组织 Storm-0940。
Cloud Backup 让 IT 服务提供商能够备份其客户的 Microsoft 365 数据，因此它的应用早已在这些租户中获得了授权同意。攻击者利用这些应用的身份，尝试登录超过 2,250 个租户。Microsoft 表示，大多数尝试都失败了，但该组织仍在一些组织中获得了特权持久化访问，有些情况下距首次攻击不到三小时。中国否认了这些指控。
为什么重要：没有用户遭到钓鱼，也没有跳过任何 MFA 提示，因为整个过程根本不涉及这些。应用使用自己的密钥或证书登录，而在许多租户中，登录策略和告警都是围绕人来设计的。应用登录往往游离于两者之外。
访问权限本身就是战利品。备份应用需要读取整个租户中的邮件、文件和站点，这恰恰是攻击者想要的访问权限。管理员授予一次的同意，就可能覆盖一切。
“大多数尝试都失败了”也不足以令人宽心。服务提供商模式意味着一家供应商连接着数千个租户，因此即使成功率很低，累积起来也相当可观。而从首次尝试到实现持久化不到三小时，留给响应的时间所剩无几。
持久化是比修复更持久的部分。一旦攻击者掌握了特权访问，就可以添加自己的凭据、应用或角色分配。移除供应商的应用并不会移除其中任何一项。
审查哪些第三方应用在您的租户中拥有授权同意，以及它们拥有哪些权限。检查应用登录日志，查找自 10 月中旬以来新增的凭据、应用或角色分配。如果您的租户由服务提供商管理，请直接询问他们是否使用过 Cloud Backup。
撤销供应商的访问权限是简单的一步。真正有用的问题是：在它拥有访问权限期间，被添加了什么。
🔎第 02 部分：深度解析
发布者是合法的，更新却遭到了篡改
10 月 29 日从 Cursor 扩展市场安装 Claude Code 扩展的开发者，做的正是别人告诉他们该做的事。他们使用编辑器内置的商店，选择了知名发布者的扩展，并接受了更新。在大约 11 个小时里，这样做就足以被植入一个 SSH 后门。
发布者是真的，商店也是真的。变化的是两者之间的软件包，尽管有分发控制措施，被篡改的软件包还是到达了用户手中。
发生了什么
Cursor 表示，一名恶意行为者“利用对 Cursor 扩展市场的访问权限，发布了一个针对 Cursor 用户的篡改扩展”。被篡改的构建是适用于 Windows 和 macOS 的 2.1.312 和 2.1.313 版本，在太平洋时间凌晨约 2:27 至下午 1:35 期间可供下载，最多影响了 5,000 名用户。Cursor 删除了这些版本，暂时关停了整个扩展市场，审计了访问权限并轮换了密钥。
Anthropic 表示，其官方渠道上的版本不受影响，2.1.313 从未发布到 Open VSX、Microsoft Visual Studio Marketplace 或其任何官方托管平台，此次事件“并非 Anthropic 系统或员工笔记本电脑遭到入侵”。它随后发布了干净的 2.1.314。两家公司都没有说明攻击者是如何获得发布权限的。
被篡改的构建做了什么
根据 StepSecurity 的分析，攻击者拿到 Anthropic 干净的 2.1.312 构建，在其 extension.js 开头插入了一个 7,386 字节的加载器。文件的其余部分与原始文件一致。该加载器没有经过混淆，扩展一加载就会在普通 Node.js 下运行，无需任何 Claude 对话。
它分六个阶段运行：收集主机信息以及匹配 KEY、TOKEN、AWS 等模式的环境变量名称；将一个标记为 svc-telemetry 的 SSH 密钥添加到 ~/.ssh/authorized_keys；开启 SSH；建立到 134.209.82.225 的反向隧道；设置持久化（在 macOS 上是名为 com.apple.sysmond 的 LaunchAgent，在 Windows 上是名为 SysMon 的计划任务）；并向攻击者的服务器报告状态。
移除扩展并不会清除其中任何一项。
扩展市场除了发布者名称之外还必须核实什么
商店里的条目告诉您原始代码是谁写的，却无法告诉您这个特定的软件包是谁构建或上传的。Cursor 事件指向三项单凭名称无法替代的检查。其中两项只检查版本号，可以发现伪造的 2.1.313。只有第三项检查内容，也只有它还能发现被篡改的 2.1.312，因为后者带着一个真实的版本号。
1. 这个版本在源头存在吗？2.1.313 版本从未通过 Anthropic 的任何官方渠道发布。一个分发他人扩展副本的商店，可以拒绝任何发布者从未发布过的版本。这能发现 2.1.313，但发现不了被篡改的 2.1.312 副本，因为这个版本确实存在。
2. 软件包内部是否自洽？“2.1.313”的代码包在内部仍然报告 version:”2.1.312”。只有重新打包的清单文件带有更高的版本号，而这足以让编辑器将其视为一次更新。清单文件与其中代码之间的不一致很容易检测，也是重新打包的强烈信号。同样，这只在攻击者提高版本号时才有用。
3. 这是发布者真正的构件吗？这是能同时覆盖两个版本的检查。被篡改的 2.1.312 与 Anthropic 真正的 2.1.312 之间只差一个文件顶部的一段代码，它会启动 ssh、写入 authorized_keys 并创建启动项。将每个软件包的哈希值与发布者自己的发布版本进行比对，并将更新与上一版本进行差异比较，查找新增的进程执行、网络隧道或持久化行为，这样关注的是软件包是什么，而不是它叫什么。
发布者签名是完成第三项检查最干净的方式，但前提是签名来自发布者本人。如果商店自己重新签名或重新托管软件包，有效的签名只能证明是商店分发了它。
两条相互竞争的时间线
攻击者只需要几分钟：自动更新送来了加载器，它在加载时就运行了。防御者则花了大约 11 个小时才下架这些版本，而且每位受影响的开发者仍需清除持久化、在干净的机器上轮换所有凭据，并决定是否重建系统。自动更新让大多数开发者保持最新补丁，因此关闭它并不是答案。检查它安装了什么才是。
四项优先事项
对于安全团队：了解您的开发者使用哪些编辑器，以及每个编辑器从哪个扩展市场拉取扩展。在具有生产环境访问权限的机器上，对扩展实行白名单或版本锁定，并将这些笔记本电脑视为具有生产访问权限的设备，配以相应的监控。准备好扩展事件应急预案：检查持久化，在干净的机器上轮换凭据，有疑问时就重建。
对于扩展市场运营方：在分发每个软件包之前，将其内容与发布者自己的发布版本进行核对，而不仅仅是核对版本号。拒绝发布者从未发布过的版本和清单不一致的软件包，并审查新增功能的更新。像保护生产部署密钥一样保护发布权限。
对于扩展发布者：公布一份清晰的官方分发渠道清单，并附上商店和用户可以核对的哈希值或签名。当出现被篡改的副本时，要迅速、明确地说明真正的版本在哪里，就像 Anthropic 这次所做的那样。
对于开发者：在任何扩展安全事件之后，将您已安装的版本与发布者自己的发行说明或更新日志进行比对，并检查您实际安装扩展所用的扩展市场。如果您的版本不在发布者列出的版本中，请将该机器视为已受影响。
问题的核心矛盾
在那些机器上运行的代码几乎全部来自 Anthropic。开发者被训练去信任的每一个信号，包括名称、商店和熟悉的更新提示，都指向了正确的方向。
在商店能够证明它们分发的内容就是发布者真正发布的内容之前，“它来自官方扩展市场”只能说明软件包从哪里来，却无法告诉您它是什么。
🎣第 03 部分：这是钓鱼吗？
合法还是钓鱼？
🔬第 04 部分：技术研究
它先测量页面速度，然后卖掉了您的持仓
10 月 29 日，Polymarket 从其供应商 DebugBear 加载的性能监控脚本被替换。新文件并没有窃取密码或密钥，而是找到每位已登录交易者浏览器中已经在运行的交易客户端，并用它清空了交易者的账户。
研究人员恢复了该脚本，它是未经混淆的普通 JavaScript，因此很容易看清它的工作方式。本文的拆解参考了以下来源的分析：ohey.ca、Report URI 和 Dancho Danchev。
事实
Polymarket 的页面从 cdn.debugbear[.]com 加载 DebugBear 的真实用户监控（RUM）脚本，且没有进行完整性校验。大约 UTC 时间 16:54，响应该 URL 的服务器发生了变化：响应头从 Google Cloud Storage 的样式变成了 nginx 风格，文件也变成了钱包盗取程序。DebugBear 后来表示，攻击者入侵了其 DNS 记录。Polymarket 在 UTC 时间 17:59 的一次构建中移除了该脚本，并在几分钟后进入仅限取消订单模式。
BleepingComputer 追踪到约 $2.57 million 流入了攻击者的钱包，GoPlus Security 统计约有 700 个充值钱包受到影响。Polymarket 表示“我们的一家第三方服务提供商遭到了入侵”，并将全额赔偿受影响的交易者。
钱包盗取程序如何运作
1. 找到已登录的交易者。该脚本读取 Polymarket 自身应用写入 localStorage 的三个键：polymarket.auth.params（登录类型和钱包）、polymarket.auth.proxyWallet（充值钱包）和 poly_clob_api_key_map（交易 API 凭据）。没有会话，就没有攻击。它还调用了 Polymarket 自己的 /api/geoblock 端点，跳过被禁止交易的访问者。
2. 借用页面的交易客户端。该脚本自身不携带任何密钥。它遍历 React 的内部组件树，通过 React 附加在 DOM 元素上的 __reactFiber$ 属性，寻找一个同时具有 postOrder 方法以及 createOrder 或 createMarketOrder 方法的对象。这个对象就是 Polymarket 正在运行的订单客户端，连同用户的签名器一并可用。简化后的搜索逻辑如下：
// Simplified illustration of the technique, not the attacker's exact code
for (const el of document.querySelectorAll("*")) {
const key = Object.keys(el).find(k => k.startsWith("__reactFiber$"));
// walk el[key] and its parents, return the first object that has
// postOrder() and createOrder(), plus a signer
}如果客户端尚未就绪，它会每隔 250 ms 重试一次，共重试 15 次，然后重新加载页面，迫使应用创建一个客户端。
3. 加载配置。它向 data.debugbear[.]com/metrics/init 请求指令。该端点在攻击期间返回 404，因此运行的是硬编码的默认配置：
return{recipient:N,minimalPerPosition:10,minimalToProcess:10,priorityToken:"POL"}N 是攻击者的 Polygon 地址 0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18。价值低于 $10 的账户不受影响。
4. 先上报账户信息。在转移任何资产之前，它会将投资组合价值、现金余额和每一个持仓，连同钱包、登录类型、操作系统、IP 和国家，一并发送到 /metrics/submit。
5. 通过两种方式清空账户。对于浏览器钱包用户，它会构建一个 EIP-712 批处理，通过一次 safeBatchTransferFrom 调用把价值高于 $10 的所有持仓转给攻击者，并通过 Polymarket 自己的中继器提交。这个批处理会以钱包签名请求的形式出现，因此这些用户必须批准它。邮箱登录账户则走另一条路径，不会出现钱包提示：它用立即成交否则取消（fill-and-kill）订单卖出持仓，价格依次为 97%、50%，再到最小价格单位，然后把现金全部转走。
6. 套现。它使用 Polymarket 自身前端中的 API 密钥，通过 fun.xyz 将现金兑换为 POL，并把攻击者设为接收方。每笔转账都会连同交易哈希一起上报到 /metrics/update 或 /metrics/handle。
边界在哪里失守
每一步用到的都是 Polymarket 页面合法拥有的东西：它的存储键、订单客户端、中继器，以及兑换服务提供商的 API 密钥。第三方脚本以加载它的页面的全部权限运行，因此监控脚本和交易界面实际上是同一个程序。
Polymarket 的内容安全策略（CSP）也没能起作用，因为盗取程序使用的每个主机都已在允许列表中。script-src-elem 允许 cdn.debugbear[.]com，connect-src 允许 data.debugbear[.]com、*.polymarket.com、*.alchemy.com 和 *.fun.xyz。正如 Report URI 所说：“无论如何，什么都不会被拦截。”
页面信任的是一个 URL，而不是一个文件。URL 从未改变，因此 Polymarket 这边无需任何改动，攻击就能得逞。
分步攻击链
[DebugBear URL now serves drainer] -> [polymarket.com loads it, no SRI]
-> [Reads localStorage: login, wallet, CLOB keys] -> [Finds React order client + signer]
-> [Reports portfolio to /metrics/submit] -> [Sells or batch-transfers positions]
-> [Swaps cash to POL via fun.xyz] -> [Attacker wallet] 防御者应从中汲取什么
使用子资源完整性（SRI）锁定第三方脚本：被篡改的文件与干净文件（0525f046…）的哈希值不同。在 script 标签上加一个 integrity 属性，浏览器就会拒绝运行它。如果供应商的脚本变化太频繁、无法锁定，就改为自行托管一份经过审查的副本。
不要把 CSP 允许列表当作完整性保障：CSP 控制的是代码从哪里加载，而不是代码是什么。添加基于哈希的控制和一个上报端点，这样即使脚本的主机在允许列表中，脚本一旦发生变化也会触发告警。
让监控脚本远离能够转移资金的页面：RUM 和分析脚本很少需要在用户可以交易或提现的页面上运行。把它们放在营销页面上加载，或者放在无法访问应用状态的沙箱 iframe 中。
高价值操作需要用户重新确认：卖出全部持仓或转移资金，应当需要用户主动给出的确认，最好使用通行密钥（passkey）或硬件安全密钥等抗钓鱼的身份验证器，这样已经在页面中的代码就无法悄无声息地完成这些操作。
对不可能出现的行为发出告警：数百个账户在几分钟内集中清仓就是一个信号。要有办法迅速暂停高价值操作，就像 Polymarket 启用仅限取消订单模式那样。
🛠️第 05 部分：本周工具
您能在几分钟内检查每台开发者笔记本电脑上是否存在同一个后门吗？
当 Cursor 扩展这样的事件发生时，问题不只是“我们安装了它吗？”，而是“它留下的东西还有没有残留？” osquery 能同时在大量机器上回答这类问题。
osquery 是一款开源工具，最初由 Facebook 开发，现由 Linux Foundation 托管，它把操作系统呈现为一组数据库表。您不必为每种操作系统编写不同的脚本，而是用 SQL 提问：哪些 SSH 密钥已获授权，存在哪些 LaunchAgent 和计划任务，哪些进程正在运行以及它们连接到哪里。
# Quickstart (macOS)
brew install --cask osquery
osqueryi-- macOS: look for the LaunchAgent named in the Cursor incident
SELECT label, path, program_arguments FROM launchd WHERE label = 'com.apple.sysmond';
-- Windows: look for the SysMon scheduled task and the Startup folder fallback
SELECT name, action, path, enabled FROM scheduled_tasks WHERE name LIKE '%SysMon%';
SELECT name, path FROM startup_items WHERE name LIKE '%sysmon%';
-- macOS and Linux: list authorized SSH keys for every local user, and look for svc-telemetry
SELECT u.username, k.key_file, k.comment
FROM users u JOIN authorized_keys k USING (uid);
-- Windows: no authorized_keys table, so find the key files and open them
SELECT path, mtime FROM file
WHERE path LIKE 'C:\Users\%\.ssh\authorized_keys'
OR path = 'C:\ProgramData\ssh\administrators_authorized_keys';Windows 上不存在 authorized_keys 表。在 Windows 上，上面的查询只能找到密钥文件，因此请逐一检查其中是否有 svc-telemetry 密钥，或者从您的配置管理清单中提取这些文件。
了解它无法告诉您什么。osquery 展示的是机器当前的状态。它无法告诉您攻击者已经用窃取的凭据做了什么，清理之后得到干净的结果也不代表什么都没被拿走。用它快速找出受影响的机器，然后轮换凭据，并在隧道已建立连接的机器上进行重建。
👏第 06 部分：本周人物
Paul McCarty
本周我们要介绍的是 Paul McCarty，他是 OpenSourceMalware 的创始人。这是一个开放的、由社区驱动的数据库，收录了在 npm、PyPI、RubyGems 和 Open VSX 等软件包仓库中发现的恶意软件包。
当一个软件包或扩展变成恶意的，防御者需要尽快知道：哪些版本、哪些指标，以及同一攻击者以前是否做过类似的事。OpenSourceMalware 将这些威胁情报公开，任何人都可以查询可疑的软件包，而不必等待供应商的报告。
他的工作也出现在本期的新闻中。在 OVHcloud CLI 遭入侵后，McCarty 将此次攻击与 GlassWorm 攻击活动联系起来，依据是早先 GlassWorm 行动中使用过的一个 Solana 钱包地址，他还发现用于调包发布版本的开发者账户早在七个月前就已被入侵。
感谢他公开追踪恶意软件包，让每一位防御者都能利用这些发现，Paul McCarty 当选本周人物。 👏
📅第 07 部分：本周活动
Open Source SecurityCon 2026
Open Source SecurityCon 是由云原生计算基金会（CNCF）和开源安全基金会（OpenSSF）联合主办的为期一天的活动，与 KubeCon + CloudNativeCon North America 同期举行。
其议程涵盖供应链安全、安全软件开发、身份与访问、架构与策略，以及开源公共政策。OpenSSF 和 CNCF 是许多用于验证您所安装内容的工具的大本营，包括 TUF、in-toto 和 Sigstore，因此构建软件包签名和构建验证的人们会在这里交流心得。
📍 美国犹他州盐湖城（Salt Palace Convention Center）📅 2026 年 11 月 9 日
📚第 08 部分：本周书籍
所有您没写、却仍在交付的东西
Software Supply Chain Security: Securing the End-to-End Supply Chain for Software, Firmware, and Hardware，作者 Cassie Crossley，介绍组织所依赖却并非自己构建的代码、组件和服务。
Crossley 带领读者走完整条链条，从您所依赖的组件和工具，到软件如何构建、签名、分发和更新，以及攻击者可以在哪些环节介入。书中涵盖软件物料清单（SBOM）、构建完整性和供应商风险等实用控制措施，而且是写给那些必须真正落实这些控制措施、而不只是谈论它们的人。
如果您想梳理自己交付却并非自己编写的代码，Software Supply Chain Security 是一个很好的起点。
😅第 09 部分：本周梗图
如果您的某个供应商脚本或某位开发者的扩展今天早上发生了变化，您会如何发现？
本期就到这里。检查您的扩展，列出您的第三方脚本，我们下期再见。
The Breach Brief，Ostorlab 团队