Much of today’s software is powered by open-source libraries, which lets developers build on pre-existing code instead of creating everything from zero. However, every dependency a team incorporates also introduces potential risks associated with its maintainers, the underlying software, and the methods used to handle security vulnerabilities. While popularity and download figures can provide a misleading impression of safety, even a package with widespread adoption might be abandoned or slow to apply necessary security patches.
Understanding what to seek out before including or keeping a dependency can determine whether it forms a robust base or becomes a transferred burden. Below, members of Forbes Technology Council outline the trust indicators that teams should assess when selecting open-source dependencies or examining those already implemented.
Evaluating Release Stability and Response Times
A dependable dependency should feature scheduled releases, clear upgrade paths, and no unexpected disruptive changes. While security is very important, stability is equally vital. When every update is an engineering challenge, the dependency will silently turn into tech debt despite its popularity,
said Ajay Pandey. Likewise, commit frequency tells you the project is alive. Response behavior tells you whether someone is actually watching the door. A repository with 10,000 stars and an 18-month-old unresolved security issue is not a dependency—it is a liability with good documentation,
according to Mukul Arora, Persistent Systems Limited.
Verifying Provenance and Maintainer Vetting
Teams need to identify who is responsible for a dependency, how releases are constructed and authenticated, and if software artifacts can be linked to verified source code. Popularity and download counts are not security guarantees. Provenance verification, combined with continuous vulnerability monitoring, strengthens software supply chain resilience,
stated Sai Krishna Manohar Cheemalurthi, U.S. Bank. A project’s procedure for trusting individuals is also crucial. Attackers have learned it is easier to earn a tired maintainer’s trust over months than to find a flaw in the code. Check whether new maintainers are vetted by more than one person and whether handoffs happen in public,
said Flavius Plesu, OutThink.
Using Automated Checks and Assessing Patch Records
One resource for assessment is the OpenSSF Scorecard. It’s a useful, free and automated check of practices that covers branch protection, code review, pinned dependencies and signed releases. A low score isn’t automatically disqualifying, but it can tell you what risk you’re inheriting and give every team the same repeatable bar instead of a gut feel based on GitHub stars,
explained Dan Sorensen, Nexus Security Advisors. The most valuable trust signal, though, is the history of patching. With AI now finding vulnerabilities in open source faster than ever, the question is no longer whether a flaw will be found but how quickly it can be fixed once it is found,
said Anuj Goel, Cyware.
