Are you deploying applications to production with packages downloaded directly from NuGet.org? A lot of organizations do this. It’s basically the default approach for working with NuGet packages. But it’s not a secure approach, and it can lead to a lot of problems down the line.
Packages from NuGet.org are not vetted for quality, unwanted licenses, or vulnerabilities. Requiring developers to constantly make decisions on which packages are acceptable is not only inefficient, but will lead to unwanted code in production. This is where a package review and approval process comes in.
In this article, we’ll take a look into:
- Why using raw packages directly from NuGet.org is not a good approach
- What a package approval workflow is
- Why you should use one in your team
- How to easily set one up in a tool like ProGet
3 Risks of Using Packages Directly from NuGet.org
Anyone can publish a package to NuGet.org; they aren’t vetted or endorsed by Microsoft, and using them without properly vetting them can lead to all sorts of issues.
⚠ Security Risks and Vulnerabilities
Many packages contain known vulnerabilities that attackers can exploit; some even have malicious code. Not all packages are insecure, but unless you look for security issues, your applications and data could be compromised.
⚠ Unwanted Licenses
Nearly all NuGet packages have a license agreement that will legally bind your company when you use the package. Some of these licenses (like GPL-3) are not a good fit for most applications and can put your company at serious legal risk.
⚠ Low Quality Packages
There are a lot of great packages on NuGet.org, but some are simply not suitable for production code. They can introduce bugs or performance issues into your application. This results in wasted time and effort to resolve, as you may need to troubleshoot problems caused by using these packages.
Use Only Approved NuGet Packages
How? A Package Approval Workflow
Think of a Package Approval Workflow as “code review” but for NuGet packages. And like code review, the process will vary form team to team. Primarily, you’ll need to vet packages from NuGet.org before they are used in the application.
This means checking that each package has:
- Low/no Vulnerabilities or Security Risks
- Acceptable License Agreements
- Suitable Quality for Production
Finding the right process is important. If it’s too complex, you’ll risk developers bypassing the process. If it’s not thorough enough, unwanted packages will make their way in your application.
Implementing A Package Approval Workflow
A package approval workflow is typically built with two feeds. One of the feeds is used to store unapproved packages from NuGet.org. After the packages are vetted, they are “promoted” to the other feed for production use.
What are the Benefits of a Package Approval Workflow?
A package approval workflow ensures that developers can only use packages that have been vetted.
It’s a simple and effective way to reduce the day-to-day decisions that developers need to make. They won’t need to constantly consider what packages they should or shouldn’t be using.
How to Create a Package Approval Workflow for NuGet
Creating a package approval flow for your NuGet packages is pretty straightforward and can be done with two feeds in a private NuGet server.
We’ll use ProGet here, but other NuGet servers are conceptually similar.
First, create two NuGet feeds, one for unapproved packages and one for approved packages that developers can download packages from.
You’ll want to “connect” the unapproved feed to NuGet.org. This will populate the feed with remote NuGet packages from nuget.org. They can be downloaded through ProGet and are available for promotion once vetted.
After vetting a package for quality, acceptable licenses, and vulnerabilities, you can promote it to the approved feed.
Now, the package will be in the approved feed, ready for developers to download and use.
You may also want to configure permissions so developers can only view or download packages from the approved feed.
Read a more detailed breakdown in our How To: Approve and Promote Open-Source Packages guide.
We also have a 3-minute video that breaks it down: