Vital Signs of Software Dependencies: Understanding Package Health
Table of Contents
As the vast majority of modern applications rely heavily on open-source software, dealing with updates for dependencies can become a major hassle for both developers and cybersecurity professionals. Every developer knows the pain of an update breaking their application. Manually determining which dependencies to run can become a massive time-suck, which is why many developers fall behind on updates, leaving applications open to vulnerabilities.
The endless nature of updates
While keeping dependencies up to date is important, immediately moving to a new version can introduce risks, including the potential for application instability or breakage due to unforeseen regressions in dependent software. Finding a balance between quality and security can seem like a Sisyphean task, as an ever-growing number of updates are required, especially if you must spend time searching for crucial information about each dependency update.
What is package health?
Package health refers to the overall security and reliability of a particular version of a software package (or library), including:
- Whether it has any known vulnerabilities (and how severe they are)
- How old it is
- Adoption rate (how many people have adopted the particular version out of all available versions)
- Test passing rate (success of moving from your current version to the new version)
- How active the maintainer is
Let’s break each of those down a little further.
Known vulnerabilities
Nearly all packages have some known vulnerabilities, but some are higher risk than others. If there are known exploits available, that vulnerability immediately becomes higher risk than vulnerabilities with only theoretical risks. Developers should know what new risks they’re subjecting applications to when updating dependencies.
It’s useful to know how many CVEs a particular version of a dependency has as well as how severe they are. If an update removes a few medium and low CVEs but introduces a new critical CVE, it may not be worth it.
Package age
The age of a package is critical for knowing how trustworthy it is. If a package is more than a year old, it likely contains some vulnerabilities that have been addressed in newer versions. While the newest package is not necessarily the best, if a package version is too old, it is probably riskier to use.
Adoption rate
By monitoring the number of users who are actively using a specific version of a package, developers can assess the overall popularity and reach of that version. If the latest version has a low adoption rate, it might indicate that other developers have tried it and rolled it back after it caused issues.
Version success
This might be the most critical metric related to a package’s health. Knowing the percentage of users who have successfully updated from your current version to a specific later version empowers you to make informed decisions about the ease or difficulty of updating without breaking your build. For example, if a version boasts a 90% success rate among adopters, you can be confident that your update will likely go smoothly as well.
Package maintenance
Developers rely on the responsiveness of library maintainers to address vulnerabilities and ensure the ongoing security of their projects. An active, well-maintained package provides peace of mind, while an abandoned or deprecated one raises a red flag, signaling potential risks and the need for alternative solutions.
More information means better decision-making
Comprehensive package health information allows you to make informed decisions, reducing the risk for negative side effects in your applications—namely, creating new vulnerability risks or breaking an application’s usability. The more you know about a package, the better decisions you can make about it.
Just like a doctor needs a complete patient history to prescribe the right medication, developers need comprehensive information about a software package before updating it. Think of it this way: a new drug might promise to cure a disease, but what about the side effects? If a patient is already vulnerable, is it worth the risk when older, proven medications exist?
The same applies to software. While a later version might seem best, it could introduce bugs or break compatibility with existing code, disrupting users. It’s a delicate balance between innovation and stability—just like a doctor weighing the best treatment options for their patient.
Comprehensive package health information helps you make informed decisions, minimizing the risk of unintended consequences. Ultimately, the more you know about a package, the better equipped you are to make the right call.
Mend.io makes updates easier
Balancing security with application stability is crucial. Mend.io offers valuable package health data, sourced from its widely-used dependency update tool Mend Renovate. This data helps developers make informed decisions about updating packages and mitigating vulnerabilities, enabling them to strike the balance between security and stability.
To update or not to update? That is the question—and one we can help you answer.
