Software Supply Chain Security Guide

A defender’s reference for software supply chain risks — threat model across the SDLC, package-registry attack patterns, CI/CD hardening, artifact provenance and signing, SBOMs, dependency scanning, case studies, and a checklist. Compiled from 54 research articles, advisories, and incident writeups in raw/Supply Chain/.

Table of Contents

1. Fundamentals
2. Threat Model Across the SDLC
3. Package Registry Risks
4. Dependency Confusion, Typosquatting, Slopsquatting
5. Maintainer Account Compromise
6. CI/CD Pipeline Hardening
7. Container Image Provenance & Verification
8. SLSA Framework
9. Sigstore, Cosign, in-toto
10. SBOMs (SPDX, CycloneDX)
11. Dependency Scanning Tooling
12. Developer Host Hardening
13. Admission Control & Runtime Verification
14. Case Studies — Defensive Lessons
15. Detection Signals & IOCs
16. Defender Checklist
17. Reference Configurations

1. Fundamentals

A software supply chain attack compromises a dependency, tool, build system, or distribution channel that the target trusts, rather than attacking the target directly. The malicious payload rides in on a routine npm install, pip install, docker pull, or CI build — bypassing perimeter defenses because the artifact appears legitimate.

Why the category exploded:

OWASP Top 10 2025 — A03 Software Supply Chain Failures:

Growth: Supply chain attacks on package registries surged 73% in 2025–2026. Sonatype tracked a 742% increase between 2019 and 2022. OSSF and Bastion 2026 reports attribute the spike to nation-state actors (notably DPRK clusters publishing ~1,700 malicious packages across npm, PyPI, Go, and Rust), credential-stealing worms, and industrialized typosquatting.

2. Threat Model Across the SDLC

Map threats to lifecycle stages. Each stage has distinct actors, assets, and controls.

STRIDE per stage: Every stage maps to Spoofing (forged provenance), Tampering (injected code), Repudiation (missing attestations), Information disclosure (leaked secrets via install scripts), DoS (dependency deletion à la left-pad), and Elevation (signing-key theft).

Blast-radius formula:

blast_radius = trust_score(package) × downstream_installs × window_before_detection × privilege(install_context)

Reduce any factor. Release-age gates attack window_before_detection; ignore-scripts attacks privilege(install_context); pinning attacks trust_score drift.

3. Package Registry Risks

Registry-by-registry quick reference

Attack pattern taxonomy

4. Dependency Confusion, Typosquatting, Slopsquatting

Dependency confusion (Birsan 2021)

Occurs when a package manager prefers public registries over private ones for a name used both internally and publicly.

npm mitigation:

# .npmrc
@myorg:registry=https://nexus.myorg.local/repository/npm-private/
registry=https://registry.npmjs.org/
always-auth=true

pip / uv mitigation:

# pip.conf — single index, no extra-index-url fallback
[global]
index-url = https://artifactory.myorg.local/artifactory/api/pypi/pypi/simple/

Avoid --extra-index-url — it merges indices and picks highest version. Use --index-url to a repository-manager virtual registry that proxies public content behind policy.

Typosquatting

Slopsquatting (AI-coined)

LLMs regularly hallucinate plausible-sounding package names. Attackers squat those names. Defensive verification before installing any AI-suggested package:

# npm
npm view <pkg> time.created versions maintainers --json

# PyPI
curl -s https://pypi.org/pypi/<pkg>/json | jq '{name:.info.name,author:.info.author,home_page:.info.home_page,releases:(.releases|keys|length)}'

Red flags: created <30 days ago, single maintainer, no linked repo, download count in tens, no release history.

5. Maintainer Account Compromise

Phishing an npm/PyPI maintainer became the single most prolific entry vector in 2025–2026 (Chalk, Debug, Axios, LiteLLM, Telnyx, Shai-Hulud, Shai-Hulud 2.0).

Key principle: a legitimate publisher account with a valid 2FA bypass is indistinguishable from the real maintainer at the artifact level. The only durable defense is post-publish attestation verification (SLSA provenance + Sigstore identity) tied to a CI workflow identity rather than a human account.

6. CI/CD Pipeline Hardening

CI/CD is high-value: it holds secrets, has network egress, and signs artifacts. Compromising it turns it into a factory for malicious releases.

Control baseline

GitHub Actions hardened job skeleton

name: build-and-release
on:
  push:
    tags: ['v*']

permissions:
  contents: read
  id-token: write      # for keyless cosign + OIDC to cloud
  packages: write      # scoped; only if publishing to GHCR

jobs:
  build:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11  # v4.1.1 pinned SHA
        with:
          persist-credentials: false

      - uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8  # v4.0.2
        with:
          node-version: 20
          cache: 'npm'

      - run: npm ci --ignore-scripts

      - run: npm run build

      - name: Generate SBOM
        uses: anchore/sbom-action@d94f46e13c6c62f59525ac9a1e147a99dc0b9bf5
        with:
          format: cyclonedx-json
          output-file: sbom.cdx.json

      - name: Scan SBOM
        uses: anchore/scan-action@be7a22da4f22dde4c7c9e0b14dea0d0f7a4a16a3
        with:
          sbom: sbom.cdx.json
          fail-build: true
          severity-cutoff: high

      - name: Build & push image
        id: build
        run: |
          IMAGE=ghcr.io/${​{ github.repository }}:${​{ github.ref_name }}
          docker build -t "$IMAGE" .
          docker push "$IMAGE"
          echo "digest=$(docker inspect --format='{​{index .RepoDigests 0}}' $IMAGE)" >> "$GITHUB_OUTPUT"

      - name: Sign image (keyless)
        env:
          COSIGN_EXPERIMENTAL: "1"
        run: cosign sign --yes ${​{ steps.build.outputs.digest }}

      - name: Attest SBOM
        run: |
          cosign attest --yes --predicate sbom.cdx.json \
            --type cyclonedx ${​{ steps.build.outputs.digest }}

      - name: Attest SLSA provenance
        uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v2.0.0
        with:
          image: ${​{ steps.build.outputs.digest }}

Runner egress allowlist (example)

registry.npmjs.org
pypi.org
files.pythonhosted.org
ghcr.io
*.actions.githubusercontent.com
fulcio.sigstore.dev
rekor.sigstore.dev
oauth2.sigstore.dev

Block everything else. Most supply-chain malware phones home on install — an allowlist surfaces it immediately.

7. Container Image Provenance & Verification

Container images are the delivery unit and must be identified by digest, not tag.

Base image hygiene

cosign image sign + verify

# Keyless sign (uses OIDC → Fulcio → Rekor)
COSIGN_EXPERIMENTAL=1 cosign sign --yes \
  ghcr.io/myorg/app@sha256:abcd...

# Verify against expected CI workflow identity
cosign verify \
  --certificate-identity-regexp="^https://github.com/myorg/app/\.github/workflows/release\.yml@refs/tags/v.*$" \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
  ghcr.io/myorg/app@sha256:abcd...

The identity regex is the critical verification step — it binds the signature to a specific workflow file in a specific repo, so a compromise of a different repo cannot produce a valid signature for this image.

8. SLSA Framework

SLSA (Supply-chain Levels for Software Artifacts, “salsa”) gives a vocabulary and progressive maturity levels for build integrity. Developed originally from Google’s Binary Authorization for Borg, donated to OpenSSF in 2021, now at v1.1.

Build track levels

Note: SLSA v1.0+ consolidated former L4 — hermetic and reproducible builds are now recommended practices, not strict requirements.

Provenance attack vectors addressed

Minimal in-toto / SLSA provenance document

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "ghcr.io/myorg/app",
    "digest": {"sha256": "abcd1234..."}
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://github.com/slsa-framework/slsa-github-generator/container@v1",
      "externalParameters": {
        "repository": "https://github.com/myorg/app",
        "ref": "refs/tags/v1.2.3"
      },
      "resolvedDependencies": [
        {"uri": "git+https://github.com/myorg/app", "digest": {"gitCommit": "f00..."}}
      ]
    },
    "runDetails": {
      "builder": {
        "id": "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v2.0.0"
      },
      "metadata": {
        "invocationId": "https://github.com/myorg/app/actions/runs/1234567890/attempts/1",
        "startedOn": "2026-04-01T12:00:00Z"
      }
    }
  }
}

SLSA 3 for Go modules (GitHub Actions + Sigstore)

GitHub provides a reusable workflow (slsa-framework/slsa-github-generator-go) that automates SLSA L3 for Go projects. The workflow uses the Actions OIDC token to bind provenance to the exact repository, branch, commit, and workflow file. Cosign + Fulcio issue a short-lived certificate from the OIDC identity, and Rekor logs the signing event. No long-lived signing keys are needed. This pattern is extensible to other ecosystems via the generic slsa-github-generator.

Consumer verification workflow

1. Download artifact + provenance bundle.
2. Verify Sigstore signature against certificate transparency log (Rekor).
3. Check builder.id matches allowlisted trusted builder.
4. Match artifact digest against subject.digest.
5. Match externalParameters.repository and ref against expected.
6. Policy engine (Kyverno / Conftest / OPA) approves or rejects.

9. Sigstore, Cosign, in-toto

Component map

Keyless signing flow

dev/CI → OIDC (GitHub, Google, etc.) → Fulcio (issues 10-min cert bound to identity)
      → cosign signs artifact with ephemeral key
      → signature + cert logged in Rekor transparency log
      → verifiers check cert identity + Rekor inclusion proof

Benefit: no long-lived signing keys to manage or exfil.

Common cosign operations

# Keyless sign a blob
cosign sign-blob --yes --bundle release.cosign.bundle release.tar.gz

# Verify blob using expected identity
cosign verify-blob \
  --bundle release.cosign.bundle \
  --certificate-identity-regexp="^https://github.com/myorg/app/.*$" \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
  release.tar.gz

# Attach an SBOM attestation
cosign attest --yes --predicate sbom.cdx.json --type cyclonedx \
  ghcr.io/myorg/app@sha256:abcd...

# Download + inspect attestation
cosign download attestation ghcr.io/myorg/app@sha256:abcd... | \
  jq -r '.payload' | base64 -d | jq .

# Verify SLSA provenance predicate
cosign verify-attestation --type slsaprovenance \
  --certificate-identity-regexp="^https://github.com/slsa-framework/.*$" \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
  ghcr.io/myorg/app@sha256:abcd...

cosign verification of ecosystem provenance bundles

Since cosign v2.4.0, you can verify attestations in the bundle format used by npm provenance, GitHub Artifact Attestations, and Homebrew provenance. Over 16,000 npm packages publish with provenance.

# Verify npm provenance (e.g., semver@7.6.3)
curl https://registry.npmjs.org/semver/-/semver-7.6.3.tgz > semver-7.6.3.tgz
curl https://registry.npmjs.org/-/npm/v1/attestations/semver@7.6.3 | \
  jq '.attestations[]|select(.predicateType=="https://slsa.dev/provenance/v1").bundle' > npm-provenance.sigstore.json
cosign verify-blob-attestation --bundle npm-provenance.sigstore.json --new-bundle-format \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  --certificate-identity-regexp="^https://github.com/npm/node-semver/.github/workflows/release-integration.yml.?" \
  semver-7.6.3.tgz

# Verify GitHub Artifact Attestation
gh attestation verify gh_2.54.0_linux_armv6.tar.gz --owner cli

The Ultralytics incident demonstrated the value: PyPI staff used Sigstore transparency logs and publish attestations to determine the first malicious releases came through the legitimate GitHub Actions workflow (build-phase injection), while the second round had no attestations at all (stolen API token). Once tooling enforces attestation presence at install time, tokenless publishes become detectable.

Key-based signing (fallback for air-gapped builds)

cosign generate-key-pair                        # cosign.key / cosign.pub
cosign sign --key cosign.key ghcr.io/app:1.0.0
cosign verify --key cosign.pub ghcr.io/app:1.0.0

Store private keys in HSM or KMS (--key awskms://…, --key gcpkms://…); never embed in CI secrets if OIDC is available.

10. SBOMs (SPDX, CycloneDX)

An SBOM is a machine-readable inventory of components, versions, licenses, and relationships in an artifact. It answers “is package X at version Y present?” in seconds when the next Log4Shell drops.

CISA 2025 Minimum Elements update

CISA updated its SBOM guidance (originally NTIA 2021) to reflect current maturity. Key additions: machine-processable formats are now required (not just recommended), SBOMs must integrate into broader cybersecurity practices (not standalone compliance artifacts), and the guidance emphasizes scalable implementation across both public and private sectors. Organizations should align SBOM programs to this updated baseline.

Minimum viable SBOM practice

1. Generate at build time (not post-hoc from a registry).
2. Attach to the artifact (cosign attest --type cyclonedx).
3. Sign the SBOM.
4. Store versioned alongside the release.
5. Feed to a vuln scanner on every pull request and on new CVE disclosure.
6. Diff SBOMs between releases to surface new transitive deps.

Generation commands

# Syft — filesystem
syft dir:. -o cyclonedx-json=sbom.cdx.json -o spdx-json=sbom.spdx.json

# Syft — container image
syft ghcr.io/myorg/app@sha256:abcd... -o cyclonedx-json=sbom.cdx.json

# cdxgen (language-native)
cdxgen -r -t javascript -o sbom.cdx.json

# Trivy
trivy image --format cyclonedx --output sbom.cdx.json ghcr.io/myorg/app@sha256:abcd...

# Docker buildx native
docker buildx build --sbom=true --provenance=mode=max -t myimage .

SBOM vulnerability scan

# Grype against the SBOM (consistent regardless of runtime env)
grype sbom:sbom.cdx.json --fail-on high

# OSV-Scanner against the SBOM
osv-scanner --sbom sbom.cdx.json

# Dependency-Track upload
curl -X POST "https://dtrack.myorg.local/api/v1/bom" \
  -H "X-API-Key: $DTRACK_TOKEN" \
  -F "autoCreate=true" \
  -F "projectName=myorg/app" \
  -F "projectVersion=1.2.3" \
  -F "bom=@sbom.cdx.json"

SBOM diff for transitive-dep injection detection

# Naive: detect new direct or transitive deps between tags
diff <(jq -r '.components[] | "\(.name)@\(.version)"' old.cdx.json | sort) \
     <(jq -r '.components[] | "\(.name)@\(.version)"' new.cdx.json | sort)

Run in PR CI — alert a human on any new dependency added by a minor/patch version bump of an existing dependency. This is the signal that would have caught the Axios → plain-crypto-js injection.

11. Dependency Scanning Tooling

OSV-Scanner CI usage

- name: OSV scan
  uses: google/osv-scanner-action/osv-scanner-action@v1.9.0
  with:
    scan-args: |-
      --lockfile=package-lock.json
      --lockfile=poetry.lock
      --recursive
      --fail-on-vuln

Dependabot minimal config

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule: { interval: "daily" }
    open-pull-requests-limit: 10
    groups:
      production:
        dependency-type: "production"
      development:
        dependency-type: "development"
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule: { interval: "weekly" }
  - package-ecosystem: "docker"
    directory: "/"
    schedule: { interval: "weekly" }

Renovate minimal config

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended", ":pinAllExceptPeerDependencies"],
  "minimumReleaseAge": "7 days",
  "pinDigests": true,
  "packageRules": [
    {"matchManagers": ["github-actions"], "pinDigests": true},
    {"matchUpdateTypes": ["patch"], "automerge": true, "automergeType": "pr"}
  ],
  "vulnerabilityAlerts": {"enabled": true, "labels": ["security"]}
}

minimumReleaseAge: "7 days" is the single most effective Renovate setting: it refuses to auto-bump into a version published less than 7 days ago, which is the window most malicious releases live before takedown.

12. Developer Host Hardening

Developer workstations and personal laptops are now prime targets (Shai-Hulud, OpenVSX compromises, Glassworm). Two host-level defenses block the majority of opportunistic install-time attacks:

1. Release-age gates — refuse to install any package version published <7 days ago.
2. Disable install lifecycle scripts — postinstall, preinstall, prepare. This is the #1 execution vector for npm malware.

Per-package-manager configs (from 2026 practitioner gist)

uv (Python) — ~/.config/uv/uv.toml

exclude-newer = "7 days"

pip (Python) — ~/.config/pip/pip.conf + shell alias

[global]
index-url = https://artifactory.myorg.local/artifactory/api/pypi/pypi/simple/

# macOS / BSD date
alias pip='pip --uploaded-prior-to $(date -u -v-7d +%Y-%m-%dT%H:%M:%SZ)'
# Linux / GNU date
alias pip='pip --uploaded-prior-to $(date -u -d "7 days ago" +%Y-%m-%dT%H:%M:%SZ)'

npm — ~/.npmrc

min-release-age=7
ignore-scripts=true

pnpm — pnpm-workspace.yaml

minimumReleaseAge: 10080   # minutes = 7 days
minimumReleaseAgeExclude:
  - "@myorg/*"
  - "esbuild"

pnpm config set ignore-scripts true --global

yarn — ~/.yarnrc.yml

npmMinimalAgeGate: "7d"
enableScripts: false
npmPreapprovedPackages:
  - "@myorg/*"

bun — ~/.bunfig.toml

[install]
minimumReleaseAge = 10080

Bun disables lifecycle scripts by default.

Additional host hygiene

13. Admission Control & Runtime Verification

CI signing is only as useful as the deploy-time verification that enforces it. Without admission control, a compromised runner or registry can push unsigned images straight into production.

Kyverno policy — require cosign-verified images

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  validationFailureAction: Enforce
  background: false
  webhookTimeoutSeconds: 30
  rules:
    - name: check-image-signature
      match:
        any:
          - resources:
              kinds: [Pod]
      verifyImages:
        - imageReferences:
            - "ghcr.io/myorg/*"
          attestors:
            - entries:
                - keyless:
                    subject: "https://github.com/myorg/*/.github/workflows/release.yml@refs/tags/v*"
                    issuer: "https://token.actions.githubusercontent.com"
                    rekor:
                      url: https://rekor.sigstore.dev

Sigstore policy-controller — verify SLSA provenance predicate

apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: require-slsa-provenance
spec:
  images:
    - glob: "ghcr.io/myorg/**"
  authorities:
    - keyless:
        identities:
          - issuer: https://token.actions.githubusercontent.com
            subjectRegExp: "https://github.com/slsa-framework/slsa-github-generator/.*"
        ctlog:
          url: https://rekor.sigstore.dev
      attestations:
        - name: must-have-slsa
          predicateType: https://slsa.dev/provenance/v1
          policy:
            type: cue
            data: |
              predicate: {
                buildDefinition: {
                  externalParameters: {
                    repository: =~"^https://github.com/myorg/"
                  }
                }
              }

OPA Gatekeeper — deny unpinned image tags

package kubernetes.admission

deny[msg] {
  input.request.kind.kind == "Pod"
  image := input.request.object.spec.containers[_].image
  not contains(image, "@sha256:")
  msg := sprintf("image %q must be pinned by digest", [image])
}

Runtime

14. Case Studies — Defensive Lessons

Each case below summarizes what happened, how it was detected, and what defenders learned. No reproduction steps.

14.1 SolarWinds SUNBURST (2020)

14.2 Codecov Bash Uploader (2021)

14.3 Log4Shell / CVE-2021-44228 (2021)

14.4 Event-stream (2018)

14.5 Chalk / Debug / color-* (September 2025)

14.6 Nx / s1ngularity (August 2025)

14.7 Shai-Hulud npm worm (September 2025) — “First successful self-propagating npm worm”

14.8 Shai-Hulud 2.0 (November 2025)

14.9 Axios / plain-crypto-js (March 2026) — DPRK-attributed

14.10 TeamPCP campaign (March 2026, ongoing)

Unifying defensive lesson: credential theft → automated republishing is the modern blueprint. Required controls: (1) no long-lived publish tokens — OIDC Trusted Publishers only; (2) pinned, digest-bound Action SHAs; (3) signed tag enforcement; (4) egress allowlist on runners; (5) anomaly detection on publish velocity.

14.11 Glassworm (October 2025)

14.12 PhantomRaven (October 2025)

14.13 DPRK 1,700-package flood (2025–2026)

14.14 XZ Utils backdoor / CVE-2024-3094 (March 2024)

14.15 tj-actions/changed-files + reviewdog (CVE-2025-30066 / CVE-2025-30154, March 2025)

14.16 Ultralytics PyPI (December 2024)

14.17 dYdX npm + PyPI (2026)

14.18 React2Shell CVE-2025-55182 (Nov–Dec 2025)

Not a supply-chain injection but relevant as a dependency-triggered RCE: React Server Components 19.0.0–19.2.0 had a pre-auth RCE. Discovered by Lachlan Davidson; exploited within days by Earth Lamia, Jackpot Panda, Contagious Interview. Over 77,000 vulnerable IPs scanned by Shadowserver. CISA KEV December 17.

Defensive lesson: SBOM-driven scanning plus an emergency response playbook are load-bearing. The fastest organizations to patch had automated SBOM → KEV lookups.

14.19 Oracle EBS CVE-2025-61882 (Oct 2025) — Clop

Oracle E-Business Suite zero-day (CVSS 9.8) exploited by Clop for mass data theft (Barts Health, Canon, GlobalLogic, LKQ, Logitech, Mazda).

Lesson: Commercial dependencies need the same patching SLAs as OSS.

14.20 ToolShell CVE-2025-53770/-53771 (July 2025)

Chained SharePoint on-prem exploits by Linen Typhoon, Violet Typhoon, Storm-2603; ~396 systems compromised; web shells deployed.

Lesson: Internet-facing internally-run commercial software is a supply chain node — treat it with the same monitoring as your own binaries.

14.21 CitrixBleed 2 CVE-2025-5777 (June 2025)

Out-of-bounds read bypassing MFA / hijacking session tokens in NetScaler ADC/Gateway.

Lesson: Network-appliance firmware is supply chain. SBOM your appliances.

14.22 Bybit $1.5B (Feb 2025)

Wallet-software supply chain compromise executing only when the target wallet was active.

Lesson: Conditional payloads evade test benches. Runtime behavioral monitoring complements static analysis.

14.23 Composite: SolarWinds, Codecov, Log4Shell, XZ Utils

Common thread: a small number of high-trust components → catastrophic downstream. The only durable defense is verifiable provenance + SBOM transparency + deploy-time enforcement.

15. Detection Signals & IOCs

Build / CI signals

Package-level signals

Workstation / dev signals

Hunting queries (SIEM pseudocode)

# Anomalous npm publish from CI
process.name = "npm" AND argv contains "publish"
  AND runner.self_hosted = true
  AND runner.name NOT IN (allowlist)

# Credential file access by package install
process.parent IN ("npm","node","pip","python","uv")
  AND file.path MATCHES ("~/.aws/*","~/.ssh/*","~/.kube/*","~/.docker/*")

# New transitive dep in patch version
repo.event = "pull_request"
  AND file.path IN ("package-lock.json","poetry.lock","go.sum")
  AND diff.adds CONTAINS "new package" AND semver.bump = "patch"

16. Defender Checklist

Strategy

• Inventory every supply chain node: registries, CI systems, artifact repos, IDE extensions, base images, vendor SaaS
• Assign an owner per node with a runbook and rotation plan
• Establish patch SLAs per severity; measure MTTR to KEV
• Build an incident response playbook keyed to supply-chain scenarios (maintainer ATO, worm, hidden transitive, build poisoning)
• Table-top a Chalk/Debug-scale and an Axios-scale incident annually (include destructive Shai-Hulud 2.0 scenario with data loss)
• Align SBOM program to CISA 2025 Minimum Elements guidance

Source & Code

• Branch protection on default branch
• Required review (>=1), with CODEOWNERS for sensitive paths
• Signed commits + signed tags enforced
• Disallow force-push to protected branches/tags
• Secret scanning enabled on all repos (GitGuardian / GitHub push protection)
• No long-lived secrets in CI — OIDC federation to cloud

Dependencies

• Lockfiles committed for all language ecosystems
• --require-hashes or equivalent for reproducibility where supported
• Dependabot or Renovate enabled, with minimumReleaseAge >= 7 days
• OSV-Scanner or Trivy on every PR + on a nightly schedule
• Dependency-Track (or equivalent) SBOM aggregation and VEX
• Behavioral scanner (Socket, Phylum) wired into PR gate
• Private-registry virtual proxy (Nexus/Artifactory) quarantining new packages

Build / CI

• Ephemeral runners only
• GitHub Actions pinned by commit SHA, not tag
• Minimal permissions: per job; default deny
• ignore-scripts=true where possible in CI installs
• Egress allowlist on runners
• No toJSON(secrets) anywhere
• No pull_request_target with unsanitized user inputs; lint with zizmor
• Audit composite action transitive dependencies
• Review GitHub org team auto-invitation policies (reviewdog lesson)
• Enable tag protection rules to prevent tag re-pointing
• Tamper-evident audit log export
• Separation of duties: code author != release signer

Artifacts / Packaging

• SBOM generated at build (CycloneDX + SPDX)
• SBOM attached to artifact as attestation (cosign attest)
• Image signed keyless via cosign + Sigstore
• SLSA L3 provenance via slsa-github-generator
• Reproducible builds where feasible
• Artifacts immutable once published

Registry / Distribution

• 2FA required on all maintainer accounts (hardware, not SMS)
• Trusted Publishers (OIDC) replacing long-lived tokens
• Publish-alert notifications to shared channel
• Namespace/scope claim for internal packages on public registries
• Repository firewall quarantining newly published or low-reputation deps

Deploy / Runtime

• Admission controller (Kyverno / policy-controller) verifies cosign signature + SLSA predicate
• Images referenced by digest only
• Deny-by-default egress NetworkPolicy
• IMDSv2 only; workload identity; no baked creds
• Runtime detection (Falco/Tetragon) for shells-from-package dirs
• Canary / staged rollout — never deploy all systems simultaneously (OWASP A03 guidance)

Developer Host

• Release-age gate configured in npm/pnpm/yarn/bun/pip/uv
• ignore-scripts / enableScripts: false globally
• Hardware MFA on registry accounts
• EDR with script-execution telemetry
• IDE extension allowlist; review extension updates
• Verify AI-suggested packages before install (slopsquatting)
• Review AI CLI tool permissions and disable dangerous auto-approve flags
• Revoke unused PyPI API tokens when using Trusted Publishers

Response

• On suspected compromise, assume full credential exposure — rotate all secrets, cloud keys, SSH keys, tokens touched by the affected environment
• Rebuild affected workstations and CI runners from a clean image
• Pull audit logs for the suspected window
• Block the indicator at repository firewall and network egress
• Publish an internal advisory with affected package/version/IOC list
• Retrospect to close the gap that permitted the compromise

17. Reference Configurations

17.1 Full hardened .npmrc

registry=https://nexus.myorg.local/repository/npm-group/
@myorg:registry=https://nexus.myorg.local/repository/npm-private/
always-auth=true
audit=true
fund=false
save-exact=true
min-release-age=7
ignore-scripts=true
engine-strict=true
package-lock=true

17.2 Full hardened pip.conf

[global]
index-url = https://artifactory.myorg.local/artifactory/api/pypi/pypi/simple/
require-virtualenv = true
disable-pip-version-check = true
no-cache-dir = false
require-hashes = true

17.3 GitHub Actions repository default permissions

permissions:
  actions: read
  contents: read
  deployments: none
  id-token: none
  issues: none
  packages: none
  pages: none
  pull-requests: none
  repository-projects: none
  security-events: none
  statuses: none

Escalate per-workflow only where needed.

17.4 Trivy image + config scan

trivy image --severity HIGH,CRITICAL --exit-code 1 \
  --ignore-unfixed \
  --format sarif --output trivy.sarif \
  ghcr.io/myorg/app@sha256:abcd...

trivy config --severity HIGH,CRITICAL --exit-code 1 .
trivy fs --scanners secret,vuln,misconfig .

17.5 OSV-Scanner offline

osv-scanner --experimental-offline --experimental-download-offline-databases ./

17.6 Syft + Grype end-to-end

syft dir:. -o cyclonedx-json=sbom.cdx.json
cosign sign-blob --yes --bundle sbom.cosign.bundle sbom.cdx.json
grype sbom:sbom.cdx.json --fail-on high -o sarif > grype.sarif

17.7 Policy-as-code example (Conftest / OPA on Dockerfile)

package main

deny[msg] {
  input[i].Cmd == "from"
  val := input[i].Value[0]
  not contains(val, "@sha256:")
  msg := sprintf("FROM %s must use @sha256 digest", [val])
}

deny[msg] {
  input[i].Cmd == "run"
  contains(input[i].Value[_], "curl")
  contains(input[i].Value[_], "|")
  contains(input[i].Value[_], "sh")
  msg := "curl | sh is banned; use pinned, verified installers"
}

17.8 Dependency-Track policy example

17.9 Release playbook summary

1. Feature branch -> PR -> required review -> merge to main
2. Tag v* -> triggers release workflow (OIDC, read-only by default)
3. Workflow: build -> SBOM -> scan -> sign -> attest (SLSA + SBOM)
4. Publish artifact + signature bundle to registry
5. Admission controller verifies at deploy time
6. Canary rollout 5% -> 25% -> 100% with automated rollback
7. Post-deploy: runtime telemetry + SBOM archived alongside release

17.10 Emergency triage on a suspected compromised dependency

1. Identify affected package + version(s) from advisory
2. Query SBOM store: "which services ship this?"
3. For each hit:
   - Pin to last-known-good version and force-rebuild
   - Invalidate all secrets accessible from the build and runtime context
   - Rebuild and redeploy affected workloads from clean state
   - Review CI runner logs + egress traffic during vulnerable window
4. Block malicious version at repository firewall
5. Add advisory to internal KEV-equivalent list
6. Notify downstream consumers if you publish packages
7. Post-incident: determine which SLSA level / SBOM coverage / admission rule would have prevented it; file follow-up action items

Appendix A — Frameworks & Standards Quick Map

Appendix B — Key CWEs

Appendix C — Sources (54 articles)

1. 12 Months That Changed Supply Chain Security (Silobreaker)
2. 16 Minutes to Impact: npm Supply Chain Abuse Deploys crypto-draining malware (Sygnia)
3. 2025 Minimum Elements for a Software Bill of Materials (SBOM) (CISA)
4. 2026 Supply Chain Security Report — Lessons from a Year of Devastating Attacks (Bastion)
5. A03 Software Supply Chain Failures (OWASP)
6. Achieving SLSA 3 Compliance with GitHub Actions and Sigstore for Go modules (GitHub Blog)
7. Axios Compromise on npm Introduces Hidden Malicious Package (Sonatype)
8. Axios npm Package Compromised in Supply Chain Attack (InfoQ)
9. Breakdown: Widespread npm Supply Chain Attack Puts Billions of Weekly Downloads at Risk (Palo Alto)
10. Compromised dYdX npm and PyPI Packages Deliver Wallet Stealers and RAT Malware (The Hacker News)
11. Compromised ultralytics PyPI package delivers crypto coinminer (ReversingLabs)
12. cosign Verification of npm Provenance, GitHub Artifact Attestations, and Homebrew Provenance (Sigstore Blog)
13. CVE-2024-3094 XZ Backdoor: All you need to know (JFrog)
14. Five Key Flaws Exploited in 2025’s Major Software Supply Chain Incidents (Infosecurity Magazine)
15. GitHub Actions Supply Chain Attack: A Targeted Attack on Coinbase Expanded to the Widespread tj-actions/changed-files Incident (Unit 42)
16. GitHub Action tj-actions/changed-files supply chain attack: everything you need to know (Wiz)
17. GitLab discovers widespread npm supply chain attack (GitLab)
18. Hackers Supply Chain Attack Moves From npm to PyPI as Trivy Breach Extends into LiteLLM (Semgrep)
19. How to Prevent OWASP Software Supply Chain Failures (CrossClassify)
20. LiteLLM PyPI Packages Compromised in Expanding TeamPCP Supply Chain Attacks (Help Net Security)
21. Malicious PyPI and npm Packages Discovered Exploiting Dependencies in Supply Chain Attacks (The Hacker News)
22. N. Korean Hackers Spread 1,700 Malicious Packages Across npm, PyPI, Go, Rust (The Hacker News)
23. North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package in Supply Chain Attack (Google Threat Intelligence / GTIG)
24. NPM Supply Chain Attacks Explained — Dependency Confusion, Exploits, and Defense (jsmon)
25. OWASP Top 10 2025 A03 — Software Supply Chain Failures (Authgear)
26. Predictions for Open Source Security in 2025 — AI, State Actors, and Supply Chains (OpenSSF)
27. Protecting Your Software Supply Chain — Typosquatting and Dependency Confusion (GitGuardian)
28. PyPI, npm, and the New Frontline of Software Supply Chain Attacks (RapidFort)
29. s1ngularity: supply chain attack leaks secrets on GitHub: everything you need to know (Wiz)
30. Securing CI/CD Pipelines After the tj-actions and reviewdog Supply Chain Attacks (OpenSSF)
31. Securing Software Supply Chains — Critical Infrastructure Priorities for 2026 (Leadership Connect)
32. Shai-Hulud 2.0: Guidance for detecting, investigating, and defending against the supply chain attack (Microsoft Security Blog)
33. Shai-Hulud 2.0 Supply Chain Attack: 25K+ Repos Exposing Secrets (Wiz)
34. Shai-hulud npm attack: What you need to know (ReversingLabs)
35. Shai-Hulud: Self-Replicating Worm Compromises 500+ NPM Packages (StepSecurity)
36. “Shai-Hulud” Worm Compromises npm Ecosystem in Supply Chain Attack (Unit 42)
37. SLSA Framework — The Definitive Guide for Securing Your Software Supply Chain (Practical DevSecOps)
38. Software Supply Chain Attacks 2025–2026 — Axios, Shai-Hulud, Chalk, TeamPCP (Cyber Army)
39. Software Supply Chain Risks — 2026 Software Supply Chain Report (Sonatype)
40. Supply-chain attack analysis: Ultralytics (PyPI Blog)
41. Supply-Chain Attack Defense — Developer Host Machine Hardening (gist)
42. Supply-chain Levels for Software Artifacts (slsa.dev)
43. Supply Chain Attack — How Attackers Weaponize Software Supply Chains (Netlas)
44. Supply Chain Attacks Are Exploiting Our Assumptions (Trail of Bits)
45. Supply Chain Attacks in Q4 2025 — From Isolated Incidents to Systemic Failure Modes (Sygnia)
46. Supply Chain Compromise of Third-Party tj-actions/changed-files (CVE-2025-30066) and reviewdog/action-setup@v1 (CVE-2025-30154) (CISA)
47. Supply Chain Security in CI — SBOMs, SLSA, and Sigstore (nathanberg.io)
48. The 2026 Guide to Software Supply Chain Security (Cloudsmith)
49. The Next Wave of Supply Chain Attacks — NPM, PyPI, Docker Hub Set the Stage for 2026 (LinuxSecurity)
50. The Nx “s1ngularity” Attack: Inside the Credential Leak (GitGuardian)
51. The Shai-Hulud 2.0 npm worm: analysis, and what you need to know (Datadog Security Labs)
52. The XZ Utils backdoor (CVE-2024-3094): Everything you need to know, and more (Datadog Security Labs)
53. Widespread npm Supply Chain Attack: Breaking Down Impact & Scope Across Debug, Chalk, and Beyond (Wiz)
54. xz Backdoor CVE-2024-3094 (OpenSSF)

This document synthesizes publicly reported research and advisories for defensive reference. It contains no reproduction steps, no working malicious code, and no attacker tooling. All code snippets are defensive configurations.