Skip to main content

Announcing automated fixes for vulnerabilities in .NET dependencies

Artikel von:
Daniel Berman
Daniel Berman

17. November 2021

0 Min. Lesezeit

We’re pleased to announce improved support for .NET applications in Snyk Open Source, allowing developers to fix vulnerabilities in .NET dependencies with the help of actionable advice and automated pull requests!

As of the time of writing, NuGet, the Microsoft-supported and de-facto standard package manager for .NET, has 276,266 unique packages, downloaded on average more than a billion times a week! In 2020, and second, only to npm, NuGet saw the largest YoY growth in terms of the number of packages added.

These numbers reflect the popularity of the .NET framework but also one of the main challenges facing .NET development teams — managing and mitigating the security risk posed by known vulnerabilities found in these packages. Often, these vulnerabilities are found in transitive dependencies, packages pulled in by other packages. This obscures visibility and complicates the required fix.

The new capabilities in Snyk Open Source make it easier for developers to not only accurately identify vulnerabilities in both their direct and transitive .NET dependencies, but also fix these vulnerabilities automatically.

.NET security in Snyk Open Source

Identification and remediation of vulnerabilities in .NET dependencies in Snyk Open Source are facilitated by two key processes: accurate analysis of the dependency tree and subsequent correlation with Snyk Intel — Snyk’s market-leading vulnerability database.

Dependency analysis

In the .NET ecosystem, there are multiple levels of dependencies, some of which are obvious and some completely hidden to a developer.

To be able to correctly identify the vulnerabilities for a given .NET application, these dependencies need to be resolved accurately.

We resolve dependencies differently in the Snyk CLI and in source code management (SCM) systems (e.g. Azure Repos, GitHub, etc). For example, in the CLI, depending on how you are managing your project dependencies, e.g. PackageReference or packages.config, we scan your obj/project.assets.json for the former and the packages directory for the latter. This approach allows us to be very accurate.

Scanning projects via the SCM integration requires a different process since the generated files mentioned above are not available. To overcome this we follow the NuGet dependency resolution algorithm to construct a dependency tree. It is worth mentioning that runtime dependencies (provided by the environment a.k.a. metapackages) would be resolved more accurately in the CLI if the host machine uses a similar runtime SDK to the server running the app.

Vulnerability intelligence

Once the dependency tree is determined, Snyk Open Source correlates the list of dependencies with Snyk Intel. Containing a comprehensive list of .NET vulnerabilities (440% more than the next publicly available database), Snyk Intel provides accurate and actionable information to help power a quick fix, including the affected package versions and the version upgrade needed to fix the issue. In total, Snyk Intel contains over 700 .NET vulnerabilities, 63% of which are critical and high severity vulnerabilities.

The case of the UbracoForms package is an interesting example. Used for building forms and questionnaires into applications, UbracoForms has been downloaded hundreds of thousands of times. While the latest version of the package, version 8.8.0, is free of vulnerabilities, previous versions contain a critical severity remote code execution (RCE) vulnerability.

wordpress-sync/dotnet_vuln

Snyk Open Source uses this information to calculate the fix required, which is reflected both in the fix advice provided and the fix pull requests that are triggered automatically.

Let’s take a closer look.

.NET fix advice  in Snyk Open Source

Snyk integrates with Git-based SCMs, including GitHub, GitHub Enterprise, Azure Repos, GitLab, Bitbucket Server, and Bitbucket Cloud, enabling you to easily import your projects and subsequently find and fix the vulnerabilities (and license issues) identified in them, all as part of your existing development workflow.

Importing a project is simple. Simply go to the Projects page, click Add project at the top-right corner of the page, and select the type of project you want to import (e.g. GitHub, Bitbucket, etc.) and the repository itself containing the project. For the sake of demonstration, I’ll be importing this sample application that is purposely vulnerable. 

As the project is imported, Snyk will automatically scan it for issues. In the example here, Snyk Code has identified an issue in my custom code (1) while Snyk Open Source has identified a longer list of issues in the open source .NET packages I’m using (2).

wordpress-sync/blog-dot-net-dependencies-scan

Clicking the .NET project file enables you to examine these issues more closely.

wordpress-sync/blog-dot-net-dependencies-issue

A total of 18 issues were identified and Snyk drives a fix in a few ways.

First, under the Dependencies tab, a full dependency tree is displayed, providing you with full visibility into all the .NET packages used to build your project and the issues they are introducing — both known security vulnerabilities and license issues:

wordpress-sync/blog-dot-net-dependencies-tree

You can filter the tree to examine only those dependencies that are vulnerable or only those that have a license issue. Again, this provides you with a clear picture of how issues were introduced, either directly or via transitive dependencies.

Next, on the Fixes tab, Snyk displays advice for fixing vulnerabilities. Not all issues can be fixed, but for those that can, you will be able to see the exact upgrade path needed to implement the fix.

Note: Snyk Open Source recommends an upgrade path for vulnerabilities identified in both direct and transitive dependencies but only in case a new version of the direct dependency fixing the vulnerability exists.

In the case of our example, Snyk is telling us that upgrading the TinyMCE package from version 4.8.2 to version 5.6.0 will fix 4 different vulnerabilities:

wordpress-sync/blog-dot-net-dependencies-tinymce

Back to the main Issues tab. Here, Snyk Open Source provides a wealth of information to help you sift through the list of issues and prioritize fixes. This includes a priority score on the top-right corner of the issue card that gives you a quick indication of how urgent the issue is (more about Snyk’s Priority Score here) and the upgrade path.

In the example below, Snyk Open Source has identified a critical vulnerability in the Halibut package and is recommending an upgrade to version 4.4.7:

wordpress-sync/blog-dot-net-dependencies-halibut

To fix the vulnerability, you can manually trigger a pull request by clicking the Fix this vulnerability button. This opens up a page listing all the vulnerabilities that you can fix with a pull request and you can choose to fix one or more vulnerabilities by selecting them:

wordpress-sync/blog-dot-net-dependencies-open-fix

In this case, I’m going to stick with the one vulnerability I want to fix — in the Halibut package.

Clicking Open a Fix PR at the bottom of the page triggers the PR, which is then opened for me to examine within the relevant repository in GitHub:

wordpress-sync/blog-dot-net-dependencies-fix-pr

The pull request contains all the context I need to determine whether to merge or not, including information about the vulnerability itself and the scope of the suggested fix.

wordpress-sync/blog-dot-net-dependencies-merge

Snyk will also automatically trigger a pull request in your repository if a new vulnerability is identified or if a new fix becomes available for one of your existing vulnerabilities.

To ensure you don’t accidentally introduce new issues into your project, Snyk Open Source will also automatically test any new pull request you, or any other contributor in the repository opens for vulnerabilities or problematic licenses:

wordpress-sync/blog-dot-net-dependencies-git

Getting started!

The .NET ecosystem is relatively complex in comparison to other ecosystems. To be able to successfully manage and mitigate the risk posed by open source .NET packages it is important to not only accurately decipher the dependency tree but also provide the context and workflows needed to be able to take action and fix vulnerabilities found.

The new remediation capabilities in Snyk Open Source help development and security teams find the different issues in their applications, actively fix them as part of their day-to-day workflow, and prevent new issues from being introduced. More information on how to get started can be found in our official Snyk for .NET documentation.

If you haven’t already, sign up to Snyk to give it a try! Happy fixing!