As of August 30, 2026, the most useful question in supply chain security is not whether your team scans dependencies. It is whether you can prove every shipped artifact came from the pipeline you intended. The last two months made that harder to ignore. On June 25, 2026, npm added a 72-hour read-only safeguard for high-impact accounts after account takeover attacks began to look like a publish button. On July 28, 2026, GitHub Actions started holding certain workflow runs for approval because compromised GitHub credentials were being used to push malicious workflows that steal CI/CD secrets. On August 6, 2026, GitHub expanded malware advisories beyond npm to eight ecosystems. And on August 28, 2026, OpenSSF launched BOMHort to help teams govern SBOMs instead of just generating them.

The pattern is simple, and it is uncomfortable: attackers do not need to break your product if they can borrow the trust you already give to package names, maintainer tokens, and build jobs. A typo-squat, a dependency-confusion package, a compromised maintainer account, or a poisoned workflow can all land in the same place operationally: inside your release path. GitHub’s August 6 post on malware advisories notes that OpenSSF’s malicious-packages data now includes typosquats, dependency-confusion packages, account takeovers, and malicious prebuilt binaries. That is the real lesson. The attack surface is not just code. It is the path code takes to become software your business depends on.

The problem is trust without proof

For founders and operators, the failure mode is usually not dramatic at first. A maintainer gets phished. A token gets reused. A release workflow runs with more privilege than it should. A public package gets updated with a malicious dependency. Nothing looks broken in the product repo, yet the next install or the next deployment carries attacker-controlled behavior. That is why recent GitHub and npm changes matter operationally. They are not just security features. They are attempts to move the trust decision closer to the point where software is published and built.

GitHub’s July 28 control for suspicious Actions workflows is especially telling. The platform is responding to attacks that use compromised GitHub credentials to push malicious workflows and steal CI/CD credentials. In other words, the pipeline itself has become a credential relay. If your release process still assumes that every workflow run is benign by default, your risk model is already behind the current threat pattern.

For smaller teams, the practical implication is not that every package is hostile. It is that every package and every workflow should be treated as untrusted until it can answer two questions: who built this, and what exactly was built. That is the line between inventory and assurance.

What SBOMs can do, and what they cannot

OpenSSF’s August 28 BOMHort announcement is a good reminder that SBOMs are no longer optional paperwork for many organizations. They are becoming part of audit readiness, regulatory readiness, and internal risk management. But SBOMs alone do not tell you whether the thing you shipped was assembled by the right process. They tell you what is there. They do not prove how it got there.

This is where provenance matters. SLSA defines provenance as verifiable information about software artifacts describing where, when, and how something was produced. That matters because a consumer can only trust a release artifact if the build path that produced it is itself trustworthy. npm’s provenance docs make the same point in practical terms: provenance lets you publicly establish where a package was built and who published it, and npm signs provenance attestations with Sigstore public good servers and logs them in a public transparency ledger. npm also warns that provenance does not guarantee a package has no malicious code. That is the right mental model. Provenance is a trust signal, not a magic shield.

Used well, SBOM and provenance work together. The SBOM says what was shipped. The provenance says how it was produced. The signature and transparency log say whether that story can be verified later. Without all three, incident response becomes guesswork. With them, you can answer questions that matter during a real event: which release was built from which commit, which builder made it, which dependencies were involved, and whether the artifact you deployed is the artifact you reviewed.

A practical hardening package for SMBs

You do not need a giant platform program to get meaningful value. The highest leverage move is to tighten the release path around a few controls that are boring in the best possible way:

  • Use trusted publishing for public npm packages so you are not relying on long-lived tokens that can be exfiltrated from CI logs or laptops.
  • Turn on provenance generation and make it visible to the people who approve releases. If a package cannot show where and how it was built, treat that as a risk decision, not a convenience issue.
  • Require artifact signing for release outputs and verify signatures before deployment. If your release artifact is a container image, a bundle, or a binary, make signature verification a gate, not a dashboard.
  • Pin critical build dependencies by digest instead of loose version ranges. This is especially important in release workflows, where a compromised dependency can turn a routine build into a silent compromise.
  • Separate untrusted pull request workflows from release workflows. The July 28 GitHub Actions approval control exists because attackers abuse workflow execution as a privilege escalation path.
  • Attach SBOMs to immutable release digests and keep them queryable. If you cannot answer which shipped release included a vulnerable or suspicious component, your SBOM is only a file, not an operational control.
  • Review vendors and open source packages for provenance gaps. If a package has no provenance, a deleted source repository, or a publishing path no one can explain, that should elevate the review level before adoption.

For a small or midsize company, that list is enough to start changing outcomes. It reduces the chance that a registry compromise turns into a production compromise. It also shortens the time between suspicion and evidence when something does go wrong. That matters because the real cost of supply chain attacks is not only incident cleanup. It is the time your team spends freezing releases, revalidating artifacts, answering customer questions, and rebuilding confidence in the pipeline.

There is a more strategic benefit too. Once provenance is part of the release contract, security stops being an after-the-fact audit and becomes a property of the build itself. That gives founders a better answer when customers, auditors, or partners ask how software is made and how much of that path is actually trusted.

The next step is not to buy another scanner and hope for the best. It is to define the trust boundary around your build and publish process, then make software prove it crossed that boundary correctly. If you want help mapping that path, GGEZ works on the exact pieces that matter here: software supply chain risk assessment, dependency and CI/CD hardening, SBOM and provenance workflow design, and vendor and open source risk review.

In 2026, the best supply chain defense is not optimism. It is evidence.

Why this matters

Provenance-backed dependency and CI/CD hardening: help teams design a release path that uses trusted publishing, artifact signing, SBOM governance, and verification gates before software reaches production.

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.