我如何构建 forgeseal 来通过一条命令解决 JS/TS 供应链安全

Source: Dev.to

问题

欧盟《网络弹性法案》将于 2026 年 9 月生效，要求向欧洲交付的每个软件产品都提供软件材料清单（SBOM）。对于 JavaScript 和 TypeScript 团队来说，供应链安全工具链十分碎片化：需要分别使用不同的工具来生成 SBOM、对制品签名、生成来源声明以及管理漏洞。每个工具都有自己的配置和假设，且许多工具在处理各种 lockfile 格式（npm v2/v3、Yarn classic、Yarn Berry v2‑v4、pnpm v6/v9、Bun）时都会遇到困难。

forgeseal 的功能

forgeseal 是一个单一的 Go 可执行文件，能够处理整个供应链安全工作流：

forgeseal pipeline --dir ./my-project --output-dir ./artifacts --vex-triage

这条命令可以：

• 检测并解析你的 lockfile（支持全部六种 JS/TS 格式）
• 生成 CycloneDX SBOM，包含正确的 PURL、完整性哈希和依赖图
• 使用 Sigstore 无密钥签名对 SBOM 进行签名（无需 GPG 密钥）
• 创建 SLSA v1 来源声明，包含 CI 环境元数据
• 查询 OSV.dev 并生成带有漏洞三角化占位符的 VEX 文档

入门指南

# 安装
go install github.com/sn45/forgeseal/cmd/forgeseal@latest

# 生成 SBOM
forgeseal sbom --dir ./my-project

# 完整工作流
forgeseal pipeline --dir . --output-dir ./forgeseal-output --vex-triage

每个子命令也可以单独使用：

• 仅生成 SBOM：forgeseal sbom
• 仅签名：forgeseal sign
• 仅 VEX 三角化：forgeseal vex triage

Lockfile 解析器的挑战

正确解析全部六种 lockfile 格式是最有趣的工程挑战。亮点包括：

• npm – 同时处理 package-lock.json 中的 v2 与 v3 架构，键结构不同。
• Yarn Classic – 使用状态机解析自定义文本格式。
• Yarn Berry – 解释带有自身约定的类 YAML 文件，用于解析分辨率和校验和。
• pnpm v9 – 跨 packages 与 snapshots 映射进行交叉引用。
• Bun – 处理带注释的 JSON（JSONC），其中 base64 哈希可能包含看似注释标记的 // 序列。

我们在 10 个主流开源项目（socket.io、jest、storybook、vue、astro、nuxt、svelte、next.js、elysia、hono）上进行了验证，覆盖了 15 000+ 组件，涉及所有格式。PURL、依赖边和完整性哈希均与源 lockfile 完全匹配。

CI 集成

forgeseal 已提供为 GitHub Action：

- uses: sn45/forgeseal@v1
  with:
    command: pipeline
    dir: '.'
    sign: 'true'
    attest: 'true'
    vex-triage: 'true'

在 GitHub Actions 中，Sigstore 签名所需的 OIDC 令牌会自动获取；只需在工作流中设置 permissions: id-token: write 即可。

下一步计划

核心工作流已相当稳固。计划中的增强功能包括：

• 容器镜像 SBOM 支持
• 与 Grype/Trivy 集成，以获取更丰富的漏洞数据
• forgeseal audit 命令，用于根据 CRA 要求评估项目的供应链安全姿态

代码仓库：
采用 Apache 2.0 许可证，欢迎贡献。