APPSEC
How to ensure your third-party software packages are reputable
August 16, 2023
Third-party packages are a smart way for organizations to leverage open-source solutions and save developers time. However, introducing third-party dependencies comes with risks, especially if there is no consideration for package reputation. Automating the process of vetting third-party packages combined with detecting the latest vulnerabilities helps mitigate the risks of using open-source software.
Third-party packages are a mainstay in most software deployments. Leveraging open-source is a smart business decision, because it takes less time and effort to import an existing package than to write custom software for a common software problem. By incorporating open-source solutions, developers can spend more time solving business-specific software issues. They can also take advantage of the extensive support community and ongoing enhancements behind many of the most popular open-source libraries.
However, this strategy comes with risks. The fact that almost anyone can contribute to open-source code serves as an open invitation to potential security vulnerabilities. Ensuring the reputation and reliability of third-party packages is crucial to minimize security risks and maintain the overall integrity of your codebase.
In this article, we will explore the key factors that contribute to third-party package reputation and discuss best practices for managing and vetting these packages effectively.
There are a number of ways to assess whether a third-party package is a vetted, solid, well-maintained piece of software—or whether it carries too much risk to be worth introducing into your ecosystem.
Similar to restaurant reviews, if a package on GitHub has received a high number of stars, this is a good indication of a high-quality repository. When GitHub users “star” a repo, they are upvoting that code, which makes the number of stars a kind of score. For example, Meta’s React library is an incredibly popular open-source UI application framework, with over 210,000 stars.
Developers can contribute changes or use customized versions of open-source software by cloning or forking open-source repositories.
A high amount of this kind of traffic usually indicates a package enjoys a healthy amount of engagement with maintainers and production use cases. There is a kind of safety in these numbers. It creates a higher possibility that common vulnerability exposures (CVEs) are being regularly published and patched for that package.
Packages with a very large number of dependencies may actually be an indication of higher risk. Each dependency is yet another library that should go through the same reputation screening as the base library being considered. Therefore, the more dependencies a package has, the greater the chance of increased complexity, security risk, and maintenance.
Number of dependants
The number of products and packages that depend on a third party package is one of the strongest signals of reputation possible. This not only tells you how many other companies and developers trust this package in their code, but also gives you an understanding of the size of the community surrounding the package, demonstrating quality assurance and bug/risk reporting speed.
The great thing about open source is its transparency: Knowing who committed what is very easy to find out, and vetting the profiles of those who committed a third-party package will tell you how trusted a package is. Checking for reputable authors includes seeing how many followers they have, looking into whether or not they have active and legitimate social media accounts/websites, and scrolling through their GitHub commit activity.
Software that was written a long time ago and hasn’t been maintained is a strong indication that the software isn’t being cared for or actively used. Just as there is safety in numbers, there is also risk in going with code that has been abandoned.
One challenge with open-source software is understanding whether a package in use has a known vulnerability. It is critical for organizations to detect new vulnerabilities in packages to mitigate the threat quickly. Arnica offers real-time package analysis to detect CVEs in code before it is released to production.
Aside from knowing whether a package is implicated in a CVE, understanding the security posture of packages and how they respond to CVEs is also an important factor in determining package reputation.
These scores and ratings provide additional information for organizations to assess the risks of the open-source software their applications rely on and prioritize fixes:
It is important to note that none of the above checks are security silver bullets. Bad actors who know that these are reputation boosters can subvert these checks in order to get their malicious code downloaded.
For example, a diligence check may show that a package has many stars on GitHub. However, a technique known as “starjacking attacks” can allow a malicious package to use a popular GitHub repository to make it seem it has more stars than it actually has.
Author checks can also be misleading. Arnica reported that in the pl0x GitHub attack, clones of popular repositories containing harmful code were falsely linking to authors that had never actually contributed to the project. You can read more about how author spoofing works here.
Nonetheless, when combined, the above steps do provide layered security. To most adequately assess a package's reputation, each variable should be given appropriate weight in a cumulative score.
The Open Worldwide Application Security Project, or OWASP, identified “Vulnerable and Outdated Components” as a top 10 web application security risk, backed by both community surveys and data analysis. While defending against published vulnerabilities is clear, the dangers surrounding outdated or under maintained packages can be easier to miss. A lack of maintenance, evidence of irregular revisions, or limited signs of active use can mean the package is untested, often with unknown vulnerabilities waiting to be exploited. Incorporating unreputable packages without assessing the risks they introduce exposes organizations to the following concerns.
Installing any package that sounds like it can “get the job done” without vetting its reputation can very quickly introduce vulnerabilities into your software. In 2020, npm security teams found that two open-source packages created by the same author, jdb.js and db-json.js, contained malicious code that installed a remote access Trojan (RAT) when they were run.
While the package was taken down quickly after detection, it was downloaded over 100 times before it was made unavailable.
Threat actors don’t simply rely on developers to naively find and install random packages that seem to solve their problems. They also employ a strategy called “typosquatting,” which exploits the fact that many developers can mistype or misremember the names of popular packages and accidentally download the wrong one.
For example, instead of importing the popular npm package “electron,” a developer can misspell the name as “electorn” and import that instead. It turns out that in 2020, the “electorn” package did exist and indeed contained malicious code, which was downloaded hundreds of times before it was detected and removed.
Remember, third-party package ecosystems consist of large dependency trees, meaning your organization’s dependencies also have dependencies. Third-party packages themselves can have poor security postures and be mismanaged, which in turn might indirectly introduce vulnerabilities or insecure coding practices that could be just as harmful as direct mismanagement.
How can an organization navigate a landscape of third-party packages that continue to reveal vulnerabilities and publish updates to fix them? The answer is package management.
Manually managing a few dependencies, for example, including JavaScript CDN libraries in a few script tags for a web page, may be approachable for a tiny static microsite managed by a single person. However, in a large organization, dozens of developers may be contributing to a complex application. Imagine a case where there are several third-party dependencies that may have common dependencies but require separate versions; this would be a nightmare to manage manually.
Package managers provide developers a lot of control over their dependencies, including versions, custom scripting, dependency analysis, and more. They also simplify and automate many of the otherwise tedious tasks such as package installs, updates, and even facilitating multiple versions of a package in the same project.
Note that different environments will have different package managers. Node developers will be familiar with npm or yarn package managers, while Python developers will find pip to be a popular choice. Most package managers will take a description of package dependencies for a project and automatically resolve and download them from a software repository they can configure.
On top of using a package manager to simplify a variety of package management tasks, it is important to also consider a package locking system. By default, package managers may update package versions and their dependencies automatically. However, this behavior could introduce annoying inconsistencies to development environments and in the worst case, invite a bug or a yet-unknown vulnerability into the system.
Package lock solutions freeze the version of every package (and their dependencies) so that the dependency tree stays stable. Updates to versions are performed as part of a versioned code change—not pulled in automatically. This ensures that developers are all working with the exact same version of the application and are in control of any package upgrades.
Package managers and package lock files are essential tools for dependency management and security. However, organizations should be aware of the large ecosystem of package manager add-ons that can take security even further.
Two solutions, in particular, may be useful to implement:
A software bill of materials (SBOM) is a list of all software dependencies, including their version and source, usually generated by tooling and output in one of the SBOM standard formats. SBOMs help organizations examine their dependencies for package vulnerabilities internally; they can also be published externally to provide risk transparency among end users and customers. Note: While an SBOM assists in detecting, for example, whether a package is affected by a known CVE, an SBOM by itself is not a preventative code security measure.
Software composition analysis (SCA) scanners automate the process of detecting security threats in source code by analyzing open-source packages and surfacing known security threats to developers who can then take action. However, these scanners are limited to known risks and are not designed to flag unknown or low reputation packages.
Ultimately, third party package security is more than just asking “Is there a known vulnerability?” and “Where does this vulnerability exist in my code?” Because packages evolve over time, and vulnerabilities are a lagging indicator of risky packages out in the wild, there are more high-fidelity characteristics such as author reputation and maintenance cadence that can signal whether a package is going to be low-risk in the long run. For example, unmanaged or rarely updated packages carry the risk of a prolonged bug or exploit exposure.
Thus, while an SBOM or SCA can tell you if you are exposed today, implementing your own proper package reputation assessments will give you an idea of what your risk profile will be tomorrow and further down the road.
To effectively assess whether or not a package is reputable, it is crucial to deploy a solution that regularly examines the reputation of both new and existing packages. This tool should ideally conduct automated scans that include new package reputation analysis and ongoing updates to that package’s reputability.
In addition to automated analysis, organizations need to adhere to general practices around package use, such as vetting the reputation of third-party package authors before their introduction, regularly checking for new risks, and ensuring that developers understand the risks associated with package use.
By automating the analysis and alerting processes related to package reputation, organizations can ensure they are always covered and minimize the potential risks associated with third-party dependencies.
