题记与说明
- 日期：2026-10-31
- 前缀：knowledge-p5j2vm4l-3
- 类型：主题研究（先检索 7 个一手来源精读，再综合产出个人项目安全检查清单）
- 产出要求：个人项目安全检查清单（见第三节）
- 来源（本主题的 7 个一手来源，全部为本会话实际抓取阅读）：
- SLSA 官网（框架定位、on-ramp、OpenSSF 治理）— https://slsa.dev/
- SLSA v1.2 规范 · Producing artifacts（Build L1/L2/L3 逐级要求）— https://slsa.dev/spec/v1.2/build-requirements （注：v1.0 已标记 Retired，v1.2 为现行版本）
- Sigstore 官方文档（keyless 签名、Fulcio/Rekor/cosign、验证四步）— https://docs.sigstore.dev/
- CycloneDX 官网（BOM 全栈标准、ECMA-424、VEX）— https://cyclonedx.org/
- SPDX 官网（ISO/IEC 5962:2021、profiles 体系）— https://spdx.dev/
- OpenSSF Scorecard 官网（18 项自动化检查及风险分级）— https://securityscorecards.dev/
- OSV-Scanner 文档（OSV.dev 前端、扫描模式、guided remediation）— https://google.github.io/osv-scanner/
- 补充对照：GitHub《Quickstart for securing your repository》— https://docs.github.com/en/code-security/getting-started/quickstart-for-securing-your-repository
- 诚实声明：本次为纯文献精读 + 综合产出，未在本地实际运行 cosign / osv-scanner / scorecard 做实测验证；清单中的具体命令均标注了来源依据，落地时需自行验证版本与行为。
一、七维提取
1. 核心问题
现代软件的绝大部分不是自己写的：依赖、构建系统、发布管道都掌握在别人手里。攻击者不再需要黑你的代码——黑你信任的东西就够了。供应链攻击的四个攻击面与对应的防线问题是：
| 攻击面 | 典型手法 | 要回答的问题 | 对应机制 |
|---|---|---|---|
| 依赖 | npm/PyPI 投毒、typosquatting、依赖混淆 | 我用了什么？里面有没有已知漏洞？ | SBOM + OSV/漏洞扫描 |
| 构建 | CI 入侵、制品被篡改（SolarWinds、XZ 后门类） | 这个制品真的是从那份源码、用可信流程造出来的吗？ | SLSA 构建级别 + provenance |
| 交付 | 长期签名密钥泄露、制品被替换 | 这个文件真的来自作者本人吗？ | Sigstore 签名与验证 |
| 响应 | 漏洞爆发时不知道自己是否受影响、影响多大 | 新 CVE 出来后，我能在多快内定位并修复？ | SBOM 消费 + VEX + 依赖更新 |
SLSA 官网对问题根源的一句话（原文）：
"Any software can introduce vulnerabilities into a supply chain."
所以这不是"选安全的依赖"就能解决的问题——链条上任何一环都可能引入漏洞，需要的是分层防线而不是单点防御。
2. 主要主张
各来源的核心声明（原文引述）：
SLSA —— 自我定位就是一个检查清单式的框架：
"SLSA is a security framework, a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure."
且强调渐进采用："with easy, basic steps at the lower levels to build up and protect against advanced threats later"；第一入口是生成来源证明："The first on-ramp to SLSA is generating provenance."
Sigstore —— 从"密钥信任"转向"身份信任"，直指传统 GPG 签名的三大痛点：
Sigstore shifts "from a key-based signing approach to an identity-based one."
传统方案的问题被明确列出：Identity（"How do you know the person signing the artifact is who they say they are?"）、Key management、Key revocation。且 "Sigstore services never obtain your private key."
CycloneDX —— SBOM 不只是组件清单，是全栈 BOM 风险标准：
"a full-stack Bill of Materials (BOM) standard that provides advanced supply chain capabilities for cyber risk reduction."
已标准化为 ECMA-424（OWASP + Ecma TC54），并宣称 "the most advanced license support of any SBOM format"（可复用 SPDX license ID）。
SPDX —— 另一条 SBOM 标准路线，主打正式国际标准地位：
"The SPDX specification is a freely available international open standard (ISO/IEC 5962:2021)."
以 profiles（Security / Licensing / AI and Dataset / Build / Lite / Core / Software / Supply-chain / Hardware / Services）组织能力。
OpenSSF Scorecard —— 安全实践可以被自动化检查并打分：
"assesses open source projects for security risks through a series of automated checks"
OSV-Scanner —— 依赖漏洞匹配应该用机器可读的权威告警源，减少误报噪音：
"Each advisory comes from an open and authoritative source (e.g. the RustSec Advisory Database)"，OSV 格式精确匹配受影响版本，从而 "fewer, more actionable vulnerability notifications."
3. 方法
四条技术路线各管一段，构成分层防御：
（a）SBOM：先有清单，才谈得上响应
SBOM = 软件组件的机器可读清单。两大标准并存：
- CycloneDX：覆盖 SBOM / SaaSBOM / CBOM（密码学 BOM）/ HBOM / AI/ML-BOM 五类 BOM，外加 VEX（Vulnerability Exploitability Exchange——让供应商声明某个漏洞是否真的影响本产品）。生态规模宣称 "over 260 tools across 20+ programming languages"，且是 "the standard for multiple world governments and the defense industrial base"。
- SPDX：ISO/IEC 5962:2021 国际标准，按 profile 组织（Security、Licensing 等），许可证合规是传统强项。
- 两者在许可证词汇上互通（CycloneDX 可用 SPDX license IDs），实际选型更多看工具链：个人项目用 CycloneDX JSON 更顺手（Syft/Trivy 默认输出之一）。
（b）SLSA：用"分级"给构建完整性定语言
SLSA v1.2 分三条 track（Build / Source / 早期版本的 Dependencies track 已并入其他机制），Build track 三级要求矩阵（引自 https://slsa.dev/spec/v1.2/build-requirements ）：
| 要求 | L1 | L2 | L3 |
|---|---|---|---|
| Provenance Exists（构建必须生成 provenance，用密码学摘要唯一标识产物） | ✓ | ✓ | ✓ |
| Provenance is Authentic（可验证签名，由构建平台控制面而非租户生成） | ✓ | ✓ | |
| Provenance is Unforgeable（租户无法伪造） | ✓ | ||
| Platform Hosted（跑在托管基础设施上，"not on an individual's workstation"） | ✓ | ✓ | |
| Platform Isolated（构建环境隔离：拿不到平台密钥、互相不影响、临时环境、"the output of the build MUST be identical whether or not the cache is used"） | ✓ |
关键点：L1 的 provenance 内容是 "Best effort"；L2 要求签名可验证；L3 要求"租户强无法伪造"且外部参数 "fully enumerated"。Hermetic builds（封闭构建）被明确推迟到 future work，因为需要 "substantial changes to both the build platform and each individual build"。
（c）Sigstore：keyless 签名的完整流程
三方协作（引自 https://docs.sigstore.dev/ ）：
- cosign（CLI）生成密钥对，连同 OIDC 身份令牌（邮箱 / 服务账号 / CI workflow 身份）发给 Fulcio（CA）；
- Fulcio 验证令牌后签发短生命周期证书，把身份绑定到公钥；私钥用完即弃；
- 签名 + 制品摘要 + 证书记入 Rekor——"an immutable, append-only ledger"，签名事件公开可审计。
验证方检查四件事：签名与证书公钥匹配 → 证书身份与预期身份匹配 → 证书链到 Sigstore 根信任 → Rekor 包含证明（inclusion proof）。效果："the artifact comes from its expected source and has not been tampered with after its creation." 附带好处：身份所有者可监控 Rekor 发现身份被滥用。
（d）依赖漏洞响应：OSV.dev + 自动化
OSV-Scanner 是 "officially supported frontend to the OSV database"，把项目依赖清单连到漏洞库；支持扫 lockfile、容器镜像、SBOM，带实验性的 Guided Remediation（修复策略）和 license scanning，可嵌入 CI（GitHub Action）或作为 Go 库。
4. 数据与证据
- Scorecard 18 项检查及风险分级（引自 https://securityscorecards.dev/ ，这是把"安全实践"量化成清单的最直接证据）：
- *Critical*：Dangerous Workflow（workflow 注入风险）
- *High*：Vulnerabilities（对接 OSV）、Dependency Update Tool、Maintained、Binary Artifacts、Branch Protection、Code Review、Token Permissions、Signed Releases
- *Medium*：Security Policy、Fuzzing、SAST、Pinned Dependencies、Packaging
- *Low*：Licence、CII Best Practices、CI Tests、Contributors
- 每项 0–10 分，按可利用性加权成单一总分，并给出修复提示（remediation prompts）。风险定义逻辑示例：可通过 PR 触发利用的检查 = 高风险。
- SLSA v1.2 逐级要求矩阵（见上文 3(b) 表格，来自规范原文页）：这是"构建完整性"从口号变成可核对条款的证据。
- CycloneDX：ECMA-424 国际标准；260+ 工具、20+ 语言；被多国政府与国防工业基础采用、医疗器械厂商获准使用——证明 SBOM 已从最佳实践变成合规要求。
- SPDX：ISO/IEC 5962:2021，背书者含 AWS、Google、Microsoft、Intel、IBM 等。
- Sigstore：OpenSSF / Linux Foundation 项目，贡献者含 Google、Red Hat、Chainguard、GitHub、Purdue；验证四步流程如上。
- GitHub 官方安全快速入门给出的仓库加固顺序（作为实践对照）：dependency graph → Dependabot alerts → dependency review → Dependabot security updates → Dependabot version updates → code scanning (CodeQL) → secret scanning + push protection → SECURITY.md。公共仓库这些功能免费。
5. 结论
四件套各司其职，缺一环就有对应盲区：
- SBOM 是"知道有什么"——没有清单，漏洞响应只能靠猜；
- SLSA 是"知道怎么造出来的"——provenance 把制品锚定到源码和构建过程，防构建期篡改；
- Sigstore 是"知道是谁发的"——keyless 签名把传统 GPG 的密钥管理负担换成 OIDC 身份 + 短期证书 + 公开透明日志；
- OSV/Scorecard 是"持续发现与响应"——漏洞数据库对接 + 自动化实践打分，把安全变成 CI 里的日常。
对个人项目的推论：不需要追求 SLSA L3 或完整合规，性价比最高的路径是：先开漏洞告警（Dependabot/OSV-Scanner）→ 固定依赖和 workflow → 收缩 token 权限 → 生成 SBOM 并让它被扫描消费 → release 签名（cosign keyless）→ 用 Scorecard 持续自查。详细清单见第三节。
6. 局限
- SBOM 是必要非充分：清单不等于安全。SBOM 若不被消费（扫描、diff、响应流程），只是 shelfware。这一点各来源均未浓墨重彩，是我基于"CycloneDX 主打 cyber risk reduction、OSV-Scanner 支持直接扫 SBOM"推断的闭环要求。
- SLSA v1.x 结构变化：早期 v0.x 的 L1–L4 阶梯已改为 track-based；本笔记的 Build 级别来自 v1.2 build-requirements 页，Source track 细节和已退休的 v1.0 页面未逐一展开；v1.2 索引页未见独立 Dependencies track。
- Hermetic builds 缺位：SLSA v1.2 明确将其推迟为 future work，即"当前规范不解决网络可达性导致的构建不确定"。
- Sigstore 的运行时依赖：keyless 签发依赖 OIDC 提供方与 Fulcio/Rekor 可用性；短生命周期证书意味着长期归档验证需要保存 bundle（证书 + Rekor 证明）——文档首页未展开此细节，是我基于流程推断的限制点。
- Scorecard 只查表面：它检查的是可自动观察的实践（是否固定、是否签名），无法证明维护者无恶意、也无法发现逻辑后门。
- OSV 覆盖不均：advisory 来自各语言权威源（如 RustSec），跨生态质量与时效不保证一致。
- 本笔记方法局限：全部内容来自 8 次网页抓取，未本地实测（cosign、osv-scanner、scorecard-action 均未运行）；GitHub 文档页部分功能（Secret Protection / Code Security）在私有仓库需付费，公共仓库免费——清单中已标注。
7. 对我的启发
- 检查清单的"原子化"价值：Scorecard 把"安全"拆成 18 个可自动判定的二元/打分项，这种"把模糊品质拆成可核对条目"的方法可直接迁移到我自己的项目 review 清单、甚至 agent 行为评估上。
- 清单必须分层优先级：SLSA 的 L1→L3 渐进哲学（"easy, basic steps at the lower levels"）比"一次性达标"更现实。给个人项目的清单也应按 30 分钟 / 本周 / 逐步 三档。
- 闭环思维：SBOM 生成本身无价值，价值在"被消费"——发布物三件套（SBOM + 签名 + provenance）要有对应的验证端，否则是自我安慰。
- 与 AI 工程的交叉：CycloneDX 已有 AI/ML-BOM 和 CBOM（密码学 BOM）profile——我的 LLM/agent 项目同样有"模型、数据集、依赖"三重供应链问题，AI/ML-BOM 是可写的选题。
- 写作素材：Sigstore "key-based → identity-based" 的范式转换、SLSA 分级表、Scorecard 风险分级逻辑，都是适合写成入门文的骨架。
二、关键引述索引（原文 + 链接）
- "Any software can introduce vulnerabilities into a supply chain." / "SLSA is a security framework, a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure." / "The first on-ramp to SLSA is generating provenance." — https://slsa.dev/
- Provenance Exists/Authentic/Unforgeable 分级；Hosted/Isolated 平台要求；"ephemeral build environment MUST be provisioned for each build"；"the output of the build MUST be identical whether or not the cache is used"；hermetic builds 属 future work — https://slsa.dev/spec/v1.2/build-requirements
- "Sigstore shifts 'from a key-based signing approach to an identity-based one.'"；"Sigstore services never obtain your private key."；Rekor = "an immutable, append-only ledger"；验证四步 — https://docs.sigstore.dev/
- "a full-stack Bill of Materials (BOM) standard that provides advanced supply chain capabilities for cyber risk reduction."；ECMA-424；VEX；260+ 工具 20+ 语言 — https://cyclonedx.org/
- "The SPDX specification is a freely available international open standard (ISO/IEC 5962:2021)."；profiles 体系 — https://spdx.dev/
- "assesses open source projects for security risks through a series of automated checks"；18 项检查与 Critical/High/Medium/Low 分级 — https://securityscorecards.dev/
- "finds existing vulnerabilities affecting your project's dependencies"；"officially supported frontend to the OSV database"；OSV 格式 → "fewer, more actionable vulnerability notifications" — https://google.github.io/osv-scanner/
- GitHub 仓库安全快速入门的功能顺序与"公共仓库免费"说明 — https://docs.github.com/en/code-security/getting-started/quickstart-for-securing-your-repository
三、个人项目安全检查清单（本次精读的落地产出）
设计原则（来自来源）：① 按 SLSA 渐进哲学分三档优先级；② 每项标注对应机制与依据来源；③ 闭环——SBOM/签名都要有"消费端"；④ 以 GitHub 公共仓库为默认环境（免费功能为主），其他平台等价替换。
使用方法：先跑一次 OpenSSF Scorecard 自查（scorecard-action装 GitHub Action，或 CLIscorecard --repo=owner/repo），按其 remediation prompts + 本清单逐项修复。
P0：立即做（≈30 分钟，防最常见的攻击面）
| # | 检查项 | 对应机制 | 具体操作 | 依据 |
|---|---|---|---|---|
| 0-1 | ✅ 依赖漏洞告警已开启 | 依赖漏洞响应 | 仓库 Settings → Advanced Security 开启 Dependabot alerts（公共仓库免费）；或非 GitHub 项目在 CI 跑 osv-scanner scan -r . 扫全部 lockfile | GitHub quickstart 步骤 4；OSV-Scanner 文档 |
| 0-2 | ✅ 无 workflow 注入点 | Scorecard: Dangerous Workflow（Critical） | grep 所有 workflow：run: 中不得拼接 ${{ github.event.* }} 等不可信输入；该类输入先落 env 变量再引用 | Scorecard 检查表（Critical 级） |
| 0-3 | ✅ Actions 固定到完整 SHA | Scorecard: Pinned Dependencies | uses: actions/checkout@v4 → @<40 位完整 commit SHA>（版本 tag 可保留在注释）；Dockerfile FROM 用 digest 固定 | Scorecard: Pinned Dependencies (Medium) |
| 0-4 | ✅ workflow permissions 收缩 | Scorecard: Token Permissions（High） | 顶层 permissions: contents: read；需要写权限的 job 单独放开；有 release 发布的 job 再给 id-token: write（keyless 签名需要） | Scorecard: Token Permissions (High) |
| 0-5 | ✅ 仓库无二进制制品 | Scorecard: Binary Artifacts（High） | 删除提交进仓库的 .exe/.so/压缩包等二进制（测试 fixture 除外）；制品只放 release artifacts | Scorecard: Binary Artifacts (High) |
| 0-6 | ✅ 无泄露密钥 | Secret scanning | 开启 secret scanning + push protection（公共仓库免费）；历史泄露需轮换而非仅删除 | GitHub quickstart 步骤 9 |
P1：本周做（把响应闭环建起来）
| # | 检查项 | 对应机制 | 具体操作 | 依据 |
|---|---|---|---|---|
| 1-1 | ✅ 每次发布生成 SBOM | SBOM（CycloneDX） | CI 里用 Syft：syft dir:. -o cyclonedx-json > sbom.json，或 Syft/Trivy 扫容器镜像；SBOM 随 release 发布并入库 | CycloneDX 生态（260+ 工具）；GitHub quickstart 步骤 3 |
| 1-2 | ✅ SBOM 被消费（关键闭环） | 依赖漏洞响应 | SBOM 不是存档：CI 定期 osv-scanner scan --sbom sbom.json，让清单对接 OSV.dev；否则 SBOM 是 shelfware | OSV-Scanner（支持直接扫 SBOM） |
| 1-3 | ✅ 依赖自动更新 | Scorecard: Dependency Update Tool（High） | 配置 dependabot.yml 开 version updates + security updates（后者自动提修复 PR）；非 GitHub 用 Renovate | Scorecard；GitHub quickstart 步骤 6–7 |
| 1-4 | ✅ Release 有签名 | Sigstore | GitHub Actions 里用 cosign keyless：cosign sign-blob --yes dist/*.tar.gz（workflow 需 id-token: write，走 Actions OIDC，无长期密钥）；下载方用 cosign verify-blob 校验证书身份 + Rekor 证明 | Sigstore 文档（keyless 流程四步） |
| 1-5 | ✅ 有 SECURITY.md | Scorecard: Security Policy（Medium） | 仓库 Security tab → "Start setup"，写清支持版本与漏洞报告渠道 | Scorecard；GitHub quickstart 步骤 10 |
| 1-6 | ✅ PR 依赖变更可视化 | 依赖响应 | 开启 dependency review（PR 里显示依赖增删与漏洞标记），合并前拦截新漏洞 | GitHub quickstart 步骤 5 |
P2：逐步做（构建完整性升级）
| # | 检查项 | 对应机制 | 具体操作 | 依据 |
|---|---|---|---|---|
| 2-1 | ✅ 生成构建 provenance（SLSA L1 入口） | SLSA | "The first on-ramp to SLSA is generating provenance"：GitHub Actions 用 actions/attest-build-provenance 为 release 产物出 attestation；消费端 gh attestation verify | SLSA 官网 on-ramp；SLSA v1.2 L1: Provenance Exists |
| 2-2 | ✅ hosted 构建（SLSA L2 路径） | SLSA | 构建留在官方 hosted runner（GitHub Actions / GCP Cloud Build），不在个人工作站构建发布物；provenance 由平台控制面签名 | SLSA v1.2: Hosted + Authentic |
| 2-3 | ✅ 构建隔离意识（SLSA L3 方向） | SLSA | 用官方 hosted runner 而非自带自建 runner；密钥进 secrets 管理且不落入构建步骤；缓存不改变输出 | SLSA v1.2: Isolated（L3 要求清单） |
| 2-4 | ✅ 分支保护 + Code Review | Scorecard: Branch Protection / Code Review（High） | 主分支禁止 force push、要求 PR review（单人项目可开 admin 强制绕行自己走一遍流程） | Scorecard (High ×2) |
| 2-5 | ✅ SAST 上线 | Scorecard: SAST（Medium） | 开 GitHub code scanning 的 CodeQL default setup（公共仓库免费） | Scorecard；GitHub quickstart 步骤 8 |
| 2-6 | ✅ 漏洞响应 SOP | VEX + SBOM | 固定流程：OSV 告警 → 查 SBOM 定位影响面 → 判定是否实际可利用 → 升级/修补 → （发布方）出 VEX 声明说明不受影响的漏洞 | CycloneDX VEX 定义；OSV-Scanner 流程 |
| 2-7 | ✅ 持续自查打分 | Scorecard | 装 scorecard-action，每次 push 自动跑 18 项检查并出聚合分与修复提示；在 README 挂 Scorecard 徽章 | Scorecard 使用方式 |
单人项目特别说明
- Branch Protection / Code Review 可降级：单人项目无法严格执行双审，最低要求是"自己也不得直推主分支"（开 require PR + 自己 approve），重点是防误操作和留审计轨迹。
- 付费功能边界：Dependabot 全家桶、dependency review、CodeQL default setup、secret scanning 对公共仓库免费；私有仓库部分功能需 GitHub Advanced Security 等付费计划——私有个人项目可等价替换为 osv-scanner + gitleaks + trivy 的自建 CI。
- 发布物三件套模板（P1/P2 完成后的理想 release）：
artifact + sbom.json（CycloneDX）+ 签名（cosign keyless）+ provenance（attest-build-provenance），对应"清单 + 身份 + 构建完整性"三问。
四、七维字段小结（供矩阵引用）
- 核心问题：软件链条每一环（依赖/构建/交付/响应）都可被投毒或篡改，需要分层可验证机制而非单点防御。
- 主要主张：SBOM 提供清单（CycloneDX=全栈 BOM+VEX，SPDX=ISO 标准）；SLSA 用分级 provenance 保证构建完整性；Sigstore 用身份签名替代密钥签名；OSV+Scorecard 让漏洞响应与实践检查自动化。
- 方法：文献精读 7 来源 → 按"攻击面↔机制"映射综合 → 产出分层检查清单（P0/P1/P2 × 单人项目特例）。
- 数据与证据：SLSA v1.2 L1–L3 要求矩阵；Scorecard 18 项检查及风险分级；CycloneDX ECMA-424/260+ 工具；SPDX ISO/IEC 5962:2021；Sigstore keyless 四步验证；GitHub 官方加固顺序。
- 结论：个人项目最优路径 = 漏洞告警先行 → 固定与缩权 → SBOM 消费闭环 → release 三件套 → Scorecard 持续自查。
- 局限：纯文献精读未实测工具；SBOM 非充分条件；SLSA hermetic builds 缺位；Sigstore 依赖 OIDC/Rekor 可用性；Scorecard 查表面不查恶意。
- 对我的启发：清单原子化与渐进分级可迁移到自建 review 流程；SBOM 必须"被消费"的闭环思维；AI/ML-BOM 是我 AI 工程项目的下一个选题。