PyPI/npm 投毒的防御与检测技术合篇：从 SBOM、SLSA 到 LLM Agent 的两条腿走路

这是一篇写给资深安全开发与架构读者的研究合篇。它把开源包投毒（Package Poisoning）的对抗体系拆成对称的两条路径：上半篇是"防御"——围绕开发者、CI、注册中心和签名/锁文件等机制，目标是收紧攻击面、让恶意发布无法发生或无法被信任；下半篇是"检测"——围绕静态规则、动态沙箱、ML/LLM 模型、信誉系统和依赖图分析，目标是在已发生发布之后及时识别、拦截、追踪。两条腿缺一不可：单靠 SLSA、签名、Trusted Publisher 解决不了 合法账号被钓鱼 的问题（参见 Shai-Hulud¹、ua-parser-js²）；单靠 GuardDog、Package Analysis 又拦不住 精心规避沙箱、延迟激活 的样本。本文把每个机制写到"原理 / 在 PyPI、npm 的具体落地形式 / 局限性 / 一条权威 URL"四元组级别，并在 ML/LLM 检测一节单独索引 16 篇代表论文（USENIX、S&P、ICSE、ASE、TOSEM、IST 等），便于把它当作研究入口。

上半篇：体系化防御

体系化防御要解决的问题从来不是"如何让投毒变成零"，而是"如何让一次投毒事件被尽早发现、影响范围尽量收窄、责任链路可被审计"。八个机制按照"声明 → 来源 → 身份 → 还原 → 隔离 → 构建 → 凭证 → 流程"递进排列。

1. SBOM：CycloneDX 与 SPDX

定义与原理。Software Bill of Materials（SBOM）是软件构成的机器可读清单，列出所有组件、版本、许可证、依赖关系，并可选地附带哈希、PURL、CPE 等标识。它是供应链安全的"事实底稿"——后续所有签名、漏洞匹配、VEX 适用性判断都建立在 SBOM 提供的"清单一致性"之上。两大主流标准并行：

• CycloneDX：由 OWASP 维护，已成为 Ecma International 标准 ECMA-424；2025 年 1.7 版本扩展了专利/IP 元数据、数据溯源引用、加密透明度（CBOM, Cryptography BOM）和 formulations 范围；安全与漏洞模型（VEX、VDR）原生内嵌³。
• SPDX：由 Linux Foundation 维护，已成为 ISO/IEC 5962:2021；强项在许可证合规与法律级深度文档⁴。

在 PyPI、npm 的落地形式。npm 侧通过 @cyclonedx/cyclonedx-npm 扫描 package-lock.json 生成 BOM；GitHub dependency-graph-action 直接产出 SPDX；多生态通用扫描器使用 syft、cdxgen。Python 侧 cyclonedx-python 解析 venv、requirements.txt、Poetry/Pipenv lock。识别符层面，CycloneDX 通常使用 pkg:npm/<name>@<version>、pkg:pypi/<name>@<version> 这样的 PURL（Package URL），与 deps.dev、OSV 数据库直接对接。NTIA 在 2021 年正式发布了 SBOM 最低要素清单（component name、supplier、version、unique identifiers、dependency relationships、SBOM author、timestamp），是国内外监管引用的事实基线⁵。

局限性。第一，SBOM 只描述"有什么"，不验证"完整性"——必须配合 in-toto/Sigstore attestation 才能防伪造。第二，依赖图深度大时极易漂移，lockfile 与 SBOM 不一致是常态。第三，post-install 阶段动态下载二级 payload（npm postinstall、PyPI setup.py）完全在 SBOM 视野之外。第四，VEX 适用性的下游消费者实践仍然不成熟，导致漏洞信噪比高、SBOM 在企业内常常被简化成一份"为了合规存档的 JSON"。

权威文档：CycloneDX 规范总览 https://cyclonedx.org/specification/overview/ 。

2. SLSA v1.0 框架

定义与原理。SLSA（Supply-chain Levels for Software Artifacts，读作 "salsa"）由 OpenSSF 主导、Google 倡议，是描述并增量提升供应链安全的规范。v1.0 在 2023 年 4 月 GA，相对于 v0.1 的关键变化是把若干跨域要求拆分为多个 Track：当前只有 Build Track 正式发布，Source Track、Dependencies Track 仍处于 Working Draft 状态⁶。SLSA 的核心抽象是 provenance——一份机器可读的"构建证词"，绑定到产物哈希，描述"由谁、用什么源代码、用什么构建器、用什么参数构建出来"。

v1.0 Build Track 各级要求：

在 PyPI、npm 的落地形式。npm 自 2023-10-03 GA 的 npm provenance：在 GitHub Actions 中执行 npm publish --provenance --access public，由 GitHub OIDC token 换取 Sigstore Fulcio 短期证书，签发 SLSA v1.0 provenance 后写入 Rekor 透明日志；npm registry 校验通过后在包详情页打"Built and signed on GitHub Actions"绿标，对应 SLSA Build L2⁷⁸。PyPI 侧通过 Trusted Publisher (OIDC) 机制实现近似 L2 等级；2024 年起 PyPI 支持 PEP 740 attestations，由 Sigstore 签发并存入 Rekor，下载方可用 pypi-attestations 工具验证⁹。

局限性。L3 要求的强化构建器在工程上昂贵，社区开源维护者很难达到。Build Track 只覆盖构建——源代码篡改 （恶意 PR、维护者账号被盗、typosquatting）需要 Source Track，但它仍是 Draft。Provenance 真实性传递依赖于 OIDC 提供商和透明日志的整体可信，存在单点假设。验证侧分散是另一个难题：消费者主动验证 provenance 的比例非常低，绝大多数下游仍只看"包能否下载"。

权威文档：SLSA v1.0 等级要求 https://slsa.dev/spec/v1.0/levels 。

3. 包签名：Sigstore / cosign / npm provenance / PyPI Trusted Publisher

定义与原理。Sigstore 是 Linux Foundation/OpenSSF 的项目，目标是 "keyless signing"——开发者不再管理长期私钥，而是用 OIDC 身份临时换取 ~10 分钟有效的短期证书签名。三组件：Fulcio（短期 X.509 CA）、Rekor（仅追加的公共透明日志，类似 CT log）、cosign / sigstore-js / sigstore-python（CLI 与 SDK）¹⁰。

在 PyPI、npm 的落地形式。

• npm provenance（2023 GA）：CI 中由 OIDC token 换取 Fulcio 证书并签发 SLSA provenance，写入 Rekor；包详情页 sidecar 含 SLSA Subject / Builder / Source Repo。生成的两类 attestation：(a) 由发布者 CI 签出的 provenance（SLSA v1.0 statement），(b) 由 npm registry 在收到包时额外签发的 publish attestation，二者共同构成可验证链路⁷⁸。
• PyPI Trusted Publisher（OIDC）：消除长期 API token，CI 通过 OIDC 交换短期 token 上传，支持 GitHub Actions、GitLab CI、Google Cloud Build、ActiveState；配合 PEP 740 自动生成 attestation⁹。
• cosign 验证 npm provenance bundles（2024 起）：cosign verify-blob --bundle <bundle> 可独立验证，便于离线审计与第三方注册中心透传¹¹。

局限性。Sigstore "keyless" 把信任根迁移到了 OIDC 提供商：GitHub Actions 配置错误（如可重用 workflow 的凭据滥用）会导致冒名签名。Rekor 自身是 SaaS 公共服务，可用性与抗 DoS 能力是供应链潜在脆弱点。npm provenance 当前非强制，覆盖率仍低（截至 2024 年估算约 5–10% 下载量），生态尚处早期阶段。中国大陆访问 Sigstore Public Good 实例延迟较高，私有部署 Fulcio/Rekor 的运维成本不低。最关键的是——签名只证明"谁发布"，不证明"代码安全"，恶意维护者签出的合法签名包仍然合法，这一点在 ua-parser-js² 与 Shai-Hulud¹ 这类"账号妥协"事件中尤为致命。

权威文档：Sigstore 官方文档 https://docs.sigstore.dev/ 。

4. 锁文件演进：从 package-lock 到 pylock.toml

定义与原理。锁文件冻结整个依赖图（直接 + 传递），通常包含包名、精确版本、解析源（registry URL/Git/本地路径）以及完整性哈希（integrity hash）。安装器在还原时校验哈希，防止"幽灵替换"——攻击者在 registry 上对同一版本号做重打包/重发布。

npm 生态。package-lock.json（npm v5+）含 integrity 字段（sha512 base64，SRI 算法）；yarn.lock（Yarn classic / Berry）含 checksum 与 resolution；pnpm-lock.yaml 默认硬链接到 content-addressable store，整体由 npm ci/yarn install --frozen-lockfile/pnpm install --frozen-lockfile 严格校验¹²。

Python 生态。

• pip install --require-hashes：要求 requirements.txt 每行 --hash=sha256:... 锁定每个 wheel/sdist，缺一拒装¹³。
• PEP 665（已 rejected/superseded）：早期对 pyproject 锁文件标准的尝试。
• PEP 751（2024 接受、2025 实施）：标准化 pylock.toml（TOML 格式），统一 PDM、pip-tools、Poetry、uv 等工具输出；包含包名、版本、wheel 文件级 hash、marker、source 来源¹⁴。
• Poetry：poetry.lock 自有格式（*package* + files 表，每文件 hash）；Poetry 团队曾表示不会原样支持 PEP 751，原因是 PEP 751 要求文件级精度而 Poetry 同时支持 sdists/VCS/dir 依赖。
• uv（Astral，2024 出品的 Rust 实现 Python 包管理器）：性能优先的 uv.lock，已支持 PEP 751 导出¹⁵。

局限性。第一，锁文件只防"同名异内容"（重打包、registry 入侵），完全防不住"开发者主动加恶意代码"——合法签名 + 锁定后仍能投毒。第二，维护者升级时若不审 diff 即接受新 hash，等于自废武功。第三，CI 中误用 npm install（而非 npm ci）会无声更新 lockfile。第四，pip install 默认不强制 hash 校验，需要项目方主动启用 --require-hashes。第五，跨平台环境（manylinux/musllinux/Windows）需要为同一逻辑依赖记录多份 wheel，PEP 751 已设计 marker，但实际工具链支持仍不完整。

权威文档：PEP 751 https://peps.python.org/pep-0751/ 。

5. 私服与制品库：Verdaccio、Nexus、Artifactory、devpi

定义与原理。在企业/可信网络内运行的包仓库，通常以 proxy/cache + hosted/private + virtual aggregation 三种模式工作。它的供应链价值有四个：(a) 缓存上游、(b) 限制可拉取的上游集合（白名单/黑名单）、(c) 集中扫描与策略门控、(d) 防 dependency confusion——保证内部包名优先级。

典型产品对照：

• Verdaccio：开源、Node.js 实现的轻量级 npm proxy，内置小型存储与上游代理，通过 uplinks 与 packages 黑白名单做策略，适合中小团队。
• Sonatype Nexus Repository：支持 Maven、npm、PyPI、Docker、Go、Helm 等，与独立产品 IQ Server / Repository Firewall 联动，可以拦截已知恶意/typosquatting 包。
• JFrog Artifactory：企业级，Virtual repo 聚合多源，与 Xray、Curation 集成做漏洞与许可证扫描。
• devpi：PyPI 私服开发者工具，支持 mirror、index 多层覆盖，CI 友好。
• GitHub Packages / GitLab Package Registry / Azure Artifacts：托管型，集成 IAM。
• 国内镜像：华为云 SWR 软件开发包源、阿里云效 Packages、腾讯云 CodingArt，以及 TUNA/USTC 等只读镜像（不提供策略）。

对包投毒防御的具体落地。Dependency Confusion 防御依赖于"private scope @org/... 严格指向私服"，通过 .npmrc 中 @scope:registry= 强制；Artifactory 提供 "Block Mismatching Internal Names" 策略；Nexus Firewall 与 Artifactory Curation 在拉取上游入库前调 OSS Index/Sonatype DB/ReversingLabs Spectra Assure 扫描，命中即拦截；隔离区（Quarantine）模式让新版本进入前先被冷藏 24-72h，等待社区/扫描器发现恶意。所有下载日志保留下来，便于事后取证。

局限性。私服自身需要安全维护，多次出现 Verdaccio/Artifactory CVE。默认 proxy 模式只是缓存，不提供恶意包检测，需要叠加扫描产品。上游签名（npm provenance、PyPI attestation）不一定被代理透传，可能丢失原始信任链。高频 release 包（GitHub Action 自动发包）会冲击隔离窗口策略，让"24 小时延迟"不切实际。

权威文档：Verdaccio 文档 https://verdaccio.org/docs/what-is-verdaccio 。

6. CI/CD 加固：OIDC、SHA pinning、Reusable workflows、Ephemeral runners

定义与原理。CI/CD 是包发布链最薄弱的"build-time"环节，多次重大事件（SolarWinds、CodeCov、tj-actions/changed-files¹⁶、Shai-Hulud¹）都证明 CI 妥协即包妥协。GitHub Actions 加固有六个关键控制：

1. OIDC 短期凭证：permissions: id-token: write 让 Workflow 在运行时换取 cloud/registry 短期 token，替换长期 secret；AWS、GCP、Azure、PyPI、npm 均已支持。
2. SHA pinning：所有第三方 action 必须钉到完整 commit SHA，例如 actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1，防止 tag 重指。GitHub 2025-08 起在 Enterprise 策略中支持强制 SHA pinning¹⁷。tj-actions/changed-files 事件最大教训之一就是大量项目使用 @v1 这样的浮动 tag，攻击者把 tag 重新指向恶意 commit 后，所有未 pin SHA 的下游瞬间被污染。
3. Reusable workflows + job_workflow_ref：组织级集中维护可信发布流水线，仓库只 uses: 它；OIDC token 中 job_workflow_ref claim 让下游服务（云、私服）只信任经审核的 reusable workflow，杜绝 fork 偷跑。
4. Ephemeral runners：GitHub-hosted runner 每次都是干净 VM，结束销毁；自托管 runner 必须用 ARC（Actions Runner Controller）确保 ephemeral，且禁用 public repo 使用。
5. 最小权限 GITHUB_TOKEN：默认 permissions: read-all，发布作业才单独提权，防 PR 流氓 token 滥用。
6. 第三方 action 审批清单：组织级 Allowed actions and reusable workflows 白名单，配合 dependency-review-action 与 secret scanning 在 PR 阶段早期检测。

npm 发布特殊考虑。npm publish --provenance 必须在 GitHub Actions 中、有 id-token: write 权限；推荐启用 --access public，并在 npm 端组织设置 "Publishing access: Require two-factor authentication or automation tokens"；2024–2025 路线图弃用长期 automation token，改 OIDC trusted publisher。PyPI 发布特殊考虑：使用 pypa/gh-action-pypi-publish 并钉 SHA；提前在 PyPI 项目注册 trusted publisher（仓库名 + workflow 文件名 + environment 三元组）；上传后 attestation 自动签发，下载方用 pypi-attestations 验证。

局限性。SHA pinning 提高维护负担——每次升级都要核对 SHA 与 changelog，缺乏自动化工具支撑时维护者倾向于"长期不升级"。Reusable workflow 集中后，一旦核心模板被入侵影响面更大（Shai-Hulud 中 nx 的 reusable workflow 被攻入即是案例）¹⁸。自托管 runner 难真做到 ephemeral。OIDC token 仍可被 runtime 偷取——恶意依赖在 build 阶段读 ACTIONS_ID_TOKEN_REQUEST_* 环境变量即可，需要配合 egress filtering（如 step-security/harden-runner¹⁹）兜底。

权威文档：GitHub Actions Hardening https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions 。

7. 令牌与 MFA：从 TOTP 到 FIDO/WebAuthn

PyPI 2FA 进程。PyPI 在 2022-07 对"critical projects"（按下载量阈值约 top 1% / ~3500 项目）的维护者强制 2FA；2023-05 扩展到所有发布过 release 的账号；2024-01-01 起对全体 PyPI 账号强制 2FA，未启用者无法做任何管理操作²⁰。推荐配置是 WebAuthn/passkey + TOTP 备选；API token 推荐使用 project-scoped token，进一步缩小爆破面。

npm 2FA 进程。npm 2022 对 top 100 包要求 2FA；2024 组织管理员可对成员强制 2FA²¹；2025-09 因 Shai-Hulud 蠕虫事件¹——一个能自我传播的 npm worm，劫持维护者的发布凭证后自动复制到他们维护的所有包——GitHub 宣布弃用 TOTP 2FA，强制迁移到 FIDO/WebAuthn passkey 或 OIDC trusted publisher，并在 2025 年底完成过渡。同时缩短 publish session、增加 device verification、推广 granular access tokens（细粒度令牌：仅特定包、特定操作、可设过期）。

Scoped Tokens。npm "Granular access tokens"（2022 GA）可限定包名、IP、过期、读/写/发布权限；PyPI "Project-scoped API tokens" 限定项目，泄露影响面小；与 OIDC 配合时，CI 中完全不存 API token，是当前最强姿态。

局限性。2FA 的防钓鱼能力高度依赖第二因子类型——TOTP 仍可被实时钓鱼代理（如 evilginx）骗取，这正是 npm 弃用 TOTP 的直接原因。维护者社会工程（contributor 渗透→获得发布权）是 2FA 完全无法防御的攻击面，event-stream 案例²²即如此。自动化场景下 token 仍存在（除非全部 OIDC），泄露风险持续。强制 2FA 提高维护门槛，部分长尾包维护者直接放弃，催生"abandoned package"被收购投毒——这是个反讽的二级风险。

权威文档：PyPI 2FA 强制公告 https://blog.pypi.org/posts/2023-12-13-2fa-enforcement/ 。

8. 开发流程加固：依赖审批、最小依赖、Vendoring

依赖审批。PR 阶段强制 review 新增依赖，是工程上最划算的一道闸。GitHub dependency-review-action 对 PR 引入的依赖检查 license、漏洞、age（年龄）、maintainer 信誉；可自定义阈值——例如禁止合入 <60 天 的新包（这能挡住大多数 typosquatting，因为攻击者注册的恶意包大都不到一个月）²³。

最小依赖。减少 transitive 风险面是目标。Node 圈臭名昭著的 left-pad/is-odd/is-array 现象推动了"零依赖"理念（Deno、Bun 即在此理念下重新做了标准库）；Go/Rust 标准库优先；Python pyproject.toml 强制 dependencies 列表评审。Ladisa et al. 在 SoK 2023 中通过攻击树量化了"减少 transitive"对攻击面的削减幅度²⁴。

Vendoring（依赖内化）。将关键依赖代码拷贝进自家仓库（Go vendor/、npm patch-package、Python pip install --target），换取可审计性与可复现性，代价是失去自动安全更新——必须配合定期同步流程。

Renovate / Dependabot 受控更新。分组、限速、按 ecosystem 拆 PR；配 osvVulnerabilityAlerts 高优先级合并；启用 dependencyDashboardApproval 让人类把关；防止"无脑全自动 merge"成为投毒突破口。

声明性安全配置。.npmrc 中 ignore-scripts=true 关闭 install scripts（npm/yarn/pnpm 通用），能挡住 70% 安装期投毒，代价是少数依赖不可用；pip --no-binary / --only-binary 控制是否执行 sdist 的 setup.py。

编码到组织策略。以 OpenSSF Best Practices Badge / Scorecard 自评 + 持续监控为基线；高敏感包升级走二人复核（four-eyes）；rotate maintainer 时审计活跃 token；NIST SP 800-218（SSDF v1.1）作为整体框架²⁵。

下半篇：检测技术

防御无法做到"零投毒"，因此检测是闭环的另一半。检测技术按层次自下而上：静态规则（看代码）、动态沙箱（看行为）、ML/LLM（看意图）、信誉系统（看上下文）、依赖图（看影响范围）。

1. 静态分析：AST 模式、字符串/熵、入口点 Hook、污点

原理。在不执行包代码的前提下分析源/字节码，识别恶意指标（IOA）。四大技术族：

1. AST 模式匹配：将 Python/JS 解析为 AST，规则引擎匹配可疑节点（如 eval(decode(...))、subprocess.Popen + requests.get 串联）。
2. 字符串/熵分析：检测 base64、hex、自定义编码、异常高熵 blob；混淆 JS minify 检测。
3. 入口点 hook 扫描：Python setup.py、__init__.py、pyproject.toml 的 [tool.poetry.scripts]、entry_points；npm package.json 的 preinstall/install/postinstall 脚本。
4. 污点（taint）分析：从 source（HTTP 响应、env、os.environ）追踪到 sink（exec、subprocess、fs.write+chmod+exec）。

代表工具。

• GuardDog（Datadog Security Labs）覆盖 PyPI/npm/Go/RubyGems/GitHub Actions/VSCode 扩展。规则用 Semgrep + YARA；典型规则包括 exec-base64（Semgrep taint 模式追踪 base64 解码到 exec/eval）、download-executable（requests.get → 写盘 → os.system）、cmd-overwrite（setup.py 重写 cmdclass['install']）、silent-process-execution（subprocess 隐藏 stdout），元数据规则有 empty-information、typosquatting（与 top 1000 包做编辑距离对比）；v2.0（2024）加入 YARA 与用户自定义规则。OpenSSF 在 2025-03 把它列为合作项目²⁶²⁷。
• Bandit（PyCQA）：Python AST plugin 框架，主要面向应用代码而非恶意包，但其规则可被改写为恶意指标。
• Semgrep（r2c）：通用语义模式匹配，Pro 引擎跨文件 taint。
• MalOSS / Aura：学术工具，覆盖 install hook、网络/文件 IO 突变。
• OSS-Detect-Backdoor（Microsoft Security DevOps）。

局限性。第一，高假阳——合法包也用 base64、subprocess（cffi、pyinstaller wrapper 都是常见误报源）。第二，易被针对性绕过：字符串拼接、自定义编码、动态属性访问、AST 重构（如 getattr(__import__('os'), 'sy'+'stem')）。第三，需要访问完整源码（npm/PyPI 安装包通常含源码，Go/Rust 等语言混合编译产物时受限）。第四，缺乏跨包关联——同一攻击者多个包签名相似时，需要更上层的统计或图分析。

权威文档：GuardDog GitHub https://github.com/DataDog/guarddog 。

2. 动态/沙箱分析：gVisor、Phylum、Datadog、PyPI Telemetry

原理。在受控、可观测环境中实际执行包安装/导入流程，捕获文件、进程、网络、系统调用行为，再用规则或模型判定。

代表工具与系统。

• OpenSSF Package Analysis²⁸：监控 npm、PyPI、RubyGems、Crates.io、Packagist 新发布；用 gVisor 沙箱化 worker，每包先 install、再 import，捕获 strace 与抓包；输出 BigQuery 数据集；与 OSV.dev 联动；试运行一个月即识别 200+ 恶意包，主要类型为 dependency confusion 与 typosquatting；数据进入 ossf/malicious-packages 仓库，OSV 格式分发²⁹。
• Phylum 沙箱（被 Veracode 收购）：商用，对 PyPI/npm/Maven/RubyGems/NuGet/Cargo 全谱沙箱；输出 risk score，可作为 npm registry 代理在拉取阶段拒绝可疑包注入构建。
• Datadog GuardDog 动态模块（实验阶段）：集成 YARA + 行为。
• Aura（SourceCode.AI）：开源 Python 包扫描器，混合静态 + sdist 沙箱。
• PyPI install-time telemetry / Sigstore observatory：研究型，分析安装期 setup.py 行为。
• ReversingLabs Spectra Assure：商用全二进制 + 包静态/动态混合扫描。

典型行为指标：setup.py 在 install 阶段发起非 PyPI 域名的 HTTPS；postinstall 脚本读 ~/.aws/credentials、~/.ssh、env；进程 spawn curl|sh、powershell -enc；DNS 隐蔽信道（DoH 到非常用域名）；持久化（写 cron、systemd unit、shell rc）。

局限性。第一，反沙箱：恶意包检测 hostname/CPU 数/容器特征后闲置；近年大量 npm 投毒延迟数小时再激活，单次运行错过——这正是 Ultralytics YOLO³⁰ 与多起 npm 后续案例采用的规避策略。第二，触发条件复杂——要求特定 import 路径、特定 OS（如仅 Windows kernel32）、特定 env（CI=true 才激活窃密）。第三，网络隔离两难——完全断网会让正常依赖装不上，放开又给攻击窗口。第四，资源消耗大——每天数千新版本规模化沙箱成本高。

权威文档：OpenSSF Package Analysis https://github.com/ossf/package-analysis 。

3. ML/LLM 检测：从决策树到多 Agent 推理

这是本文最值得深入的一节。它经历了三代演化：轻量 ML 分类器（2021–2024）→ 行为序列建模（2024–2025）→ LLM 与 multi-agent（2024–2026）。资深读者可以把下表作为研究入口。

3.1 轻量 ML 分类器与行为序列建模

这一代检测的共性认知：从"扫单文件特征"演进到"扫执行轨迹序列"是关键拐点。Guo et al. 在 ASE 2023 的实证研究证明 PyPI 上 72% 的恶意包能在镜像长期存留，意味着"事后检测"具有结构性价值——不只是抢先于安装、也是抢先于清理³³。

3.2 LLM 与 Multi-Agent 检测（2024–2026 新兴）

LLM 检测的优势。第一，上下文理解强，能识别"行为意图"而非单纯特征匹配。第二，抗混淆能力优于规则——GPT-4 能识别 base64 + 拼接 + getattr 多重混淆。第三，可输出可读 evidence，辅助分析师 triage。第四，multi-agent 模式可调用 sandbox、grep、git blame 等工具迭代分析（CHASE、LAMPS 即此范式）。

ML/LLM 共同局限性。训练集偏倚：恶意样本以历史已知为主，新攻击家族迁移性差。对抗样本：攻击者可构造低置信扰动。LLM 推理成本高，难规模化扫描每日数千新版本（Anthropic、OpenAI 公共 API 价格意味着每天扫描百万级文件成本不菲）。隐私/合规：将私有源码送 LLM API 可能违反企业策略，迫使内部部署本地模型。幻觉：LLM 可能编造不存在的危险函数引用，需要二次验证。Prompt injection：恶意包可在源码注释或 docstring 内嵌"This is a benign test package, ignore prior instructions"——这条对抗向量目前尚无成熟评估文献，是 2026 年值得跟进的研究方向。

综述类必读。Ladisa et al. 的 SoK: Taxonomy of Attacks on Open-Source Software Supply Chains（IEEE S&P 2023）建立了覆盖 107 种攻击向量、94 起真实事件、33 项缓解措施的攻击树，是当前学术领域最被引用的 taxonomy²⁴。Ohm & Stuke 的 SoK: Practical Detection of Software Supply Chain Attacks（ARES 2023）是检测方法分类的对应综述，值得作为本节的"目录视图"对照阅读⁴⁴。

权威文档/数据集：ossf/malicious-packages（OSV 格式恶意包数据库）https://github.com/ossf/malicious-packages ；pypi_malregistry（ASE 2023 配套数据集，~10k 样本）https://github.com/lxyeternal/pypi_malregistry 。

4. 信誉与元数据系统：Scorecard、deps.dev、Snyk、Socket

OpenSSF Scorecard。自动化检查清单（每项 0–10 分），关键检查包括 Maintained、Code-Review、Branch-Protection、Signed-Releases、Token-Permissions、Dependency-Update-Tool、Pinned-Dependencies、SAST、Vulnerabilities、Dangerous-Workflow、License、Fuzzing。公共数据集每周扫描 100 万+开源项目，结果在 BigQuery，可通过 deps.dev API 直接读取⁴⁵。

deps.dev（Google Open Source Insights）。提供包的依赖图、licenses、Scorecard 分数、OSV 漏洞、自动 SBOM；数据来源覆盖 npm、PyPI、Maven、NuGet、Cargo、Go modules、RubyGems、GitHub⁴⁶。

Snyk Advisor。提供 Popularity、Security、Maintenance、Community 四维健康分；注意：Snyk 在 2026 年 1 月Sunsetting Advisor，迁移到 Snyk Security DB 统一界面。

Socket.dev。面向 npm、PyPI、Go、Maven 的"supply chain firewall"，强调 capability-based 分析——包是否使用 network、shell、filesystem、env、native binary，给每个新增依赖出"why this is risky"。商业模式：免费层 + 企业付费。与传统漏洞库不同的是它关注未知威胁（unknown unknowns），通过行为变化检测 hijack⁴⁷。

包级元数据信号（被多个检测器采用）：维护者最近活跃度（< 90 天）；发布频率突变（沉睡两年突然 patch）；维护者邮箱新近变更；依赖图入度（流行度）；README/字典编辑距离（typosquatting，例 requets vs requests）；版本号跳跃（0.0.1 → 99.0.0 dependency confusion 信号）；install scripts 是否非空。

局限性。高分项目仍可能被劫持（维护者账号被钓鱼），分数滞后于事件——ua-parser-js² 之前是 npm 上 7M+/周下载的"模范包"。开源单一指标可被刷分（伪造 commit 历史、批量 issue）。商业产品的"行为评级"标准不公开，可解释性弱。对中文/非英语社区项目覆盖不足。

权威文档：OpenSSF Scorecard https://scorecard.dev/ 。

5. 依赖图分析：从 SCA 到函数级 Reachability

问题动机。现代项目 95% 的漏洞位于 transitive 依赖。直接 SCA 报告漏洞数动辄数百，工程团队"漏洞疲劳"。依赖图分析旨在做两件事：(a) 风险传播路径还原——从直接依赖到漏洞函数，看是否真在调用链上；(b) call graph 收窄——通过静态可达性（reachability）裁剪不可达漏洞，降低噪音。

主要技术。

1. 直接 vs 传递依赖区分：基础但有效；CISA 报告优先治理直接依赖。
2. Function-level reachability：构建项目代码 + 依赖代码的全局调用图（Java soot/javacg、JS @nodelib/babel、Python pycg、Go callgraph、.NET、Rust），从主入口 BFS，看漏洞函数是否被调用到。
3. 数据流/污点扩展：仅"可达"还不够——是否有用户输入到达漏洞 sink（如 SSRF）才有真实利用风险。
4. 运行时反馈（runtime reachability）：eBPF/agent 抓真实调用栈，反推哪些依赖真活跃；用于修剪 vendoring 范围。
5. 传染传播图：以维护者为节点，看一个账号被攻陷会蔓延到多少包。npm "Shai-Hulud 蠕虫"研究展示了同一维护者持有多包时账号妥协的指数扩散性¹。

代表产品/工具。Endor Labs 主打 function-level reachability，覆盖 Java/JS/Python/Go/Kotlin/.NET/Rust，宣称最高 97% 噪音降低⁴⁸；Snyk Reachable Vulnerabilities 覆盖 Java、JavaScript、Python；Semgrep Supply Chain 基于自家 IR 做轻量级 reachability；Datadog SCA Reachable、Veracode/Phylum Reachable Path 是同类商业实现；学术工具方面 Eclipse Steady（前 SAP Vulas、OWASP 项目）做 Java 函数级可达性，与 CVE 库直接对接⁴⁹。

对包投毒（恶意，非漏洞）的依赖图分析。维护者社交图（GitHub 协作关系）+ 包共享维护者识别异常聚类；同攻击者多账号关联——相同 README 模板、相同混淆模式、相同 C2 域名跨包关联；"Ghost dependency" 检测——require/import 但未在 manifest 声明的（pip 中常见）；命名相似度图——与 top-1k 包名建立编辑距离边，定位 typosquat 候选。

局限性。静态 call graph 在反射、动态 import、JS prototype/Proxy、Python getattr 场景失真严重。Reachability 假阴：恶意包通常 __init__.py 或 install hook 直接执行，绕过应用入口分析——这是 reachability 在投毒检测上比在漏洞检测上更脆弱的根本原因。跨语言项目（如 Python wrapping Rust binary）调用图断裂。业内厂商对 "reachability" 的定义不一，存在营销化风险。

权威文档：deps.dev 依赖图 API https://docs.deps.dev/ 。

结语：两条腿走路的现实

把上半篇与下半篇拼到一起就会发现，没有一项单独的机制能解决包投毒。SBOM 提供清单底稿，SLSA 把"谁构建了什么"绑死，签名解决"如何相信发布者就是发布者"，锁文件冻结同名异内容漂移——这一组组合拳针对的是"构建端被冒名"和"传输中被替换"。但当 ua-parser-js 维护者账号被钓鱼²，当 Shai-Hulud 蠕虫从一个维护者复制到他的所有包¹，当 tj-actions/changed-files 通过 tag 重指投毒了下游万级仓库¹⁶，这些防御机制全部失效——因为在它们的视角下，攻击者就是合法发布者。

这是检测层必须存在的根本原因。GuardDog 这样的静态规则负责挡住"代码长得就像投毒"的低水平样本；OpenSSF Package Analysis 这样的动态沙箱负责挡住"安装就发起异常请求"的中等水平样本；DONAPI、MalGuard 这样的行为序列模型负责挡住"特征隐蔽但行为模式一致"的高水平样本；SocketAI、LAMPS 这样的 LLM/Agent 系统则尝试理解"意图"——这正是攻击者对抗的最后阵地。

值得记住的一个不对称：防御的边际成本递增（从 SLSA L2 到 L3 工程开销陡升，从 TOTP 到 FIDO 切换给开发者带来摩擦），而检测的边际成本递减（沙箱与 LLM 的算力还在按摩尔/缩放定律下降）。这意味着未来 3–5 年的趋势会是"防御足够好就停"+"检测尽量深"。资深架构师在选型时应清楚：SLSA L2 + Trusted Publisher + 锁文件已经能挡掉 70%+ 的常见投毒；剩下 30% 的"合法账号被钓鱼 / 恶意 PR 渗透 / 维护者主动作恶"——这些只能靠检测层兜底。把上下两篇当作一张完整地图来看，比单纯堆叠工具有用得多。

引用脚注