Open-source libraries power much of today’s software, allowing developers to build on existing code rather than start from scratch. But every dependency a team adds also brings potential risks tied to its maintainers, the software it relies on, and how security issues are handled. Popularity and download counts can create a false sense of safety, and even a widely used package may be neglected or slow to receive security fixes.
Knowing what to look for before adding or retaining a dependency can mean the difference between a solid foundation and an inherited liability. Here, members of Forbes Technology Council share the trust signals teams should evaluate when choosing open-source dependencies or reviewing those already in use.
2. Release Stability And Predictability
I’d evaluate how safely the project development is going. A reliable dependency should have planned releases, proper migration procedures and no surprises with breaking 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. – Ajay Pandey
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
3. Verifiable Software Provenance
One critical trust signal is verifiable software provenance. Teams should know who maintains a dependency, how releases are built and signed, and whether artifacts can be traced to trusted source code. Popularity and download counts are not security guarantees. Provenance verification, combined with continuous vulnerability monitoring, strengthens software supply chain resilience. – Sai Krishna Manohar Cheemakurthi, U.S. Bank
4. OpenSSF Scorecard Results
First, run it through 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. It’s one tool you can use to evaluate and get consistent results for open-source software. – Dan Sorensen, Nexus Security Advisors
5. Response Times To Vulnerability Reports
Check when the maintainer last responded to a reported vulnerability, not when they last pushed code. 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. – Mukul Arora, Persistent Systems Limited
6. Vetting Of New Maintainers
Examine who gets to become a maintainer. 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. A project’s process for trusting people matters as much as its code. – Flavius Plesu, OutThink
7. Transparency In Handling Security Reports
One trust signal I’ve observed is how maintainers respond to reported security issues. It’s critical to look for clear updates and evidence that they fix problems rather than relying on download counts. A popular dependency can still leave your team waiting for a fix. – Mark Vena, SmartTech Research
8. Security Patch Track Record
The most useful trust signal is the patch track record. 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. Teams should look at the dependency’s current vulnerability history and update cadence and determine whether maintainers respond rapidly to security issues. A modern software project that is popular but patches slowly should be avoided in the AI era. – Anuj Goel, Cyware
9. Number Of Active Maintainers
Check who is actually maintaining it. A popular library with millions of downloads can still rest on one unpaid volunteer who hasn’t merged a fix in a year. Look at recent commit activity, how quickly security issues get patched, and how many active maintainers there are. Download counts measure popularity, not durability, and you’re inheriting the support risk. – Steven Singer, Arbill
10. Security Assessment Of The Exact Package Version
Open source runs on shared ingenuity. Give that ingenuity a security check: look for a current assessment of the exact package version you’ll deploy, inspecting its contents for malware, tampering and suspicious behavior alongside known vulnerabilities. Check each update and reassess existing dependencies as threats emerge. Trust the community, and give it the backup it deserves. – Mario Vuksan, ReversingLabs
11. Proven Use In Established Projects
Look at support and usage. Open source is great in terms of lesser cost and general support, but with general support, there is more risk. An open-source project can have security flaws or problematic issues that are not easily spotted by even the most advanced professionals. Look for something that serves one purpose and has been proven before by use in other high-profile projects or companies. Then go for it—with contingencies in place. – WaiJe Coler, InfoTracer
12. Reproducible Software Releases
A useful signal is whether another party can rebuild the published release from the tagged source and get the same artifact. Signed provenance says who claims to have built it; reproducibility lets an independent team check that claim without trusting the maintainer’s pipeline. Before adoption, try this on one release and see whether the project documents the toolchain, inputs and steps needed to repeat the build. This makes artifact integrity independently testable. – Jagadish Gokavarapu, Wissen Infotech
13. Consistent Updates And Versioning
A trustworthy project actively updates its own upstream dependencies, maintains clear semantic versioning, and demonstrates steady commit velocity. If a library has millions of downloads but hasn’t shipped a patch or addressed security pull requests in six months, its technical debt becomes yours the moment you import it. – Japjeev Kohli, Transurban
15. Accountability For Dependency Selection
Ask who chose it. More dependencies now arrive because a model suggested them, not because an engineer compared options. At Google, adding a dependency meant someone had to argue for it and own it afterward. That argument is the trust signal. If nobody on the team can say why this package is better than the alternatives, you have not evaluated a dependency. You have accepted a recommendation. – Prashant Jalan, Guickly
16. Health Of The Maintainer Community
I’d look at whether the project has an active, healthy maintainer community. Not all open-source projects are resilient. A dependency can be technically excellent yet still introduce risk if it’s maintained by only one or two individuals, receives infrequent updates, or lacks clear governance. Healthy open-source projects tend to show consistent releases, responsive issue management, transparent security practices and a diverse contributor base. – Ciaran Cosgrave, Nearform
17. AI Model Weight License Terms
Read the license on the model weights, not only on the code. Teams now pull open-weight AI models into products the way they pull in libraries, and some of those licenses ban commercial use, cap the number of users, or restrict whole categories of use. The code around a model can carry an MIT license, while the weights you ship come with different terms. – Jerry Tang, Atlas Cloud
18. Verified Functional Accuracy
One key trust signal is whether an open-source dependency creates accurate and consistent results. Libraries used in calculations, data conversion or scientific computing can cause errors that affect major decisions. Test key functions against trusted reference results and check for rounding errors or erratic outputs. A package may meet security standards but still produce wrong results. Trust must include functional accuracy, not just security and maintenance. – Salice Thomas, Wipro Limited
19. Project Governance And Security Practices
Essentially, I look for good governance signals. How large and spread out is the group of top maintainers—the more coherent, the better—and what’s their relationship with the project? How fast do they fix issues, especially security issues? Are security tests embedded in the build and release pipelines? Are there external security validations like OpenSSF? Regarding general health, how many stars and how many forks? What’s the recent commit and release cadence? – Julien Vantyghem, Quintess AI