<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
---
name: supply-chain-security
description: >-
  Software supply chain security including dependency vulnerability management,
  SBOM lifecycle, SLSA framework compliance, package manager security (npm/PyPI/
  Maven), build pipeline integrity, code signing, artifact verification, typosquatting
  detection, and vendor risk assessment.
domain: cybersecurity
subdomain: supply-chain-security
tags:
  - supply-chain
  - sbom
  - slsa
  - dependency-management
  - code-signing
  - typosquatting
  - vendor-risk
  - sigstore
  - npm-security
  - package-security
version: "1.0"
author: defconxt
license: AGPL-3.0
compatibility: Designed for Claude Code, GitHub Copilot, OpenAI Codex, Cursor, Gemini CLI, and any agentskills.io-compatible agent.
metadata:
  mitre-attack: ["T1195", "T1195.001", "T1195.002", "T1199"]
  nist-csf: ["ID.SC-1", "ID.SC-2", "ID.SC-4", "PR.DS-6"]
  frameworks: ["SLSA v1.0", "NIST SP 800-161", "CISA Secure Software Development"]
---

# Supply Chain Security

## When to Use

Activate when the operator asks about software supply chain attacks, dependency
security, SBOM management, SLSA compliance, package integrity verification,
vendor risk assessment, or build pipeline security.

Mode: `[MODE: ARCHITECT]` for supply chain design; `[MODE: BLUE]` for monitoring; `[MODE: RED]` for supply chain attack simulation.

## Quick Reference

| Control | Tool / Action | Stage |
|---------|--------------|-------|
| Dependency audit | `npm audit` / `pip-audit` / `mvn dependency:check` | Development |
| Typosquatting check | `safety check -r requirements.txt` | CI |
| SBOM generation | `syft . -o cyclonedx-json` | Build |
| SBOM vulnerability scan | `grype sbom:sbom.cdx.json` | Build/Deploy |
| Build provenance | SLSA GitHub Generator | Release |
| Artifact signing | `cosign sign --key cosign.key image:tag` | Release |
| Signature verification | `cosign verify --key cosign.pub image:tag` | Deploy |
| Lock file audit | `npm ci` (strict) / `pip install --require-hashes` | Build |
| Vendor assessment | CAIQ (CSA Consensus Assessment) | Procurement |

## Workflow

### 1. Dependency Attack Vectors

```
Attack taxonomy:
├── Typosquatting: Publish malicious package with similar name
│   Example: "colorsss" instead of "colors", "python-dateutil" typos
├── Dependency confusion: Internal package name claimed on public registry
│   Example: Private "company-utils" → attacker publishes to npm/PyPI
├── Maintainer compromise: Attacker gains control of legitimate package
│   Example: event-stream (npm), ua-parser-js, node-ipc
├── Build system compromise: Inject malicious code during build
│   Example: SolarWinds Orion (Sunburst), Codecov bash uploader
├── Malicious updates: Legitimate package pushes malicious version
│   Example: colors.js/faker.js (maintainer protest)
└── Abandoned package takeover: Claim ownership of unmaintained packages
    Example: Package with expired maintainer email domain
```

### 2. Dependency Hardening

```bash
# npm — audit and fix
npm audit --audit-level=high
npm audit fix --force  # Use cautiously

# npm — lockfile integrity
npm ci  # Installs exactly from package-lock.json

# Python — audit with pip-audit
pip-audit -r requirements.txt -f json
pip install --require-hashes -r requirements.txt

# Python — dependency confusion prevention
pip install --index-url https://internal.pypi.company.com/simple/ \
  --extra-index-url https://pypi.org/simple/ package-name

# Go — verify module checksums
go mod verify  # Verify against go.sum
GONOSUMCHECK=off go mod tidy  # Enforce checksum verification

# Lock file best practices:
# - ALWAYS commit lock files (package-lock.json, yarn.lock, Pipfile.lock)
# - Use --frozen-lockfile in CI (npm ci, yarn --frozen-lockfile)
# - Review lock file diffs in PRs for unexpected changes
# - Pin exact versions for critical dependencies
```

### 3. SBOM Management

```bash
# Generate SBOM (CycloneDX format)
syft packages dir:. -o cyclonedx-json > sbom.cdx.json

# Generate SBOM for container image
syft packages docker:app:latest -o spdx-json > sbom.spdx.json

# Scan SBOM for vulnerabilities
grype sbom:sbom.cdx.json --only-fixed --fail-on high

# SBOM lifecycle:
# 1. Generate at build time (every release)
# 2. Store with release artifacts
# 3. Scan continuously against updated vuln databases
# 4. Share with customers/regulators on request
# 5. Update when dependencies change
```

### 4. SLSA Framework

```
SLSA Levels:
Level 0: No guarantees (most projects today)
Level 1: Provenance exists, build automated
Level 2: Hosted build, signed provenance
Level 3: Hardened build, non-falsifiable provenance
Level 4: Two-person review, hermetic/reproducible

Implementation checklist:
├── Level 1:
│   ├── Automated build process (no manual steps)
│   ├── Generate provenance metadata
│   └── Publish provenance with artifacts
├── Level 2:
│   ├── Build on hosted CI (GitHub Actions, GitLab CI)
│   ├── Provenance signed by build platform
│   └── Authenticated provenance source
├── Level 3:
│   ├── Hardened CI configuration (no arbitrary code in build)
│   ├── Isolated build environment
│   ├── Non-falsifiable provenance (platform-signed, not user-signed)
│   └── Verified source repository
└── Level 4:
    ├── Two-person code review required
    ├── Hermetic build (no network access during build)
    ├── Reproducible build (same input → same output)
    └── Parameterless build (all config from source)
```

### 5. Vendor Risk Assessment

```
Assessment framework:
├── Security questionnaire (SIG Lite, CAIQ, custom)
├── SOC 2 Type II report review
├── Penetration test report review
├── Data processing agreement (DPA) for GDPR
├── Business continuity / disaster recovery plan
├── Incident notification timeline (contractual SLA)
├── Subprocessor management (who else touches data?)
├── Right to audit clause
└── Exit strategy (data portability, deletion)

Continuous monitoring:
├── SecurityScorecard / BitSight rating
├── Public breach notification monitoring
├── Certificate transparency log monitoring
├── DNS/domain registration monitoring
└── Dark web credential monitoring for vendor domains
```

## Verification

- [ ] Dependency audit passing with zero high/critical vulnerabilities
- [ ] Lock files committed and enforced in CI
- [ ] SBOM generated for every release
- [ ] Artifact signing implemented (Sigstore/cosign)
- [ ] Dependency confusion mitigated (scoped packages, internal registry)
- [ ] SLSA Level 2+ achieved for production releases
- [ ] Vendor risk assessments completed for critical vendors
- [ ] Typosquatting detection active for internal package names
