On May 11, 2026, GitHub documented a supply chain attack in which 84 malicious versions across 42 @tanstack/* packages were published in a six-minute window. The uncomfortable detail is that the publishes were authenticated through a legitimate GitHub Actions OIDC trusted-publisher binding. From the outside, the release looked like a normal trusted build path.

That matters because a lot of small and midsize teams still treat provenance as the finish line: if the build is signed, the SBOM exists, and the package name is familiar, the release must be safe. The TanStack incident says otherwise. Attackers chained a pull_request_target misconfiguration, cache poisoning across the fork and base trust boundary, and runtime token extraction from the Actions runner process. The result was credential-stealing malware published under a trusted identity.

Then, on May 20, 2026, GitHub disclosed a separate compromise involving a poisoned VS Code extension on an employee device, with internal repositories exfiltrated and critical secrets rotated. On May 12, 2026, GitHub deprecated its synchronous SBOM endpoint in favor of an asynchronous report flow. Taken together, those updates point to the same operational reality: your supply chain visibility now has to cover developer tools, build systems, and release metadata, not just the final artifact.

The attack was a workflow failure, not just a package failure

What makes this class of incident so disruptive is that it breaks the usual mental model of trust. Teams often assume the risk sits in third-party code itself. In practice, the attack surface is bigger. A bad workflow step can let untrusted inputs influence the build. A mis-scoped token can let a compromised runner publish something that looks legitimate. A poisoned cache can cross the boundary between a fork and the main repository. Once that happens, a signed artifact can still be the wrong artifact.

For operators, the lesson is not abstract. If your release process uses one workflow for tests and another for publish, if secrets are available too early, or if any step can write to the same cache or artifact namespace as the release job, you have a trust boundary problem. That is the sort of issue that does not show up in a feature roadmap, but absolutely shows up in a postmortem.

SBOMs and provenance are useful only when they are wired into the pipeline

GitHub’s SBOM changelog update on May 12 is a good reminder that SBOM generation should be part of the release workflow, not a separate manual export someone remembers to run later. If you generate an SBOM after shipping, it is documentation. If you generate and store it as part of the build and release path, it becomes evidence.

SLSA’s provenance guidance is explicit about what provenance is for: verifiable information that tracks an artifact back through the supply chain to where it came from. Its Build Track Basics page also draws a clear line between levels. At Build L1, provenance exists. At Build L2, provenance is signed by a hosted build platform. At Build L3, the build platform must prevent runs from influencing one another and keep signing material out of user-defined build steps. That is the level of rigor SMBs should aim at, even if they do not adopt the full spec overnight.

GitHub’s own docs make the practical point even more bluntly: artifact attestations are not a guarantee that an artifact is secure. They link the artifact to its source and build instructions, and you still have to verify them against policy. That is the right mental model for founders and operators. Treat attestations and SBOMs as decision inputs, not as proof that nothing can go wrong.

What to change this week

If you run a small team, you do not need a giant supply chain program before you get value. You need a short list of controls that reduce the chance of bad releases and make a bad release easier to detect and roll back.

  • Require dependency review on pull requests so vulnerable dependency changes are visible before merge.
  • Separate test and publish workflows, and keep publish tokens out of any step that handles untrusted code.
  • Use short-lived credentials and pin third-party actions, package manager hooks, and CI templates to reviewed versions.
  • Generate artifact attestations and SBOMs as part of the release pipeline, then verify them before deployment.
  • Review the maintainers, release cadence, and permissions of the packages, actions, and extensions your team depends on.

The key is to stop treating those tasks as separate security chores. They are one system. Dependency review protects what enters the tree. Hardened CI/CD protects how code turns into artifacts. SBOMs and provenance tell you what you shipped. Artifact signing helps consumers verify it. Vendor review helps you decide what to trust in the first place.

That is the practical response to the TanStack attack and the GitHub incidents this week. Not more fear, and not more policy theater. Just a release path that is narrow enough to reason about and instrumented enough to trust.

If your current release flow still depends on a manual SBOM export, a broad publish token, or a build job that can see more than it needs, the next move is a workflow review. For most SMBs, that is the fastest way to reduce real risk without slowing delivery to a crawl.

Why this matters

Build a release pipeline that combines dependency review, hardened CI/CD, artifact attestations, and automated SBOM generation so SMBs can verify what ships before it reaches customers.

Sources

Need help applying this?

If supply chain risk is becoming a board, buyer, or audit concern, GGEZ can help turn it into a practical hardening plan. See the related service area.