Dependency Health—assessing package risk with Snyk

Snyk’s goal is to help you use open source in a secure way. Vulnerabilities are one indicator that a dependency is unhealthy, but there are other risk factors at play as well.

For that reason, we have a whole team working on making Snyk the go-to destination for information about your dependencies – from Security to License information, and now to Health.

This month, we’ve been rolling out the first phase of our Dependency Health initiative to help developers identify whether there might be a risk associated with any of the dependencies included in their code.

Health risk categories

The new risk information includes:

• An indicator for packages that are deprecated

• Date the package was first released (maturity)

• Date the package was last updated (activity)

• For reports only, the delta between your current package version and the most recent package version (outdatedness)

Here’s that new information in more detail:

Problematic status—is this package deprecated?

For npm, a dependency is marked as “deprecated” if the maintainer is no longer updating it. We now mark these packages from snyk.io with a warning icon in the Dependencies tab of your reports. We’ve also added a filter so that you can get a list of just the ones that are deprecated.

"In addition, we’ve added a warning to the relevant package page if the latest version of the package is deprecated:

Some examples of packages where you can see this warning include cryptiles, node-uuid and hoek.

Maturity — when was this package first released?

When we asked our community what would be a red flag for them when installing a new package, the thing many of them listed first was maturity: they wanted to know if a package has been around for a while. If it was first published last week, they probably wouldn’t want to install it. If it had been first published over a year ago, that would indicate to them that it’s more mature.On the other hand, some packages could be mistakenly considered “mature” because they’ve been around a long time, but they’ve only had one version published. So, we’re exposing the latest semantic version (semver) as well. If it’s below a range such as 0.1.0, this might indicate it’s a bit pre-baked so you may wish to hold off using it.So, we now show this data in the report:

And we display that data in the Package page too:

Activity — is the package still being maintained?

The Last Publish data also informs us about how active the package is. Many packages are effectively archived, but the maintainer hasn’t explicitly marked them as such. A package that hasn’t been updated in, say, over 12 months, probably isn’t going to be updated again. It may be a single-purpose library and considered complete, but if its dependencies are not being updated, it poses a higher risk.

Outdatedness — are there updates available?

For those who like to always be on the latest version, we now show a comparison of what dependency you have installed in your projects, and what the latest version available is for that same package (excluding alpha/pre-releases).

Since this data relates directly to your projects, it’s only visible in Snyk’s reporting area.

Continuing to assess quality with Snyk

In the same way that a 4.5-star wouldn’t be a great indicator of a quality product if it came from just a single review, dependency health data should be considered in a much broader context. That’s why we’re building up our database with different indicators of quality, to help our customers review and make more informed decisions on their risk. Our recommendation is to view each package in its broader context – there may be good reasons why it scores poorly on one metric.

So much more to come…

Over the coming months, we’ll be expanding the depth and breadth of dependency health, by adding more data points to the categories we have now, by including new categories such as Popularity, and by offering policies to automate assessment.

Getting started

Details are included in the Dependencies tab of Snyk’s reports area (if you have a Snyk plan with reports), as well as on our Package pages, which are available to the entire open source community.

Currently, details are provided for npm packages only. For reports, this data updates every time a new snapshot is taken by Snyk of the project in which the dependency was found (the default is every 24 hours).

If you’re on one of our plans that includes access to our API, you can use our Dependencies API to start scripting your own reports. You can also export a CSV of all your dependencies to help your team triage problematic dependencies.

Do try it out, and let us know what other data you’d like us to show.