NuGet is the go-to package manager for .NET and is built right into tools like Visual Studio, making adding, updating, and managing libraries super easy. By default, Visual Studio pulls packages from NuGet.org—but giving your team unrestricted access to all those packages can be risky.

Over 80% of projects rely on outdated dependencies, and nearly 70% of devs don’t even realize when they’re pulling in vulnerable packages. On top of that, open-source vulnerabilities are doubling every year, and even NuGet.org has had dozens of malicious packages slip through in supply chain attacks. The result? Outdated, unmaintained, or flat-out malicious packages can sneak into your codebase, leading to data leaks, downtime, tricky license issues, or broken user trust.

In this article, we’ll look at how NuGet packages are installed in Visual Studio, why connecting directly to NuGet.org is a little dangerous, and how using a package manager as a proxy can give your team the oversight they need without slowing them down.

Default NuGet Setup in Visual Studio and Its Pitfalls

NuGet’s simple integration with Visual Studio makes it super easy to connect to its public repository, NuGet.org. Here’s a quick look at how it all works—and what you should keep in mind.

By default, NuGet connects directly to its public repository—NuGet.org. You can browse NuGet packages through the Package Manager. Navigate to:

Tools > NuGet Package Manager > Manage NuGet Packages for Solution…

Then use the Browse tab to search for packages from the public repository.

Next, just select the package you’re looking for, check its details, and click Install to add it to your project. Accept any license agreements to complete the installation.

Connecting directly to NuGet.org might work well for personal projects, but for larger-scale teams… not so much. Limited control over security vulnerabilities and licensing concerns make this unsuitable for using NuGet at scale. Let’s dive into these risks.

The Problem with Connecting Directly to NuGet.org 

Connecting Visual Studio to NuGet.org is totally fine for personal or hobby projects. It’s fast, easy, and gives you access to thousands of packages. But in a team or organizational setting, this convenience can backfire. Without oversight, developers might pull packages that aren’t production-ready, or worse, introduce serious risks:

⚠ Licensing: Many packages have restrictive terms in their license that might lead to legal complications, like in the case Entr’Ouvert v. Orange, where a GPL commercial license wasn’t obtained, resulting in litigation and a nasty fee.

⚠ Deprecated packages: When popular libraries lack support and become outdated, projects are left without clear alternatives and get stuck with compatibility issues.

⚠ Vulnerabilities: Vulnerable packages can open the door to security issues… But not every vulnerability is actually a problem. A high severity flag (thanks, nuget audit) doesn’t always mean your app is at risk—context matters. That’s why oversight is important, so you can decide case by case what truly matters.

These challenges highlight the need for better oversight in package management, and that’s where a proxy package manager like ProGet can help.

Using a Proxy Package Manager with NuGet Packages

In ProGet you can proxy packages from NuGet.org, without a direct connection, and set up approval flows to oversee what packages get used, and limit developers to pulling production-safe packages.

You can even automatically identify vulnerable packages with vulnerability scanning and decide whether these packages are blocked or permitted, and set up license rules for automatically detected licenses, which you can prevent from being downloaded.

Adding ProGet Feeds as a Source in Visual Studio 

Once your approved ProGet feeds are ready, it’s super easy for devs to add them as a source in Visual Studio. In Visual Studio, navigate to:

Tools > NuGet Package Manager > Package Manager Settings > Package Sources

Then, deselect the nuget.org checkbox to stop Visual Studio scanning NuGet.org and ProGet for packages. Limiting package pulls to ProGet avoids licensing issues, vulnerable packages, and dependency conflicts, common problems when using public sources.

Next, create a new package source by clicking the + button at the top right. Give your new source a name and enter your ProGet feed URL. Finally, click OK to save your changes. 

Bonus: Saving Your Favorite NuGet Packages 

One more thing before we wrap up: An old Reddit thread highlights a frustration many developers have, but not many tools fix, even with how much devs value quick access to frequently used packages across projects.

ProGet’s package promotion can be used to create feeds of curated, frequently used packages, and download stats make it easy to see which packages are frequently downloaded, which is way more convenient than just pulling packages straight from NuGet.org.

Beyond Visual Studio — Doing NuGet the Right Way

Connecting Visual Studio straight to NuGet.org is fine for side projects, but in a professional setting, it’s risky. You’ve got no control over licenses, outdated packages can sneak in, and security vulnerabilities can become a real problem. These challenges mean this approach just isn’t right for using NuGet at a large scale.

That’s where a proxy package manager like ProGet comes in. It gives you control over what packages are allowed, how vulnerabilities are handled, and which licenses are acceptable. That way, devs in your team can only use safe, compliant packages in production, and you have the oversight needed for organizational-level workflows.

That was quite a bit of info, and I highly suggest you save this page for later use! Even better, why not grab our eBook, “NuGet at Scale”? By downloading it, you’ll dive deeper into vulnerabilities, licenses, and a lot more! Get your free copy now!