Call the deps.dev API v3 with a package name and read the versions list. Each version carries a publish time and a deprecated flag. A second call on the version returns advisories, licenses and links, and a project call returns an OpenSSF Scorecard result when one exists. Plain curl is enough.
What the API exposes
The deps.dev documentation describes JSON over HTTP, usable with any HTTP client. These are the fields that matter for risk signals, all documented on the API page:
| Field | Where | Meaning |
|---|---|---|
| versions[].publishedAt | GetPackage | Time the version was published, as reported by the registry, if available |
| versions[].isDefault | GetPackage | The version installed when none is specified |
| versions[].isDeprecated | GetPackage | Version marked as deprecated |
| versions[].deprecatedReason | GetPackage | Reason given |
| advisoryKeys | GetVersion | Advisories known to affect this version directly |
| licenses | GetVersion | Licenses for the version |
| slsaProvenances | GetVersion | Provenance data for npm versions |
| scorecard | GetProject | OpenSSF Scorecard result and date, if available |
| openIssuesCount | GetProject | Open issues reported by the project host |
Step by step
- Pick the system and package. The path form is a GET on the packages endpoint, with the system, such as npm, and the package name.
- Read the versions array. Sort by publishedAt and note gaps. Check which version isDefault.
- Check isDeprecated on the version you run and on the default version. A deprecated default version is a clear prompt to look for a replacement.
- Call GetVersion for the version you use and read advisoryKeys and licenses.
- Follow the project link and read the scorecard object. Note its date, since it is a snapshot.
A request looks like this.
curl -s "https://api.deps.dev/v3/systems/npm/packages/PACKAGE_NAME" | head -c 2000
Replace PACKAGE_NAME with the package. Check the API documentation for the exact path and encoding rules, for example for scoped package names.
Reading the output carefully
Three cautions apply. The publish time is whatever the registry reports, and it may be missing. Coverage differs by ecosystem, so an absent field is not proof of a problem. And a Scorecard result describes the repository on a given date, not the artifact you installed.
Use the numbers to build a one line summary for each dependency: last publish date, whether the default version is deprecated, count of advisories on your version, and Scorecard date. Store it with a date.
Putting it in a routine
A weekly script that fetches these four values for the direct dependencies in your lockfile is small and useful. Compare against last week and flag changes, such as a new deprecation or a long gap ending in a new version. Do not auto-block on a single field. Send changes to a human with the dependency's role in the build.
Try it yourself
Click through it at your own pace, or open it full screen. See how direct and transitive components are listed, which is the list you would feed to a script like this.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, with policies and gates, and a free scan at gold.safeguard.sh/scan, so you do not have to maintain the script for every repository.
Quick check
Does the API need a key?
Check the current terms and usage notes on the documentation page before you build anything that depends on it.
Is a missing publish time a red flag?
No. The documentation says the field is populated if available, so treat it as unknown.
Sources
Last reviewed: 19 October 2026.
