Today more than 90% of software is built on open source packages. These packages may have unknown risks, such as security vulnerabilities, poorly maintained codebases and undesirable licenses. In the .NET ecosystem, these open source packages are usually managed via the NuGet package manager, although others, such as Paket, exist as well. What’s important to remember about open source risk is that you must look at the entire .NET dependency tree to really understand your full risk, this means looking beyond the direct NuGet or Paket packages that you and your development team might install. Software Composition Analysis (SCA) for .NET will analyze all the packages (both direct and transitive) for vulnerabilities and licenses.
What are the risks?
Open source NuGet package risks come in many forms. The most well known is security vulnerabilities introduced by using an open source NuGet package. Based on SOOS’s analysis, .NET vulnerabilities typically fall in the Medium and High severity ranges which means they are impactful and should be remediated quickly. Beyond vulnerabilities, there are a number of overlooked risks. These include risks such as relying on a poorly maintained NuGet package, accidentally installing a potentially malicious look-a-like package through a typo, or installing a NuGet package with a license that is incompatible with your codebase.
Severity Breakdown Across .NET Vulnerabilities
How do I detect open source package risks in .NET?
First, you need to determine which manifest file format(s) are being used in your projects. For .NET there are a number of manifest formats available, many of which depend on the version of .NET being used, such as .NET Core or .NET Framework. Additionally, there is also the choice of using lock files vs non-lock files. Lock files can be a good choice, when available, because they are generated by the NuGet (or Paket) package manager and therefore are the exact set of packages and versions that have been resolved and will be used in your build. Lock files are not always available though, especially for older versions of the .NET framework. In these cases look for a tool, such as SOOS, which has advanced dependency tree and version resolution capabilities which mirror the NuGet/Paket package manager and can produce the same results without a lock file.
Common .NET Lock File Formats:
packages.lock.json (NuGet package manager lock file)
paket.lock (Paket package manager lock file)
Common .NET Manifest Formats:
Packages.config (older .NET framework projects using the NuGet package manager)
csproj (.NET C# project file using the NuGet package manager)
vbproj (.NET VB project file using the NuGet package manager)
paket.dependencies (Paket package manager)
What features should I look for in a .NET SCA solution?
Vulnerability Detection
This should be at the top of everyone’s list. It is imperative that you choose a solution which inspects the full .NET dependency tree and supports the .NET manifest formats that you use. This ensures that vulnerabilities located deep in your dependency tree will be caught. The ability to research vulnerabilities, view the introduction paths of found vulnerabilities, include suggested fixes, create PRs, and suppress false positives, should be of top priority.
License Analysis & Governance
Ensure licenses from the full .NET dependency tree are inspected. Composite licenses and license expressions such as “GPL-2.0-only OR BSD-3-Clause” or “GPL-2.0-with-autoconf-exception” should be analyzed. Find a solution which also supports license governance policies (such as excluding specific licenses) and one which summarizes what you can and cannot do with your software based on the NuGet package license restrictions.
Dependency Health/Risk
The ability to understand and be notified about the .NET dependency risks for your entire dependency tree is an often overlooked feature. You should be alerted to and/or able to create governance policies which protect against low open source contributor counts, small NuGet package download counts, dependency typos, and other risk factors. Additionally, understanding how out of date your NuGet package versions are, is an important aspect of staying current with your .NET dependencies.
Integrations & Data Exports
How you integrate with an SCA solution plays a huge role in how quickly you can get up and running and how easily you can integrate the solution into your workflow. Select a solution which supports your CI/CD or SCM system so you can run scans on each commit across multiple branches. Once issues are found, they should be able to be pushed to your issue management system, SBOM hub, SEIM/SOAR, or compliance solution. Typically formats for export should include SBOM formats like SPDX, CycloneDX, VEX, as well as non-SBOM formats like SARIF, or CSV.
Automatic Ongoing Analysis
The ability to provide ongoing analysis (running scans at least daily, even if code hasn’t changed), is extremely important, especially for teams that have code that sits in production for longer periods of time without being updated. Running ongoing scans will ensure that when new .NET vulnerabilities are found you will be promptly notified, even though a typical CI/CD scan wasn’t initiated. Finding a solution that does this automatically, so you don’t have to run a scheduled job, means there is one less scheduled job that you have to monitor and maintain!
How do I get started?
Running a Software Composition Analysis (SCA) solution against your .NET projects is the best and quickest way to start protecting yourself from vulnerabilities, license risks and unmaintained NuGet packages. Look for a solution like SOOS which is easy to implement, cost effective, and has a free trial so you can evaluate before committing.
