When Shai-Hulud first appeared in 2025, the software supply chain lesson seemed straightforward: a compromised maintainer account could turn trusted packages into a distribution mechanism for malicious code.

A year later, the attack family has become more capable. But the more important lesson is about how we think about software trust.

Recent Shai-Hulud variants have targeted not just npm credentials, but also GitHub Actions, cloud identities, Kubernetes and Vault secrets, OIDC tokens, and developer tool configurations. Some malicious packages have even been released through legitimate repositories and workflows with valid provenance metadata.

That matters because it exposes a limitation in any security strategy that ends with signing. 

Signing is essential. But signing alone doesn't tell you whether the software you're signing is safe. 

Authenticity and security answer different questions

A digital signature helps establish who signed an artifact and whether that artifact has changed since it was signed.

Those are critical assurances.

But if an attacker compromises a legitimate maintainer, repository, or release workflow before the software is signed, the resulting signature can still be valid. The artifact may be authentically produced through the expected process while containing malicious code.

Shai-Hulud has made that distinction increasingly difficult to ignore.

The answer isn't to sign less. It's to combine signing with visibility into what you're actually releasing.

That starts with understanding your dependencies.

SBOMs give you the map

Most software contains open-source and third-party components, often several layers deep. When one of those dependencies becomes vulnerable or compromised, the first question is simple:

Where are we using it?

Without a software bill of materials, answering that question can require searching repositories, build systems, release records, and deployment environments individually.

An SBOM gives you a structured inventory of the components associated with a release. That makes it possible to identify which releases contain a particular package or dependency and focus remediation where it's needed. 

The value becomes even clearer when risk changes after release.

The most recent Shai-Hulud activity illustrates the point. In September 2026, a previously known malicious payload resurfaced in newly published npm packages after more than three months of dormancy. It wasn't a new technical variant. Known malicious code had simply reappeared.

The same dynamic happens with vulnerabilities. Software that appeared clean when released may contain a dependency that receives a new CVE weeks or months later.

Your release hasn't changed. Your understanding of its risk has.

Monitoring must continue after software ships

This is why point-in-time security checks aren't enough.

Teams need to know when new information changes the security posture of software already in use. That means continuously connecting vulnerability and dependency information back to specific releases.

With an SBOM and ongoing monitoring, you can answer questions such as:

• Which active releases contain the affected dependency?
• Which versions are exposed?
• How severe is the newly identified vulnerability?
• Which releases should be investigated or updated first?
• Is a fixed dependency version available?

That changes the role of an SBOM from static documentation into something operational.

It also closes an important gap between software signing and software security.

Signing tells you whether the software is authentic and unchanged. SBOMs tell you what the release contains. Monitoring tells you when something inside that release requires attention.

You need all three.

Bringing signing and release risk together with Software Trust Manager

DigiCert Software Trust Manager is designed around that broader view of software trust.

For protection, Software Trust Manager centralizes code signing governance, protects private signing keys in secure hardware, controls who can sign, and supports policy-driven signing across development workflows.

For visibility, its Secure Releases functionality connects GitHub releases with dependency, vulnerability, CVSS, SBOM, and scan-status information. Teams can see which releases may be affected instead of manually correlating findings across repositories and security tools.

For ongoing monitoring and remediation, supported Software Trust Manager packages can monitor release risk as vulnerability information changes. Teams can be notified when releases require attention and see context such as affected dependencies and, where supported, fix-version suggestions. Organizations can also define vulnerability- and SBOM-based conditions within governed signing and release workflows. 

Secure Releases isn't intended to replace vulnerability scanners. Its role is to connect their findings to the software releases your teams actually ship and maintain.

That's the larger lesson from Shai-Hulud.

Software trust doesn't end when code is signed. You have to know what you're shipping—and keep watching it after it ships.