SuperAPI AI Directory
Partner中文AI newsFavorites
Skillssupply-chain-security

supply-chain-security

Security & auditing

View repository

Updated 10-16 08:53

About this skill

Supply Chain Security Testing

When to Use

  • Auditing how software is built, packaged, and depended upon.
  • Verifying whether a disclosed CVE is actually reachable in a project.

Use cases

  • Software supply chain security assessment
  • Open source dependency vulnerability scanning and verification
  • CI/CD pipeline security audit
  • Container image security analysis
  • Third-party component compliance review
  • Build artifact provenance and integrity verification

Six-layer supply chain governance framework

Layer 1: 源码信任评估 → 上游仓库/维护者/发布历史审查
Layer 2: 构建管道集成 → CI/CD 安全门禁、签名验证
Layer 3: 制品分发完整性 → 签名、校验和、SBOM 附加
Layer 4: 运行时保护 → 容器扫描、准入控制
Layer 5: 持续监控 → CVE 实时追踪、漏洞可达性分析
Layer 6: 事件响应 → 供应链攻击应急、回滚策略

Workflow

1. SBOM generation and audit

生成 SBOM：
□ CycloneDX 格式: cdxgen → bom.json
□ SPDX 格式: sbom-tool generate
□ Syft: syft <image|dir> -o spdx-json

审计要点：
□ 是否存在未知/未授权的依赖
□ 是否存在已废弃/停止维护的包
□ 许可证冲突检测
□ 直接依赖 vs 传递依赖清单
□ 每个组件的发布时间线和维护者状态

2. Software composition analysis (SCA)

# OSV-Scanner（免费、Google 维护）
osv-scanner scan -r . --format json

# OWASP Dependency-Track（企业级持续监控）
# Deployment requires reviewed configuration, digest, access controls and authorization.
# → 上传 SBOM → 自动匹配 NVD/OSV/GitHub Advisory

# Snyk（商业）
snyk test --all-projects
# Persistent monitoring is a separately authorized operation.

# Trivy（容器 + 依赖 + IaC）
trivy fs .          # 文件系统扫描
trivy image nginx   # 容器镜像
trivy config .      # IaC 配置

3. Vulnerability reachability verification

SCA 告警需要结合实际版本、暴露面和调用路径验证。未提供可复现样本时，不声称固定的可达比例。

验证步骤：
1. 用 Dependency-Track 或 Trivy 获取 CVE 列表
2. 筛选 CVSS ≥ 7.0 的漏洞
3. 对有 PoC 的 CVE 做可达性分析
   - Code Property Graph 切片: 追踪用户输入到漏洞函数的路径
   - DEPTEX 方法: EPD (Execution Path Dominance) + LLM 语义验证
4. 在隔离环境中验证 PoC
5. 对可达的漏洞按实际影响排序修复优先级

Tool references:

  • CodeQL: GitHub code query → data flow analysis
  • Snyk Code: reachability tagging
  • DEPTEX: LLM-assisted context-aware risk assessment

4. CI/CD pipeline security

安全检查点：
□ 代码提交 → 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）

5. Container image security

# 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

6. Third-party dependency review

新增依赖 Checklist：
□ 维护状态：最近 6 个月有提交？维护者活跃度？
□ 安全历史：过去有无被植入恶意代码？
□ 依赖树：引入后新增多少传递依赖？
□ 许可证：与项目许可证兼容？
□ 替代方案：有无更安全的替代（Snyk Advisor / Socket.dev 评分）？

风险评估矩阵：
  高维护 × 低依赖数 × 兼容许可证 → 低风险
  低维护 × 高依赖数 × 许可证冲突 → 高风险

Toolchain

Use the OSV-Scanner, Trivy, Syft, cdxgen, Cosign, Gitleaks, or CodeQL already installed and version-locked in the project. Verify the actual executable paths and official version notes; installing new tools requires reviewing the source, immutable version, and checksum first, and do not execute online download scripts or automatic global installations. Tool capabilities, paid conditions, and reachability support depend on the actual version and cannot be inferred from the tool name.

Scanning private dependencies, uploading SBOMs, continuous monitoring, pulling public images, and signing and pushing all have network, data, or cost boundaries. Confirm the target and authorization first; by default, only generate reports in an authorized local directory, and do not start services or register monitoring.

References

  • references/sbom-sca-methodology.md — SBOM + SCA methodology
  • references/cicd-pipeline-security.md — CI/CD pipeline security audit

Task completion self-check (MUST pass before claiming completion)

  • Did I execute every step in the workflow (rather than just read it)?
  • Did I base this on tool-index and use real tool paths?
  • Did I produce reproducible evidence (commands/scripts/screenshots/reports)?
  • Did I complete and write back the Checklist items required by RULES?

Limitations

  • SBOM completeness depends on ecosystem tooling maturity.
  • Reachability analysis is heuristic; manual confirmation advised.

Adapted from zhaoxuya520/reverse-skill (MIT).