Why does my scanner show nothing after a supply chain headline?

A scanner can show nothing after a headline because it only reports what exists in its advisory data. If no advisory has been written yet, or it has not been mapped to your package and version, the scan stays quiet. Treat silence as "not yet known" and check your exposure by hand.

What a scanner actually compares

A dependency scanner does one job. It lists the packages and versions you use, then looks each one up in an advisory database. No record, no finding.

That makes the scan only as current as the records behind it. GitHub's documentation describes its advisory database as a set of advisories for specific security problems, imported from sources such as the National Vulnerability Database, ecosystem databases and community contributions. Each one has to be written, reviewed and mapped to a package before it can match anything in your repository.

News moves faster than that pipeline. A maintainer post, a researcher thread or a registry notice can land hours before a structured record exists.

Vulnerability records and malware records behave differently

GitHub's docs separate two kinds of advisory. A vulnerability advisory lists the range of affected versions and the earliest fixed version. A malware advisory has no fixed version, because the defining feature is that there are no safe versions: the safe course is to stop using the package.

This matters when you read the news. If the headline describes a malicious release, "no fix available" is expected. You are looking for a version to avoid and a version to roll back to, not a patch to apply. A scan that lists nothing for a malicious release may simply mean no malware record has been created for that package yet.

A manual check that does not wait for the database

When the headline names a package, do the lookup yourself.

1. Write down the exact package name, ecosystem and the versions the source says are bad. Use the primary source, not a repost.
2. Search your lockfiles and manifests for the name. In an npm project, npm ls package-name shows every copy in the tree. In a Python environment, pip show package-name and pip freeze show what is installed.
3. Compare the installed version to the bad list. A name match with a safe version is a no.
4. Check whether any build or CI run installed the package during the bad window, since an old lockfile may not reflect what a build fetched. See the post on building the exposure window.
5. Record the answer and the time you checked.

If you run many repositories, an inventory of every package and version across them turns step 2 into a single search instead of a repository by repository hunt.

Check back, because records change

Advisory records get created, edited and withdrawn after first publication. A scan that was silent in the morning may report a finding by evening. Set a recheck time, and write it in the ticket so the answer does not depend on someone remembering.

GitHub also notes that Dependabot alerts fire when a new vulnerability is added to the advisory database, and when your dependency graph changes. So an alert can appear later even with no change from you. Do not close the news item on the strength of an empty alert list.

Six reasons a scan can stay silent

Silence has more than one cause, and the cause decides what you do next. Work through this table before you decide anything.

Only the last row is good news, and you cannot tell it apart from the first five without looking.

A worked example

Suppose a news item says a popular npm package shipped two bad versions, 3.4.1 and 3.4.2, early on a Tuesday. At 10:00 your dependency scan shows nothing for that package.

You do not stop there. You run these steps.

1. You open the primary source and copy the package name and the two versions into the ticket, along with the time you read it.
2. You search your lockfiles. The package appears in two services. Service A pins 3.4.0. Service B resolves 3.4.2 through a caret range in a transitive dependency.
3. That is a hit. The scanner was silent because no advisory record existed yet, not because Service B was safe.
4. You pause the automated updates for that package, pin Service B to 3.4.0 with an override, and ask the build owner whether any job installed 3.4.2 fresh.
5. At 14:00 you check the advisory database again. A malware record now exists. Your scanner picks it up on its next run and the ticket gains an official finding that matches what you already knew.

The by hand result arrived four hours before the database record. That is the whole point of the manual check.

What to tell colleagues while the scan is quiet

People will ask whether the scanner is clean. A useful answer has three parts: what you checked, what you found, and when you will check again. For example: "Scanner shows nothing, which only means no record exists yet. We checked lockfiles for both bad versions and found one service resolving 3.4.2, now pinned. We recheck the advisory data at 14:00."

Avoid "we are fine" until the by hand check is done and recorded. Avoid "we are vulnerable" until the version match is confirmed. Say what is known.

Make the next time faster

Teams that handle this calmly usually prepared two things in advance. First, a way to search every package and version across all repositories in one query, so step 2 takes minutes. Second, a short written routine so that nobody improvises under pressure. If you do not have either, the news item you are reading now is a good prompt to start one.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how a project is watched over time, since a dependency can change status after you last checked.

Safeguard's SBOM and dependency scanning, plus continuous monitoring, are built around the same idea: your inventory is checked again when new advisory data arrives. You can try a free scan at gold.safeguard.sh/scan.

Quick check

Sources

• About the GitHub Advisory Database
• About Dependabot alerts

Last reviewed: 19 October 2026.