Prologue — The Supply Chain Is the New Attack Surface

The center of gravity of software security has moved. A decade ago, "block bugs in my code" was the whole job. The 2026 answer is different. You also have to vouch for the 5,000 packages you import, the build environment those packages came out of, the container images of that build environment, and the base OS of those container images.

A short sequence of incidents drove the shift.

- **SolarWinds Orion (2020)** — Sunburst backdoor. 18,000 US federal agencies and Fortune 500 firms compromised. Build-system breach.

- **Codecov bash uploader (2021)** — The bash script used in CI was tampered with; tokens stored in environment variables leaked.

- **Log4Shell (December 2021)** — Log4j 2.x JNDI vulnerability CVE-2021-44228. Affected nearly every Java service.

- **3CX desktop app (March 2023)** — Mandiant attribution. North Korea linked. A build pipeline takeover.

- **XZ Utils backdoor (March 2024)** — Jia Tan (a pseudonym) earned maintainer trust over two years and inserted a backdoor. Andres Freund (Microsoft PostgreSQL engineer) found it by accident. CVE-2024-3094.

- **npm typosquats** — Weekly reports from 2023 to 2025. lodash to lodahs, requests to requets, and so on.

The conclusion these events forced is simple. **You must be able to prove after the fact what happened at build time.** And **you must understand what every dependency you import is doing.**

This piece is the 2026 answer to those two propositions. Sigstore signs without long-lived keys, SLSA defines build integrity levels, and SBOMs record "what is inside this binary" in a standard format. Sixty plus tools, standards, and incidents in one flow.

1 · Why Supply Chain Security Matters

Five axes of supply chain threat in 2026.

- **Dependency tree explosion** — An ordinary npm project pulls in 1,500 to 3,000 packages direct and transitive. Each carries its own maintainer trust model.

- **Build environment opacity** — There is no guarantee that the code in a git repo matches the tarball uploaded to npm. event-stream (2018), ua-parser-js (2021), and node-ipc (2022) all share that pattern.

- **CVE accumulation in base images** — alpine, ubuntu, debian images on Docker Hub accumulate CVEs as they age. If the last rebuild was six months ago, 30 to 60 unpatched security fixes is typical.

- **CI/CD secret leakage** — Tokens stored in GitHub Actions, GitLab CI, CircleCI, Buildkite leak through workflow logs, caches, and artifacts.

- **Regulatory pressure** — US EO 14028, the CISA Attestation Form, the EU CRA, Korea ISMS-P, and Japan IPA guidelines now demand SBOMs and attestations.

Each axis spawned its own tools and standards. The structure of this piece follows those five axes.

[Supply Chain Security — 2026 Model, 6 Stages]

1. Source control — Git, SCM policy, code signing

2. Dependency curation — Socket, Snyk, Phylum, Endor

3. Build integrity — SLSA, in-toto, GitHub OIDC, Tekton Chains

4. SBOM generation — Syft, CycloneDX, SPDX, CSAF

5. Artifact signing — cosign, Sigstore, Notary v2

6. Runtime verification — Kyverno, Sigstore policy-controller, OPA

Each stage has its own tools and its own owners. The piece is organized stage by stage.

2 · The Defining Incident — XZ Utils (CVE-2024-3094)

On 28 March 2024, Microsoft PostgreSQL engineer Andres Freund posted to the oss-security mailing list. That post became the watershed of 2020s supply chain security.

- **Outline** — XZ Utils 5.6.0 and 5.6.1 carried backdoor code. The path went through liblzma into OpenSSH sshd. Anyone holding a specific RSA key gained unauthenticated RCE.

- **Maintainer trust takeover** — Jia Tan (or Jia Cheong Tan), active since 2021, methodically earned patch, review, and release rights over two to three years.

- **Social engineering pressure** — Pseudonymous accounts such as Jigar Kumar pressured the original maintainer Lasse Collin about slow releases. Eventually Jia Tan was added as co-maintainer.

- **Accidental discovery** — Freund noticed a 0.5 second sshd login delay, traced it with perf, and stumbled on the backdoor. **Essentially luck.**

The lessons are blunt.

- **Maintainer trust is not eternal** — A single human cannot be a single point of failure.

- **You must compare binary builds to source** — The XZ backdoor was in the tarball but not the git repo.

- **Reproducible builds matter** — Debian and Tor's reproducible builds would have caught the divergence instantly.

- **Static detection has limits** — Static analysis missed it. Behavioral analysis is required.

After XZ, the OpenSSF Alpha-Omega project expanded support for critical OSS maintainers, and Sigstore, SLSA, and Socket adoption stepped up in earnest.

3 · Sigstore — The Standard for Keyless Signing

**Sigstore** (sigstore.dev) launched in 2021 as a Linux Foundation, Red Hat, and Google joint effort under OpenSSF.

Core components.

- **cosign** — A CLI that signs container images, SBOMs, and binaries.

- **fulcio** — A short-lived certificate authority. Takes an OIDC token and issues an X.509 signing certificate valid for 5 to 10 minutes.

- **rekor** — An immutable transparency log built on a Merkle tree. Every signature ends up in public records.

- **gitsign** — A cosign variant for signing git commits. OIDC instead of SSH keys.

The workflow is "keyless signing."

- **OIDC login** — Authenticate via GitHub Actions, Google, Microsoft, or GitLab OIDC.

- **CSR to fulcio** — fulcio embeds the OIDC claim in the certificate and returns a short-lived signing cert.

- **Sign with cosign** — Sign the artifact with that certificate. The certificate and signature are appended to rekor immediately afterwards.

- **Verify** — Anyone can verify by walking the rekor transparency log and the fulcio certificate chain.

This sidesteps the long-running problems of PGP signing — key management, key revocation, key loss. There is no key to lose. Every signature lands in a public log, so denying having signed something is impossible.

As of May 2026, Kubernetes, parts of npm, and parts of PyPI ship with Sigstore signatures. GitHub Actions Artifact Attestations (May 2024 GA) is also Sigstore under the hood.

4 · SLSA v1.1 — Supply Chain Integrity Levels

**SLSA** (slsa.dev, pronounced "salsa") stands for Supply-chain Levels for Software Artifacts. Google generalized its internal Binary Authorization for Borg (BAB) into open source. Stewarded by OpenSSF.

- **v1.0** — April 2023. Splits Build, Source, and Dependency tracks.

- **v1.1** — Updated in late 2024. Focuses on the Build track; Source and Dependency continue separately.

Build track levels.

- **Build Level 1** — Provenance (who built it, where, how) exists. No tamper resistance yet.

- **Build Level 2** — Provenance is signed, and the build service is hosted. Builder trust is required.

- **Build Level 3** — Builder is isolated from other builds. GitHub Actions Reusable Workflows plus OIDC is the canonical example.

Reaching SLSA Level 3 creates a real defense against SolarWinds and Codecov style attacks — build environment tampering. Unless the build service itself is compromised, an attacker cannot inject arbitrary code into the output.

Real-world adoption.

- **GitHub Actions** — Use the `slsa-framework/slsa-github-generator` action for Level 3 builds.

- **GitLab CI** — Automatic provenance attestation in Premium and up.

- **Google Cloud Build** — Provenance through the Container Analysis API.

- **AWS CodeBuild** — Public Builds supports Build Level 3 since GA in 2024.

5 · in-toto — The General Attestation Framework

**in-toto** (in-toto.io) started as an academic project at NYU and Cornell before landing in CNCF. CNCF Incubating in 2022, Graduated in 2024.

The core idea. **At each stage of the supply chain, issue an attestation of "what I did," and have the next stage verify it.**

- **Layout** — The pipeline definition. "In this order, by these people, doing this work."

- **Step** — Input and output hashes for each stage.

- **Sublayout** — Delegating a portion of a large pipeline to another layout.

SLSA provenance is one kind of in-toto attestation. SLSA borrows the in-toto envelope and focuses it on build integrity.

The generality of in-toto means.

- **SBOMs are attestations** — "This artifact's SBOM is this."

- **Vulnerability scan results are attestations** — "At this time I scanned with Trivy and got this."

- **Test results are attestations** — "At this time these tests passed."

Once every attestation is Sigstore signed and rekor logged, operations can enforce "did this image collect enough attestations" at deploy time with policy engines like Kyverno or OPA.

6 · GUAC — The Graph Database for Attestations

**GUAC** (guac.sh, Graph for Understanding Artifact Composition) is an OpenSSF project from Kusari, Google, and Purdue. Launched in early 2023.

The problem statement. **SBOMs, attestations, and vulnerability data sit in different places. You need one place where you can query them as a graph.**

GUAC combines.

- **SBOMs** — CycloneDX or SPDX produced by Syft and Trivy.

- **Attestations** — SLSA provenance, in-toto.

- **Vulnerabilities** — Pulled from OSV, GHSA, NVD.

- **Container metadata** — Information pulled from registries.

Sample queries.

Q: Which of our running images use Log4j 2.14?

GUAC: registry/payments-api:v3.2.1, registry/inventory:v1.0.5 ...

Q: Among npm packages that this image depends on, which ones

match a Jia Tan style maintainer pattern?

GUAC: (graph traversal across maintainer and release patterns)

As of May 2026 GUAC is Alpha, but OpenSSF is pushing it hard. Kusari offers a hosted SaaS.

7 · OpenSSF Scorecard — A Health Score for OSS Projects

**OpenSSF Scorecard** (github.com/ossf/scorecard) is an automated scoring tool for OSS project security practices. Launched in 2020.

Score categories (16 checks).

- **Code-Review** — Are all changes code reviewed.

- **Branch-Protection** — Main branch protection settings.

- **Token-Permissions** — Are GitHub Actions tokens minimally scoped.

- **Vulnerabilities** — Do dependencies carry known vulnerabilities.

- **Pinned-Dependencies** — Are dependencies pinned by SHA.

- **Maintained** — Activity within the last 90 days.

- **License** — Is a license file present.

Each item gets 0 to 10 points; the average is the project score, with 10 the maximum.

Where it shows up.

- **deps.dev** (Google) — Surfaces Scorecard scores for every OSS package.

- **Securityscorecards.dev** — A score visualization dashboard.

- **GitHub Action** — Add a Scorecard workflow to your own project.

Scorecard increasingly serves as automated criteria for "should I import this package." Commercial tools like Endor Labs and Snyk fold Scorecard signals into dependency risk.

8 · Frizbee and AllStar — Helper Tools from OpenSSF

**Frizbee** (github.com/stacklok/frizbee) is a small Stacklok tool. It pins GitHub Actions and container images by SHA.

Before

- uses: actions/checkout@v4

After (Frizbee applied)

- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

A tag (`v4`) can be moved by the maintainer to point at a new SHA. The tj-actions/changed-files incident (March 2025 GitHub Action tampering) demonstrated the risk. A SHA pin does not move under you.

**AllStar** (github.com/ossf/allstar) is the OpenSSF policy bot. It enforces on GitHub organizations.

- **Branch Protection** — No direct pushes to main, mandatory PR reviews.

- **Binary Artifacts** — No .exe, .dll, .so binaries in the repo.

- **Outside Collaborators** — Restrict outside collaborator permissions.

- **SECURITY.md** — Verify a security policy file exists.

AllStar opens an issue when it finds a violation and, if unfixed for a while, opens a pull request with the remediation. OpenSSF, Sigstore, and CNCF's own GitHub organizations run AllStar.

9 · OSV-Scanner and OSV.dev — Open Source Vulnerabilities

**OSV** (osv.dev, Open Source Vulnerabilities) is a vulnerability database Google launched in early 2021. **The NVD alternative.**

NVD problems.

- **Slow ingestion** — Months can pass between a CVE being issued and NVD entering it.

- **2024 NVD slowdown** — A NIST staffing shortage essentially halted NVD analysis from February 2024. A major shock to US-government OSS security.

- **Version range expressiveness** — CPE matching such as vulnerable_software_list is not precise.

OSV strengths.

- **JSON schema standard** — Anyone can publish a new database in OSV format.

- **Automatic imports** — Pulls in GHSA (GitHub), RustSec, PyPA Advisory, npm Advisory.

- **Per-ecosystem databases** — npm, PyPI, Go, Maven, NuGet each get their own dataset.

- **Precise range matching** — Matches package manager semantics (semver, PEP 440).

**OSV-Scanner** (github.com/google/osv-scanner) is a local scanner that uses OSV data. It reads lockfiles (package-lock.json, Cargo.lock, and so on) and reports vulnerabilities. Free and open source.

After the 2024 NVD slowdown OSV effectively became the first major DB to live without NVD dependence. CISA also ties OSV into the KEV (Known Exploited Vulnerabilities) feed.

10 · SBOM Formats — CycloneDX 1.6 vs SPDX 3.0

Two SBOM standards (Software Bill of Materials) evolve in parallel.

**CycloneDX** (cyclonedx.org).

- **Steward** — OWASP.

- **Version** — 1.6 (April 2024).

- **Formats** — JSON, XML, ProtoBuf.

- **Strengths** — VEX (Vulnerability Exploitability eXchange) integration; ML model, service, and hardware BOM support. Security tools adopted it fastest.

**SPDX** (spdx.dev).

- **Steward** — Linux Foundation.

- **Version** — 3.0 (April 2024).

- **Formats** — JSON-LD, RDF/XML, Tag-Value.

- **Strengths** — International standard ISO/IEC 5962:2021. Rich license metadata. Compliance and legal teams adopted it first.

How to choose.

- **Security focus, use CycloneDX** — Strong VEX integration, lightweight JSON.

- **License or compliance focus, use SPDX** — ISO standard, strong license metadata.

- **Emit both** — Syft and Trivy can emit both. Dual publishing is a safe default.

US EO 14028 and CISA Attestation accept either format. The EU CRA also does not mandate a specific SBOM format.

11 · SWID Tags and CSAF — Supporting SBOM and Vulnerability Standards

**SWID Tags** (ISO/IEC 19770-2) are software identification tags. NIST recommends them for US government systems. An XML file distributed alongside the package install that records who, when, and what was installed.

SWID is sharper than SBOMs for identifying a single package, but not as ubiquitous as CycloneDX or SPDX.

**CSAF** (Common Security Advisory Framework) is an OASIS standard. JSON for vulnerability advisories.

- **2.0** — Released in 2022.

- **VEX integration** — The CSAF VEX profile standardizes "this CVE does not affect our product" statements.

- **Adopters** — Red Hat, SUSE, Cisco, Siemens publish advisories in CSAF.

CSAF pairs with SBOM. SBOM answers "what is inside this," and CSAF answers "what vulnerabilities affect it," both machine readable.

12 · Syft and Grype — Anchore's SBOM Tools

**Syft** (github.com/anchore/syft) is Anchore's multi-format SBOM generator. Free and open source.

- **Inputs** — Container images, filesystem directories, OCI archives.

- **Output formats** — CycloneDX, SPDX, Syft JSON, GitHub Dependency Snapshot, text.

- **Detected packages** — npm, PyPI, Maven, Go modules, Rust crates, RubyGems, Debian and RPM packages, Java JARs, Python wheels.

syft alpine:3.20 -o cyclonedx-json=sbom.cdx.json

syft alpine:3.20 -o spdx-json=sbom.spdx.json

**Grype** (github.com/anchore/grype) is Anchore's vulnerability scanner. It consumes the SBOMs that Syft emits.

- **DB** — NVD plus OSV plus GitHub Advisory plus Anchore curation.

- **Outputs** — table, JSON, SARIF.

- **VEX support** — The `--vex` flag removes false positives.

Anchore Enterprise wraps Syft and Grype into a SaaS or on-prem platform with a policy engine (Anchore Policy).

13 · Trivy and Microsoft SBOM Tool

**Trivy** (github.com/aquasecurity/trivy) is Aqua Security's all-purpose security scanner. Covered in iter79, but central to supply chain security.

- **Container image scanning** — OS packages plus language dependencies plus IaC plus secrets.

- **SBOM generation** — CycloneDX, SPDX outputs.

- **SBOM scanning** — Takes an existing SBOM as input and scans for vulnerabilities.

trivy image --format cyclonedx --output sbom.json alpine:3.20

trivy sbom sbom.json

Trivy is free and open source. Aqua Enterprise (commercial) adds cluster-wide scanning, policy, and CI integration.

**Microsoft SBOM Tool** (github.com/microsoft/sbom-tool) started internal at Microsoft and went open source in 2022. Strong on the Windows and .NET ecosystem. SPDX 2.2 output.

sbom-tool generate -b ./build -bc ./src -nsb https://example.com/sbom

Microsoft mandates SBOM Tool on every internal build. Integrated with Visual Studio and Azure DevOps.

14 · GitHub Dependency Graph, Dependabot, Snyk SBOM

**GitHub Dependency Graph** is GitHub's auto-generated dependency tree. It parses lockfiles from nearly every package manager.

- **Dependabot Alerts** — Automatic alerts when a dependency carries a known vulnerability.

- **Dependabot Security Updates** — Auto-opened PRs that apply patches.

- **Dependency Review** — Shows license and vulnerability deltas when a PR adds a new dependency.

- **SBOM Export** — Settings, then Dependency graph, then Export SBOM (SPDX 2.3).

Adding GitHub Advanced Security (GHAS) layers in CodeQL (SAST), Secret Scanning, and Push Protection.

**Snyk SBOM** (snyk.io) is the SBOM module of the commercial Snyk product. It integrates with Snyk Open Source (dependency scanning), Snyk Code (SAST), and Snyk Container (image scanning). Emits CycloneDX and SPDX.

**Mend** (formerly WhiteSource, mend.io) sits in the same bucket. Strong on license compliance. The SBOM module emits CycloneDX.

15 · Image Signing — cosign, Notary v2, TUF

Several image signing standards coexist.

**cosign / Sigstore** — See chapter 3. Keyless signing. The de facto standard.

**Notary v2** (notaryproject.dev) is a CNCF Incubating project. The successor to Docker Notary v1.

- **OCI Image standard adoption** — Stores signatures as OCI artifacts in the registry.

- **Multiple signing algorithms** — RSA, ECDSA, EdDSA.

- **Azure Key Vault and AWS KMS integration** — Friendly to enterprise KMS.

- **notation CLI** — Similar to cosign, but key based.

Notary v2 and cosign can coexist in the same OCI registry. AWS and Azure favor KMS-based keys and push Notary v2; Google and OpenSSF push cosign.

**Docker Content Trust (DCT)** is the legacy Notary v1 layer. Rarely used in 2026.

**TUF** (theupdateframework.io, The Update Framework) is a CNCF Graduated project. A general framework for update mechanisms. cosign and notation both inherit TUF ideas. PyPI's PEP 458 secure package signing is built on TUF.

16 · Chainguard Images and Wolfi OS — The Distroless Evolution

**Chainguard** (chainguard.dev) was founded in 2021 by Google alumni Dan Lorenc, Kim Lewandowski, and others. The company was built by the Sigstore co-founders.

Flagship product — **Chainguard Images**.

- **Image catalog** — nginx, python, go, node, php, openjdk, postgres, and roughly 350 more.

- **Base** — Their own OS, **Wolfi**.

- **Characteristics** — distroless (no shell), Sigstore signed, SBOM bundled, **CVE zero as a target**.

What sets Wolfi apart.

- **undistro** — A from-scratch OS, unlike existing distros. glibc based (Alpine uses musl).

- **Rolling release** — Latest package versions land instantly.

- **Build tooling** — apko (image builder) and melange (package builder) are both open source.

Pricing (May 2026).

- **Chainguard Free** — Public images free for the community.

- **Chainguard Production** — SLA, long-term support, internal mirror, FIPS certified images. Enterprise pricing.

- **Chainguard Custom** — A bespoke base image build service.

Strategically Chainguard targets Red Hat UBI and Google Distroless. In 2024 and 2025 Chainguard raised a Series D of 140 million USD on a valuation near 3 billion USD.

17 · Google Distroless, Red Hat UBI Minimal, BuildPacks

**Google Distroless** (github.com/GoogleContainerTools/distroless) is the OSS project Google launched in 2017. Minimal images with no shell or package manager.

- **base-nossl** — For simple non-cgo Go binaries.

- **cc** — glibc included, for C, C++, and Go.

- **nodejs / java / python** — Includes the language runtime; no package manager.

Distroless is free and open source. But unlike Chainguard, it does not ship SBOMs, signatures, or CVE monitoring as a service.

**Red Hat UBI Minimal** (catalog.redhat.com) is Red Hat's Universal Base Image. RHEL compatible. Ships microdnf (so not fully distroless). Friendly to enterprise RHEL customers.

**BuildPacks** (buildpacks.io) is CNCF Incubating. Automates container builds without Dockerfiles.

- **Paketo Buildpacks** (VMware) — Java, Node, Python, Go, Ruby, and more.

- **Heroku Buildpacks** — The lineage of Heroku PaaS builds.

- **Google Cloud Buildpacks** — What Cloud Run and App Engine use.

BuildPacks shrink the Dockerfile attack surface, reducing misconfiguration and vulnerabilities. Auto base image updates are a side benefit.

**Apko, Melange** (github.com/chainguard-dev/apko, github.com/chainguard-dev/melange) are Chainguard's build tools. apko builds an image from declarative YAML, melange builds packages. The Wolfi build foundation.

18 · Socket.dev — Behavior Analysis for npm and PyPI

**Socket** (socket.dev) was founded in 2022 by Feross Aboukhadijeh, a Node.js community veteran (Standard JS, WebTorrent).

The problem. **npm and PyPI accept tens of thousands of new packages and versions per day; no human can review them all.**

Socket's approach.

- **AST analysis** — Static analysis of every new package. Suspicious patterns (eval, child_process, fs.readFileSync) get scored.

- **Install script analysis** — Inspects npm preinstall and postinstall scripts plus PyPI setup.py before execution.

- **Network communication detection** — Detects suspicious domains, IPs, and telemetry.

- **Typosquat detection** — Edit distance against popular package names.

- **Maintainer change tracking** — Alerts when new maintainers join.

Socket Bot comments on the pull request with the risk surface. The GitHub Marketplace install is free. Paid plans add SAST, SBOM, and a policy engine.

Pricing (May 2026).

- **Free** — Open source projects and individuals.

- **Team** — 8 USD per user per month.

- **Enterprise** — Quoted.

After XZ Utils, Socket disclosed that its analysis would have flagged Jia Tan's anomalous pattern (large changes immediately after release rights) post-hoc, and accelerated similar detection.

19 · JFrog Xray and Black Duck — Enterprise Dependency Scanning

**JFrog Xray** (jfrog.com/xray) is the security module that bolts on to JFrog Artifactory. A natural add-on for any Artifactory customer.

- **Targets** — Every artifact in JFrog Artifactory repositories.

- **Scans** — CVEs, licenses, operational risk (deprecated packages, and so on).

- **Block policy** — Stops risky packages from being downloaded through Artifactory.

- **SBOM** — CycloneDX and SPDX output.

- **Curation** (added in 2024) — Mirrors only vetted packages into an internal repo.

The JFrog integration is the strength and also the limit. Without Artifactory the reason to choose Xray weakens.

**Black Duck** (blackduck.com) is the SCA business Synopsys spun out in September 2024. Officially Black Duck Software Composition Analysis.

- **History** — Founded in 2002. Essentially defined the SCA category.

- **KnowledgeBase** — A database of 5 million plus open source components and licenses.

- **Strengths** — License compliance, due diligence reports (used in M and A).

- **SBOM** — CycloneDX, SPDX.

Black Duck is strong on license risk, and expensive. Standard at automotive, healthcare, and financial firms with strict requirements. Enterprise pricing.

20 · Snyk Open Source and Snyk Container

**Snyk** (snyk.io) was founded in the UK in 2015. Valued at 8 billion USD at peak (2022); a down round followed in 2023 and 2024.

Product lineup.

- **Snyk Open Source** — Scans npm, PyPI, Maven, NuGet, and other dependencies, plus license info.

- **Snyk Code** — SAST (an in-house engine based on the DeepCode acquisition).

- **Snyk Container** — Container image scanning.

- **Snyk IaC** — Terraform, Kubernetes, CloudFormation scanning.

Pricing (May 2026).

- **Free** — 200 tests per month.

- **Team** — 25 USD per user per month.

- **Enterprise** — Quoted.

Snyk's strengths — developer-friendly UX, IDE plugins (VS Code, JetBrains), GitHub and GitLab integration. Weakness — pricing scales fast.

In 2024 Snyk reinforced its SBOM module and pushed into ASPM (Application Security Posture Management) with AppRisk Pro, competing with Endor Labs, Apiiro, OX Security, and Cycode.

21 · Phylum, Stacklok, Endor Labs — The Next Generation

**Phylum** (phylum.io) was founded in 2020. ML-driven package risk scoring.

- **Analysis model** — More than 280 heuristics across maintainers, code patterns, and library history.

- **Package manager coverage** — npm, PyPI, RubyGems, Maven, NuGet, Cargo, Go.

- **Zero-day blocking** — Analyzes new packages the moment they are published.

**Stacklok** (stacklok.com) was founded in 2023 by Craig McLuckie (Kubernetes co-creator) and Luke Hinds (Sigstore co-creator).

- **Product — Minder** — A supply chain policy engine. Integrates Sigstore, OPA, GUAC.

- **Product — Trusty** — A free package risk score service.

- **Product — Frizbee** — The SHA pinning tool (chapter 8).

Stacklok is essentially the Sigstore co-founders productizing what they built. OSS first.

**Endor Labs** (endorlabs.com) was founded in 2022 by Varun Badhwar (formerly Palo Alto Networks and RedLock).

- **Reachability Analysis** — Tracks precisely whether a vulnerable package is actually called from your code. Sharply reduces CVE noise.

- **Phantom Dependencies** — Detects packages that are imported even though they are absent from package.json.

- **License Risk** — Dual-license and copyleft hazards.

- **SBOM plus VEX** — Auto-generates VEX for "no impact" statements.

Endor Labs raised a 70 million USD Series B in 2023 and a further 160 million USD in 2024. One of the ASPM category leaders.

22 · GitHub Actions OIDC and Artifact Attestations

**GitHub Actions OIDC** is the mechanism by which a GitHub Actions workflow takes an OIDC token and authenticates to AWS, GCP, or Azure with an IAM role. GA in 2022. Eliminates static secrets like AWS_ACCESS_KEY.

permissions:

id-token: write

contents: read

jobs:

deploy:

runs-on: ubuntu-latest

steps:

- uses: aws-actions/configure-aws-credentials@v4

with:

role-to-assume: arn:aws:iam::123:role/github-actions

aws-region: us-east-1

**GitHub Artifact Attestations** (GA May 2024) combines OIDC, Sigstore, and in-toto. Automatically attaches provenance to workflow outputs.

- uses: actions/attest-build-provenance@v1

with:

subject-path: dist/myapp

That one line generates SLSA Build Level 3 grade provenance, signs it with Sigstore, and logs it to rekor. Verification is `gh attestation verify`.

As of May 2026 GitHub Actions is the de facto OSS supply chain security platform. GitLab CI and CircleCI offer similar OIDC, but GitHub leads adoption.

23 · GitLab CI, Buildkite, Tekton Chains

**GitLab CI** is GitLab's built-in CI/CD. Premium and up generate SLSA provenance since 2023.

- **OIDC** — The `id_tokens` keyword authenticates to AWS, GCP, or HashiCorp Vault.

- **Container Scanning** — Trivy integration.

- **Dependency Scanning** — Gemnasium (GitLab's own) plus external DBs.

- **SBOM Export** — CycloneDX output in Ultimate.

**Buildkite** (buildkite.com) is an Australian CI. Hybrid model — SaaS control plane plus self-hosted agents. Signed Pipelines launched in 2024. The pipeline definition itself is signed to block tampering.

**CircleCI** doubled down on OIDC after its own January 2023 security incident (customer secrets leaked). SLSA Level 3 automation followed in 2024.

**Tekton Chains** (tekton.dev/docs/chains) is the security module of CNCF Tekton. Auto-generates attestations for every TaskRun and PipelineRun in a Tekton pipeline. Sigstore signing. Bundled with Red Hat OpenShift Pipelines.

24 · OIDC-Signed Package Managers — PyPI, npm, RubyGems

Package managers introduced OIDC publisher verification. They blunt the impact of maintainer password or API token compromise turning into malicious releases.

**PyPI Trusted Publishers** (docs.pypi.org/trusted-publishers) went GA in April 2023. Directly trusts OIDC tokens from GitHub Actions, GitLab CI, or Google Cloud Build. No PyPI API token needed.

- uses: pypa/gh-action-pypi-publish@release/v1

with:

No api-token! OIDC only

repository-url: https://upload.pypi.org/legacy/

PyPI tightened external screening of security-relevant packages and completed 2FA enforcement in November 2024.

**npm provenance** (docs.npmjs.com/generating-provenance-statements) shipped in April 2023. Flip `npm publish --provenance`. Built on GitHub Actions OIDC. Provenance shows up as a "Provenance" badge on the npm package page.

**RubyGems trusted publishing** rolled out in late 2024. Similar OIDC base.

**Crates.io** (Rust) outlined a new security model in 2024 (RFC 2706 and friends). aud verification and OIDC based.

**Maven Central** strengthened PGP signing in 2024 and stood up a new signing portal. Direct OIDC adoption is in progress for 2026.

25 · Vulnerability Database Comparison — NVD, OSV, GHSA, KEV

**NVD** (nvd.nist.gov) is NIST's National Vulnerability Database. Adds CVSS scores and CPE matching on top of CVE. Since February 2024 analysis has slowed sharply, and NIST has announced contractor alternatives.

**OSV** (osv.dev) — see chapter 9. The de facto OSS standard after the 2024 NVD slowdown.

**GHSA** (GitHub Security Advisories, github.com/advisories) are advisories that GitHub issues. CVE assignment is automated. The data source behind Dependabot.

**KEV** (CISA Known Exploited Vulnerabilities, cisa.gov/known-exploited-vulnerabilities-catalog) is the US CISA catalog. Only CVEs actually used in attacks. US federal systems must patch KEV-listed CVEs on a short clock.

Selection criteria.

- **Breadth** — NVD was the most comprehensive; the 2024 slowdown ceded ground to OSV and GHSA.

- **Speed** — GHSA and OSV are fastest.

- **Real-world risk** — KEV is the most precise. Quality over quantity.

- **Commercial data** — Snyk DB, Rapid7, and Tenable DB layer in their own curation.

26 · Regulatory Landscape — US EO 14028, CISA, EU CRA, NIST SSDF

**Executive Order 14028** (May 2021, Biden) raised the cybersecurity bar for US federal agencies. SBOMs, zero trust, and incident reporting became required.

**NIST SSDF** (Secure Software Development Framework, NIST SP 800-218) is the follow-up. A safe SDLC practice guide. Four groups, 19 practices.

**CISA Secure Software Development Attestation Form** (announced March 2024) is the operationalization of EO 14028. Vendors selling software to US federal agencies must self-attest to NIST SSDF compliance with CEO and executive signatures. False statements carry criminal liability.

**EU Cyber Resilience Act (CRA)** was adopted by the EU Parliament in October 2024. Full enforcement starts December 2027. Cybersecurity obligations for digital products.

- **CE mark** — CE mark required for products that can be hacked (IoT, software).

- **SBOM** — SBOM must ship with every product placed on the market.

- **Vulnerability reporting** — 24-hour reporting to ENISA and the national CSIRT.

- **Fines** — 2.5 percent of revenue or 15 million EUR, whichever is greater.

OSS maintainers were worried early (the OSS exemption is explicit), but the final text limited scope to "every digital product placed on the market commercially," leaving non-commercial OSS exempt.

**PCI DSS 4.0** (mandatory March 2024) is the payment card standard. SBOM, SAST and DAST, and secret management are stricter.

27 · Korea and Japan Supply Chain Security Guidelines

**Korea**.

- **ISMS-P** (Information Security and Privacy Management Certification) — Run by KISA. Supply chain items strengthened in the 2024 revision.

- **FSI SBOM guide** (financial sector regulator, published September 2024) — Recommendation for SBOM adoption in financial institutions. CycloneDX or SPDX.

- **Samsung SDS, LG CNS, NCSOFT** — Internal SBOM systems. Their own dependency curation registries.

- **Naver Whale, Kakao Security Center** — Strengthened external package use policies. After the 2024 KakaoTalk security incident, supply chain reviews escalated.

- **Software Promotion Act** — Revised in 2024 to require SBOMs on public SW projects.

**Japan**.

- **IPA Software Supply Chain Security Guidelines** (Version 1.0, December 2023) — Released by the Information-technology Promotion Agency. Recommends CycloneDX.

- **NISC** (Cabinet Cyber Security Center) — Supply chain security standard for government systems.

- **METI** (Ministry of Economy, Trade and Industry) — Cybersecurity Management Guideline 3.0 adds supply chain items.

- **NTT Communications** (Group-CSIRT) — In-house SBOM and SCA. Internal safe-package registry.

- **GMO Cybersecurity by IERAE** — SBOM and SCA consulting plus a JVN integrated solution.

- **Automotive industry** — UN R155 obligations push Toyota, Honda, and Nissan to require SBOMs all the way down to tier-1 suppliers.

28 · Industry Specifics — Medical, Automotive, Financial

**Medical (US)**. Since October 2023 the FDA mandates cybersecurity in medical devices under Section 524B.

- **SBOM mandate** — Every new device 510(k) submission ships with an SBOM.

- **Vulnerability monitoring** — Lifetime monitoring after release.

- **Software updates** — A security patch distribution plan is required.

GE Healthcare, Medtronic, Philips, and Siemens Healthineers strengthened their own SBOM workflows.

**Automotive**. UN R155 (type approval mandatory for new cars from 2022) and ISO/SAE 21434.

- **CSMS** (Cyber Security Management System) — Mandatory for automotive OEMs and tier-1 suppliers.

- **SBOM and VEX** — Track vehicle software components.

- **OTA updates** — Standard for over-the-air security patches.

Toyota, BMW, GM, Ford, and Tesla are all affected. Korean Hyundai and Kia also fall under R155 for global sales.

**Financial**. PCI DSS 4.0 (March 2024), Korea Electronic Financial Supervisory Regulations, Japan FISC Safety Standards.

- **Payment card environments** — SBOM, SAST, and DAST mandatory.

- **System risk** — Payment outages are systemic risk. Third-party SW risk assessment is mandatory.

Korea's FSI 2024 SBOM guide is part of this current.

29 · Adoption Roadmap — Zero to Twelve Months

Adoption has to be incremental. Throwing every tool at developers at once will paralyze the team. A sample 12-month roadmap.

[Months 0-1] Visibility

- Turn on GitHub Dependency Graph plus Dependabot (free)

- Start Trivy scans of every container image

- Pilot SBOM emission with Syft (CycloneDX output)

[Months 1-3] Automation

- Install Socket Bot from the GitHub Marketplace

- Run a PoC of Snyk or Endor Labs

- Adopt OIDC in CI/CD (GitHub Actions to AWS IAM Role)

[Months 3-6] Build integrity

- Reach SLSA Build Level 2 (auto-emit provenance)

- Adopt GitHub Actions Artifact Attestations

- Sign container images with Sigstore cosign

[Months 6-9] Harden base images

- Switch to Chainguard Images or Google Distroless

- Pin every GitHub Action by SHA with Frizbee

[Months 9-12] Enforce policy

- Block unsigned images at deploy time with Kyverno

or Sigstore policy-controller

- Reach SLSA Build Level 3

- Publish SBOMs and VEX to customers and auditors regularly

Each stage needs measurable output. "We have an SBOM" is not a win. "Average vulnerability patch time fell from 30 days to 7 days" is.

30 · Decision — Which Tools, When

[OSS / personal projects]

-> GitHub Dependabot, Trivy, Sigstore (all free)

-> Watch OpenSSF Scorecard scores

-> Keep dependencies small

[Startup / SMB SaaS]

-> Snyk Free or Socket Free

-> GitHub Actions Artifact Attestations

-> Chainguard Images (community)

-> Auto-generate SBOMs with Syft

[Enterprise — financial, medical, automotive]

-> JFrog Xray (if you run Artifactory)

-> Black Duck (license compliance)

-> Chainguard Production

-> Endor Labs or Snyk Enterprise

-> SLSA Level 3 plus cosign plus Kyverno

[Government / Defense]

-> Fill out the CISA Attestation Form

-> Adopt NIST SSDF wholesale

-> Publish SBOMs and VEX on a regular cadence

-> Patch KEV-listed CVEs on a short clock

The trick is "as much as you need." Endor Labs Enterprise is overkill for a 50-dependency project. Trivy alone is too thin for a 5,000-dependency payments stack.

31 · Self-Assessment Checklist

Eight questions before adopting any supply chain security tool.

1. Do you have lockfiles, and does CI verify them?

- If package-lock.json or poetry.lock is missing, fix that first.

2. Are container images scanned on every build?

- At minimum one of Trivy, Grype, Snyk Container.

3. Are CI tokens static secrets or OIDC?

- Replace static keys like AWS_ACCESS_KEY with OIDC immediately.

4. Who reviews new dependencies?

- Add automated analysis from Socket or Phylum.

5. Can you trace where your base images come from?

- Pick one of Chainguard, Distroless, UBI and standardize.

6. Do build outputs carry provenance?

- SLSA Build Level 2 is the floor.

7. What is the average vulnerability patch time?

- 24-72 hours for KEV, 30-90 days for the rest as SLAs.

8. Do you publish SBOMs to customers and auditors?

- Be ready for CISA Attestation and EU CRA.

Falling short on five or more of these eight items means you are exposed. When the next SolarWinds, Log4Shell, or XZ event hits, recovery takes the company.

Epilogue — Trust Is Built, Not Assumed

This piece maps out 60 plus tools, standards, and incidents. Sigstore, SLSA, SBOMs, Chainguard, Socket, JFrog, Snyk, Endor Labs, Phylum, GUAC, in-toto, OpenSSF Scorecard, CycloneDX, SPDX. Each has its place.

But the core truth of 2026 supply chain security is this. **Trust is not the default. Trust is built.** A maintainer's email address, a GitHub star count, or a download tally is not a basis for trust. Signatures, attestations, reproducible builds, and behavior analysis are.

The XZ Utils lesson is cold. Two years of social engineering cannot be blocked by human intuition alone. Andres Freund's catch was luck, and the next intrusion may never be caught. That is precisely why pushing tools, standards, and automation off the calendar is not an option.

If you read this through, pick one thing today. **Print your project's dependency tree once.** `npm ls --all`, `pip list`, `mvn dependency:tree`, `go mod graph`. If the output shows 1,500 packages or more, that is your real supply chain. The first question is how trust formed in those 1,500.

Good tools, good standards, good maintainers. Sigstore and SLSA are bridges among the three.

Appendix · Quick Command Reference

Generate an SBOM

syft alpine:3.20 -o cyclonedx-json=sbom.cdx.json

trivy image --format spdx-json -o sbom.spdx.json alpine:3.20

Sign an image (cosign with GitHub OIDC)

cosign sign --yes registry.example.com/myapp:v1.0.0

Verify an image

cosign verify --certificate-identity-regexp 'https://github.com/myorg/.*' \

--certificate-oidc-issuer https://token.actions.githubusercontent.com \

registry.example.com/myapp:v1.0.0

Verify an attestation (GitHub CLI)

gh attestation verify oci://registry.example.com/myapp:v1.0.0 \

--repo myorg/myapp

OSV scan

osv-scanner --lockfile=package-lock.json

osv-scanner --docker alpine:3.20

Scorecard score

scorecard --repo=github.com/myorg/myproject

References

- [OpenSSF](https://openssf.org/)

- [Sigstore](https://www.sigstore.dev/)

- [SLSA Framework](https://slsa.dev/)

- [in-toto](https://in-toto.io/)

- [GUAC](https://guac.sh/)

- [OpenSSF Scorecard](https://scorecard.dev/)

- [OSV.dev](https://osv.dev/)

- [CycloneDX](https://cyclonedx.org/)

- [SPDX](https://spdx.dev/)

- [CSAF (OASIS)](https://oasis-open.github.io/csaf-documentation/)

- [Syft (Anchore)](https://github.com/anchore/syft)

- [Grype (Anchore)](https://github.com/anchore/grype)

- [Trivy (Aqua)](https://trivy.dev/)

- [Microsoft SBOM Tool](https://github.com/microsoft/sbom-tool)

- [GitHub Artifact Attestations](https://docs.github.com/en/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds)

- [GitHub Advisory Database](https://github.com/advisories)

- [CISA KEV Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)

- [CISA Secure Software Development Attestation](https://www.cisa.gov/resources-tools/resources/secure-software-development-attestation-form)

- [Executive Order 14028](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/)

- [NIST SSDF (SP 800-218)](https://csrc.nist.gov/publications/detail/sp/800-218/final)

- [EU Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)

- [Chainguard](https://www.chainguard.dev/) · [Wolfi](https://wolfi.dev/)

- [Google Distroless](https://github.com/GoogleContainerTools/distroless)

- [Red Hat UBI](https://catalog.redhat.com/software/base-images)

- [Socket](https://socket.dev/)

- [JFrog Xray](https://jfrog.com/xray/)

- [Black Duck](https://www.blackduck.com/)

- [Snyk](https://snyk.io/)

- [Phylum](https://www.phylum.io/) · [Stacklok](https://stacklok.com/) · [Endor Labs](https://www.endorlabs.com/)

- [PyPI Trusted Publishers](https://docs.pypi.org/trusted-publishers/)

- [npm Provenance](https://docs.npmjs.com/generating-provenance-statements)

- [Andres Freund XZ Backdoor Disclosure (oss-security)](https://www.openwall.com/lists/oss-security/2024/03/29/4)

- [Tekton Chains](https://tekton.dev/docs/chains/)

- [Frizbee (Stacklok)](https://github.com/stacklok/frizbee)

- [AllStar (OpenSSF)](https://github.com/ossf/allstar)

- [IPA Software Supply Chain Security Guidelines (Japan)](https://www.ipa.go.jp/security/reports/oversea/supplychain/index.html)

- [Korea FSI (금융보안원)](https://www.fsec.or.kr/)

- [KISA ISMS-P](https://isms.kisa.or.kr/)