You can learn a lot about a package named in the news without installing it. Registry commands show version history and publish times, the PyPI API shows file digests, the GitHub Advisory Database shows records, and the npm API shows download counts. Each one is read-only, so you can run them safely before you decide anything.
Why read-only first
When a package is in the news, the temptation is to install it and poke around. That is the one thing you should not do on a machine you care about. If the package is harmful, installing it is how it runs.
Read-only lookups ask questions of public records. They do not execute the package. They answer most first-hour questions: which versions exist, when were they published, are there advisories, how popular is it, and is the file I have the file the registry published?
The cheat sheet
| Question | Tool | Command or route |
|---|---|---|
| Which versions exist? | npm registry | npm view some-package versions |
| When was each version published? | npm registry | npm view some-package time --json |
| What does one version declare? | npm registry | npm view some-package@1.2.3 dependencies |
| What does a Python project list? | PyPI JSON API | https://pypi.org/pypi/some-project/json |
| What are the file digests? | PyPI JSON API | digests block in each release file entry |
| When was a Python file uploaded? | PyPI JSON API | upload time fields in the file entry |
| Is there a malware or vulnerability record? | GitHub Advisory Database | search with ecosystem: and affects: or type:malware |
| Did a record change recently? | GitHub Advisory Database | sort:updated-desc |
| How many downloads? | npm API | https://api.npmjs.org/downloads/point/last-week/some-package |
| Downloads per version, last 7 days | npm API | https://api.npmjs.org/versions/some-package/last-week |
The npm documentation shows that npm view accepts a package spec and field names, and that you can read child fields and version ranges. The PyPI documentation describes the JSON route and the digests. The GitHub documentation lists the search qualifiers. The npm registry documentation describes the download routes.
Reading the output carefully
Version lists show what the registry holds now. A removed version may no longer appear, so a missing version does not mean it never existed. Your own records of what you installed matter more.
Publish times are strong evidence for building a window. See the post on the dates in a write-up.
Metadata fields such as author and links are declared by the uploader. The PyPI documentation says metadata comes from values provided at upload time and may not match the files. Use digests and timestamps for evidence instead.
Advisory records may not exist yet for fresh news. A search that returns nothing is not an all clear. Read why a scanner can stay silent.
Download counts describe popularity, not your exposure. See the post on download counts in a headline.
A worked example
A story names an npm package called some-package and says a version published on Monday is malicious. You work through the sheet in about ten minutes, without installing anything.
npm view some-package versionsshows 3.0.0 through 3.0.4. You note 3.0.4 is the newest.npm view some-package time --jsonshows 3.0.4 was published Monday at 11:20 UTC, minutes after 3.0.3 was published Friday.- You search the advisory database with the ecosystem set to npm and the package named. There is a malware record created Monday evening for 3.0.4. You save the page.
- The per version download endpoint shows 3.0.4 had a few thousand downloads in the last week. You save the JSON because the per version data disappears after seven days.
- You check your own lockfiles. Two services pin 3.0.2. A third resolved 3.0.4 on Monday afternoon.
You now know the version, the time, the advisory status and your one exposed service, and you did not install anything. The one step that touched your systems was reading your own lockfiles.
When you need to look inside
Sometimes the metadata is not enough and you need to see the files. Do that in a disposable environment. Fetch without installing, unpack and compare to the previous version. The post on diffing a suspicious release shows how.
Keep the commands handy
Save the cheat sheet in your incident folder with the placeholders ready to fill. A copy in your runbook turns a stressful moment into following a list. Add other ecosystems you use, such as your language's registry and its advisory database, so the sheet matches your stack.
Limits of read-only checks
Read-only lookups tell you what the registries and databases say. They cannot tell you what your own systems did. A lookup might show that version 3.0.4 is malicious, and only your build logs show whether you installed it. Pair every public lookup with a look at your own records, and write down which statements come from which side.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how every component and version gets an entry, which is the inventory you compare the lookup results against.
Safeguard's SBOM and dependency scanning gives you that inventory, and its free scan at gold.safeguard.sh/scan is a quick way to see what a project depends on.
Quick check
Is it safe to run npm view on a malicious package?
The npm documentation describes it as showing registry data about a package. It reads records and does not install the package.
Why save the per version download data?
The npm documentation says per version counts are only available for the previous seven days, so the numbers will not be retrievable later.
What if the advisory database has no record?
That means no record exists in that database yet. Check by hand and set a recheck time.
Sources
- npm view documentation
- PyPI JSON API documentation
- Browsing security advisories in the GitHub Advisory Database
- npm registry: package download counts
Last reviewed: 19 October 2026.
