How do you decide whether you can trust an open-source package? If you are like most developers I know, you look at the number of downloads, check the license name and maybe glance at the list of known vulnerabilities. I used to do the same. But after maintaining Fluent Assertions for more than fifteen years, I have learned that this tells you surprisingly little.

Every package you add becomes code you own. You did not write it and you did not review it, but you ship it, and it is your problem when it breaks. So what makes a package reliable? And what about the risks almost nobody looks at? Think of a license that changes in the next major version, a maintainer who is the only person with publish rights, a project where nobody has answered an issue in months, or a release that nobody can trace back to its source code. In 2026 we saw worms spread through npm using stolen maintainer accounts, so this is not a theoretical problem anymore.

In this session, I’ll first show you the signs of a healthy package and the risks you probably never considered. Then we’ll follow the vulnerability data back to where it comes from, and I’ll explain why the NVD can no longer be your only source. Finally, I’ll compare free and commercial tools such as GitHub Advanced Security, Snyk, Socket, Endor Labs, Black Duck, Sonatype and Mend on every one of those risks. I’ll include my own open-source tool, PackageGuard, and be honest about where it falls short.

You’ll leave with a checklist you can use tomorrow and a realistic view of what each tool can and cannot do for you.

Most developers add open-source packages without thinking twice. I know, because I have been on both sides for a long time. As a consultant I have seen teams get burned by packages they never really looked at. As the maintainer of Fluent Assertions and many other open-source projects, I have seen how a license change can surprise thousands of users overnight. This talk is my attempt to share what I learned the hard way.

The session is aimed at developers, tech leads and architects who use NuGet, npm or similar package managers. You do not need a security background. My examples come mostly from .NET, but everything applies to other ecosystems as well.

I’ve organized the talk in five parts:

1. What makes a package healthy? Six signs to look for, why stars and downloads are misleading, and a five-minute check anybody can do with the .NET SDK and a few free websites.

2. The risks nobody looks at. Legal, security and operational risks, illustrated with real stories: the commercial license switches of 2025, the xz-utils backdoor, and the npm worms of 2026.

3. Where does vulnerability data come from? How a CVE reaches your scanner, who MITRE, CISA, NIST, GitHub, OpenSSF and ENISA are, why NIST stopped enriching most CVEs in April 2026, and why malware almost never gets a CVE.

4. Free versus commercial tools. An aspect-by-aspect comparison of eight tools. I’ll tell you where each one is strong and where it isn’t, and I’ll do that for the free tools as well.

My goal is not to sell a tool. It’s to make people ask better questions before they add or upgrade a dependency. Attendees leave with a practical checklist, a clear picture of the vulnerability data landscape, and advice on how to combine free and paid tools in a way that makes sense for their situation.