/20-supply-chain-security

name: Supply Chain Security
description: Software supply chain security — SBOM generation and analysis, dependency confusion and typosquatting detection, malicious package indicators, CI/CD pipeline hardening, and artifact provenance/signing (SLSA, Sigstore)
version: 3.1.0
author: Masriyan
tags: [cybersecurity, supply-chain, sbom, sca, typosquatting, dependency-confusion, slsa, sigstore, ci-cd-security, provenance]

Supply Chain Security

Purpose

Enable Claude to assess and harden the software supply chain end-to-end: what a project depends on, how those dependencies got in, how they were built, and how anyone downstream can trust the result. This complements Skill 02 (Vulnerability Scanner) — Skill 02 asks "is this known-vulnerable version?"; this skill asks "is this dependency, build, or pipeline something to trust at all?"

---

Activation Triggers

This skill activates when the user asks about:

• SBOM (Software Bill of Materials) generation, validation, or analysis (CycloneDX, SPDX)
• Dependency confusion, typosquatting, or malicious/compromised packages (npm, PyPI, RubyGems, crates.io, Maven, Go modules)
• Suspicious `postinstall`/`preinstall` scripts or other package lifecycle hooks
• CI/CD pipeline security — GitHub Actions, GitLab CI, Jenkins hardening
• Artifact signing, provenance, or attestation — SLSA levels, in-toto, Sigstore/cosign, npm provenance
• Build reproducibility or "does this build match what's published" questions
• Vendor/open-source component risk as part of onboarding a new dependency
• Incidents referencing a compromised upstream package, maintainer account takeover, or a poisoned build pipeline

---

Prerequisites

pip install pyyaml requests

**Optional enhanced tools:**

• `syft` / `cyclonedx-py` / `cdxgen` — SBOM generation (CycloneDX/SPDX)
• `grype` / `osv-scanner` — SBOM-driven vulnerability matching (pairs with Skill 02)
• `cosign` — artifact/image signing and verification (Sigstore)
• `slsa-verifier` — verify SLSA provenance attestations
• `scorecard` (OpenSSF) — automated supply-chain risk scoring for a GitHub repo

---

Core Capabilities

1. SBOM Generation & Analysis

**When the user asks to generate or review an SBOM:**

1. Identify the ecosystem(s) in the project (see manifest map below) and generate a CycloneDX or SPDX SBOM with the appropriate tool (`syft dir:. -o cyclonedx-json`, `cyclonedx-py`, or language-native equivalents) — or, without tooling, build a manual component list directly from lockfiles. 2. For each component, capture: name, version, ecosystem/PURL, declared license, and (if available) known vulnerabilities. 3. Cross-reference against Skill 02's vulnerability scanning for a combined SBOM+VEX view: which components are affected, and which affected components are actually reachable in the code. 4. Flag components with no discoverable source repository, an unusually recent first-publish date paired with a sudden high download count, or a license that conflicts with project policy (e.g., copyleft in a proprietary product).

2. Dependency Confusion & Typosquatting Detection

**When the user asks to audit dependencies for malicious/confusable packages:**

1. **Typosquatting** — compare declared package names against well-known popular packages in the same ecosystem for near-miss names (edit distance, added/dropped hyphen, swapped separator, homoglyphs). 2. **Dependency confusion** — for any internal/private package name, confirm it is actually scoped (npm `@org/pkg`) or otherwise cannot be shadowed by a same-named public package; flag any internal package referenced without a scope or private-registry pin. 3. **Registry existence & metadata** — verify a package still exists at its declared registry, and treat a sudden maintainer change, drastically inflated version jump, or an empty/near-empty README on a long-lived package as a signal worth flagging. 4. Use `scripts/supply_chain_auditor.py` for the automatable parts (typosquat distance, floating versions, missing lockfile, lifecycle-script red flags); apply human judgment for anything the script surfaces as a near-miss rather than treating a hit as proof of compromise.

3. Malicious Package Indicators

**When reviewing a specific package (new dependency, or a flagged one) for compromise:**

Look for, in order of severity:

• **Lifecycle script abuse** — `preinstall`/`install`/`postinstall`/`prepare` hooks that fetch and execute remote code, decode base64 blobs, or read CI/registry credentials from the environment (`NPM_TOKEN`, `GITHUB_TOKEN`, cloud secrets).
• **Obfuscation** — minified/packed code in a package that has no legitimate reason to ship obfuscated source (most libraries don't need this).
• **Network exfiltration** — outbound calls to raw IP literals, unfamiliar domains, or DNS-based exfiltration patterns embedded in otherwise unrelated code.
• **Version/behavior mismatch** — a patch-level version bump that changes dependencies, adds install scripts, or touches unrelated files (compare the diff between versions, not just the changelog).

4. CI/CD Pipeline Hardening

**When the user asks to review a build/deploy pipeline:**

GitHub Actions Checklist

[ ] Third-party actions pinned to a full commit SHA, not a mutable tag/branch
[ ] Workflow declares explicit top-level `permissions:` (default is broad without it)
[ ] pull_request_target is never combined with checkout of PR head + code execution
[ ] Secrets are scoped to the job/environment that needs them, not global
[ ] Self-hosted runners are not used for public-repo PR workflows (arbitrary code execution risk)
[ ] Reusable/composite actions from third parties are reviewed like any other dependency
[ ] Build artifacts are published with provenance (see below), not just uploaded raw

General CI/CD Checklist (any platform)

[ ] Build environment is ephemeral / reproducible, not a long-lived hand-configured box
[ ] Dependency resolution uses lockfiles, not f