供应 链安全测试（Supply Chain Security Testing）
一、用途与适用场景
当需要审计软件是如何被构建、打包和依赖时，或需要验证某个已披露的 CVE 在项目中是否实际可达时，可使用本技能。适用场景包括：软件供应链安全评估、开源依赖漏洞扫描与验证、CI/CD 管道安全审计、容器镜像安全分析、第三方组件合规审查、构建产物溯源与完整性验证。
二、六层供应链治理框架
- Layer 1：源码信任评估 —— 上游仓库、维护者、发布历史审查。
- Layer 2：构建管道集成 —— CI/CD 安全门禁、签名验证。
- Layer 3：制品分发完整性 —— 签名、校验和、SBOM 附加。
- Layer 4：运行时保护 —— 容器扫描、准入控制。
- Layer 5：持续监控 —— CVE 实时追踪、漏洞可达性分析。
- Layer 6：事件响应 —— 供应链攻击应急、回滚策略。
三、工作流
- SBOM 生成与审计
生成 SBOM：
- CycloneDX 格式：cdxgen → bom.json
- SPDX 格式：sbom-tool generate
- Syft：syft <image|dir> -o spdx-json
审计要点：
- 是否存在未知/未授权的依赖
- 是否存在已废弃/停止维护的包
- 许可证冲突检测
- 直接依赖 vs 传递依赖清单
- 每个组件的发布时间线和维护者状态
- 软件组成分析（SCA）
- OSV-Scanner（免费、Google 维护）：osv-scanner scan -r . --format json
- OWASP Dependency-Track（企业级持续监控）：部署需要经过审核的配置、摘要、访问控制和授权；上传 SBOM 后自动匹配 NVD/OSV/GitHub Advisory。
- Snyk（商业）：snyk test --all-projects；持续监控属于需单独授权的操作。
- Trivy（容器 + 依赖 + IaC）：trivy fs .（文件系统扫描）、trivy image nginx（容器镜像）、trivy config .（IaC 配置）。
- 漏洞可达性验证
SCA 告警需要结合实际版本、暴露面和调用路径进行验证。未提供可复现样本时，不声称固定的可达比例。
验证步骤：
- 用 Dependency-Track 或 Trivy 获取 CVE 列表；
- 筛选 CVSS ≥ 7.0 的漏洞；
- 对有 PoC 的 CVE 做可达性分析：代码属性图切片追踪用户输入到漏洞函数的路径；DEPTEX 方法（EPD 执行路径支配 + LLM 语义验证）；
- 在隔离环境中验证 PoC；
- 对可达的漏洞按实际影响排序修复优先级。
工具参考：CodeQL（GitHub 代码查询，数据流分析）、Snyk Code（可达性标记）、DEPTEX（LLM 辅助上下文感知风险评估）。
- CI/CD 管道安全
安全检查点：
- 代码提交 → pre-commit hook：gitleaks（密钥扫描）
- PR 阶段 → SCA 扫描（Trivy/OSV-Scanner）
- 构建阶段 → 制品签名（cosign）
- 推送阶段 → SBOM 附加（syft + attest）
- 部署阶段 → 准入控制（OPA/Kyverno + 镜像扫描）
- 运行时 → 持续漏洞监控（Dependency-Track）
管道自身安全：
- Pipeline as Code 审计（GitHub Actions / GitLab CI 配置注入）
- Runner 隔离（防止恶意构建突破容器）
- 密钥管理（Actions Secrets / Vault，禁止硬编码）
- 第三方 Action 审查（锁定 commit SHA，而非 tag）
- 容器镜像安全
- Dockerfile 审计：hadolint Dockerfile
- 镜像扫描（多层：OS + 应用依赖 + 配置）：trivy image --severity HIGH,CRITICAL nginx:latest
- 最小基础镜像：优先 distroless → alpine → slim → 避免 latest；docker scout quickview nginx:latest
- 镜像签名：cosign sign --key cosign.key myimage:tag；cosign verify --key cosign.pub myimage:tag
- 第三方依赖审查
新增依赖 Checklist：
- 维护状态：最近 6 个月有提交？维护者活跃度？
- 安全历史：过去有无被植入恶意代码？
- 依赖树：引入后新增多少传递依赖？
- 许可证：与项目许可证兼容？
- 替代方案：有无更安全的替代（Snyk Advisor / Socket.dev 评分）？
风险评估矩阵：高维护 × 低依赖数 × 兼容许可证 → 低风险；低维护 × 高依赖数 × 许可证冲突 → 高风险。
四、工具链与执行边界
使用项目已安装并锁定版本的 OSV-Scanner、Trivy、Syft、cdxgen、Cosign、Gitleaks 或 CodeQL。核对真实可执行路径及官方版本说明；安装新工具需先审核来源、不可变版本和校验和，不执行在线下载脚本或自动全局安装。工具能力、付费条件和可达性支持取决于实际版本，不能从工具名推断。
扫描私有依赖、上传 SBOM、持续监控、公开镜像拉取、签名及推送均有网络、数据或成本边界。先确认目标和授权；默认仅在获准的本地目录生成报告，不启动服务或注册监控。
五、参考
- references/sbom-sca-methodology.md：SBOM + SCA 方法论
- references/cicd-pipeline-security.md：CI/CD 管道安全审计
六、任务完成自检（声称完成前 MUST 通过）
- 是否执行了工作流中的每一步（而不是只阅读）？
- 是否基于 tool-index 使用了真实工具路径？
- 是否产出了可复现证据（命令/脚本/截图/报告）？
- 是否完成并回写了 RULES 要求的 Checklist 项？
七、限制
- SBOM 完整性取决于各生态工具的成熟度。
- 可达性分析是启发式的，建议人工确认。
- 改编自 zhaoxuya520/reverse-skill（MIT）。