A trusted update can carry an attack because a signature proves who sent the update, not that the contents are safe. If attackers get into the sender's build process or accounts, their bad code arrives with a real signature. Trust tells you the source. It does not check the cargo.
TL;DR
- A digital signature is like a wax seal. It shows the letter came from the sender and was not changed on the way.
- It does not show the sender wrote a good letter, or that nobody sat at the sender's desk first.
- Better proof comes from build records, called provenance, plus your own checks and monitoring.
Definition: A digital signature is a mathematical stamp that proves a file came from a particular signer and has not been altered since it was signed. Provenance is a record of where and how a piece of software was built.
Why do we trust updates in the first place?
Updates fix bugs and close security holes. Common security advice has long been "install updates quickly." That advice is mostly right. But it means that the update channel is one of the most trusted paths into a computer, and attackers know it.
Your computer asks one question when it sees an update: is this really from the company? If the signature checks out, the update goes in. That is a good check for stopping outsiders from pretending to be the company. It cannot stop a problem that starts inside the company's own pipeline.
What happened in real cases?
CISA's advisory on the SolarWinds related compromise says that one of the initial access vectors was a supply chain compromise of a library file in certain SolarWinds Orion products. In other words, the harmful code traveled inside a product that customers had installed and trusted. CISA noted that the actor had shown patience and operational security and that removing it from compromised environments would be highly complex.
For XZ Utils, CISA reported that malicious code had been embedded in versions 5.6.0 and 5.6.1 of a widely used compression library, tracked as CVE-2024-3094. CISA recommended downgrading to an uncompromised version, such as 5.4.6. Here, the trusted thing was a long standing open source project.
The lesson is not that updates are bad. It is that the sender's identity and the update's safety are two separate questions.
What does a signature prove, and what does it not?
| Check | What it tells you | What it cannot tell you |
|---|---|---|
| Digital signature | The file came from this signer and has not changed since signing | That the signer's build was clean |
| Checksum (a short fingerprint of a file) | The file you got matches the file that was published | That the published file is good |
| Provenance record | Where, when and how the software was built | That the source code itself is harmless |
| Version age | How long a release has been public | That an old release is safe forever |
| Maintainer reputation | Track record of the people involved | That their account was not taken over |
Notice the pattern. Each check answers one question well and leaves another unanswered. That is why layers matter.
The npm documentation describes one such layer. Provenance statements let you publicly establish where a package was built and who published it. The registry signs them using Sigstore, a set of tools for signing software, and records them in a public transparency ledger. The SLSA project describes the broader idea: tamper resistant evidence for each step from source to build to distribution, so that you can trust the ingredient list matches what is in the package. Its own page says that its guidelines help increase trust that the analysis done on source code still applies to the program you receive.
Even so, provenance shows how something was built, not that the build was wise. We cover that gap in a package with valid provenance is not automatically safe and in what SLSA levels mean.
What can you do about it?
You cannot inspect every update line by line. You can do these things:
- Slow down the newest releases. Wait a short time before taking a brand new version unless it fixes a serious problem. Read about this in dependency cooldown periods.
- Watch what changes. When an update arrives, look at what is different in its list of dependencies and scripts. A small bug fix that suddenly adds a new network call deserves a question.
- Keep a rollback ready. Know how to return to the last version you trusted, as CISA's XZ advice suggests.
- Limit what updates can reach. If a build machine does not hold production passwords, a bad update there can do less harm.
- Monitor after install. Many attacks show up as odd behavior later, not at install time.
What does this look like with real numbers?
These numbers are invented to explain the idea. They are not from a real company.
A team uses 200 third party packages. Over a quarter, those packages publish 1,000 new versions between them. The team cannot read 1,000 releases.
Instead they set three rules. First, a new version must be at least 3 days old before it goes in, unless it is flagged as a security fix. Second, any release that adds a new dependency or a new install script is held for a person to look at. Third, builds run with a token that can read the code but cannot reach production.
Suppose 40 of the 1,000 releases trip rule two. A person reviews 40 releases in a quarter, around 10 a month. That is a workload a small team can carry, and it points human attention at the changes most likely to matter.
How can Safeguard help?
Safeguard is a software supply chain security platform. SBOM and dependency scanning keeps an up to date list of what you use, so you can check it again whenever new information appears about a package. Zero-day discovery helps surface new problems early, and policies and gates let you hold changes, such as a new dependency, for review. Reachability analysis helps you judge what a flawed package can actually do in your code.
Run the free scan at gold.safeguard.sh/scan to see what your project pulls in today.
Try it yourself
In the demo, watch how an item that passed a scan earlier can be rechecked later as new information arrives. Click through and look for the point where the status changes.
Click through it at your own pace, or open it full screen.
Quick check
Should I stop installing updates?
No. Most updates fix real problems, and staying far behind is risky too. The goal is to install updates with a little care: a short wait, a quick look at what changed, and a way to go back.
Does a signed update mean it was checked for malware?
No. A signature shows who signed it and that it was not changed after signing. It says nothing about whether the build that produced it was clean.
What is the difference between a signature and provenance?
A signature proves origin and integrity of a file. Provenance is a record of how it was built, such as where and by whom. Provenance gives more context, but neither one proves the code is harmless.
Sources
- CISA advisory AA20-352A
- CISA alert on XZ Utils, CVE-2024-3094
- npm Docs: Generating provenance statements
- SLSA: About SLSA
Last reviewed: 19 October 2026.
