.NET — About NuGet Package Audit and "False-Positive" Security Warnings

Over the last few years, the commitment to `information security` has evolved in a positive direction - more organizations taking a far more serious posture when it comes to system security and its associated risks. Software development processes are no exception in this regard.

In this post, I will discuss recent NuGet security-related changes (in regards to shift-left testing) and how these changes affect DevExpress customers.

Built-in Microsoft Diagnostics for Vulnerable Packages - NuGet and Visual Studio

As you probably know, Microsoft has introduced multiple enhancements to help mitigate security-related risks for software developers (shift-left testing). Here are some important Microsoft articles on this subject matter:

• .NET 9 SDK: NuGetAudit now raises warnings for vulnerabilities in transitive dependencies (GitHub)
• Building a Safer Future – How NuGet is Tackling Software Supply Chain Threats (Microsoft blogs, Jon Douglas)
• Auditing package dependencies for security vulnerabilities (Microsoft Learn)

If you are researching the latest technologies and are using the most recent previews of the .NET 9 SDK/Visual Studio 2022, you may encounter the following circumstance when loading DevExpress demos, project templates, or samples.

If you prefer to use command line tools (CLI) with NuGet, the picture may be similar:

Needless to say, these messages seem scary...but the question is whether you need to worry or bombard the DevExpress Support Center? :-).

Security Audit Tools Are Not Always Right

Example with System.Formats.Asn1

Let's review the recent System.Formats.Asn1 v6.0.0 vulnerability, which was fixed by Microsoft in July 2024: https://github.com/advisories/GHSA-447r-wph3-92pm. According to the Microsoft security advisory, System.Formats.Asn1 v6.0.1 is patched and can be used. This is also confirmed by a NuGet audit:

❯ dotnet list package --include-transitive
Project 'app' has the following package references
   [net8.0]:
   Top-level Package          Requested   Resolved
> System.Formats.Asn1     6.0.1        6.0.1

❯ dotnet list package --include-transitive --vulnerable
The given project `app` has no vulnerable packages given the current source

However, if we run our test .NET 8 project with this patched version, you will notice that the application loaded a different version from the .NET 8.0.6 Runtime, which may still be vulnerable:

❯ dotnet run
Assembly: 
System.Formats.Asn1, Version=8.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
Location: 
C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.6\System.Formats.Asn1.dll
FileVersion: 8.0.624.26715

Catch #1

Even though NuGet audit gives you a green light after a NuGet package update, you may still be at risk or require additional actions. In this particular instance, you must update the .NET Runtime itself:

Catch #2

Even though diagnostic tools may suggest that DevExpress and other third-party libraries (even the standard Microsoft BCL) have vulnerabilities, the underlying issue may involve the .NET Runtime itself. Additional digging/research may be needed to determine the real issue.

Let me quote Jon Douglas (a Principal PM at Microsoft working on NuGet) about the current state and future plans in this regard:

Currently, we don't have advanced features to minimize false positives, like static analysis tools that determine if a vulnerable code path is actually reachable. We are considering implementing tools similar to the  vulncheck feature in Go to improve our analysis. This would require further development to enhance the accuracy of our results. As of now, we are at a preliminary stage where we alert you to security vulnerabilities, and you will need to assess their potential risk yourself.

Catch #3

With .NET 9, Microsoft extended built-in NuGet diagnostics to transitive dependencies as well (previously, they only scanned direct dependencies). For example, when a DevExpress packages previously referenced System.Text.Json or Azure.Identity, only direct or first-level dependencies were considered by built-in IDE tooling.

With the recent .NET 9 change, NuGet and Visual Studio will scan inner packages and also their own dependencies recurrently. For now, this feature can be seen in Visual Studio 2022 Preview (for example, the demo app I used for the first screenshot will build without errors in non-preview Visual Studio 2022 today).

As a result, we expect to see yet more warnings and false-positives (see point #1). You may have already read reports from the community (on GitHub) on this subject - individuals trying to discover/remedy false-positives by the NuGet diagnostic tools:

• Possible NuGet vulnerability false positive when transitive package conflicts with BCL?
• dotnet list packages should not report false positives for assemblies in shared directory
• Support "Supplied by Platform" scenario in restore

Summary

We welcome Microsoft's commitment to security as their initiatives ultimately help save time and deliver more reliable solutions to market. Automatic vulnerability detection is a complicated process and requires a careful manual review once issues are discovered/reported. Through human analysis, you can discover false positives regardless of the scanning tool used. Said differently, simply because a scanner logs an issue, does not mean that the issue represents a security vulnerability (a false-positive).

At DevExpress, we already use NuGet audit to scan our own packages and associated dependencies for each release (making certain that non-vulnerable dependencies are used by default). We also use Veracode for static code analysis (learn more).

We hope (and expect) that built-in NuGet and Visual Studio diagnostic tools will consider the current .NET Runtime version so as to reduce the number of false positives in the future (especially when .NET 9 ships at the end of this year). Until that time, you should carefully review each issue to determine whether it is a legitimate vulnerability or simple a false-positive report by the scanner. As always, if you have any questions or doubts, feel free to contact us in the DevExpress Support Center.

Your Feedback Matters

Thanks,
Dennis Garavsky
Principal Product Manager
dennis@devexpress.com