---
title: "Checking your solution for NuGet vulnerabilities or deprecated packages"
description: "While your software might be the best in the world, it's only as good as the libraries it uses. In this small blog post, we will discover how to check your solution for NuGet vulnerabilities or deprecated packages. "
updated: 2024-05-02
tags: ["Nuget", ".NET"]
canonical: "https://steven-giesel.com/blogPost/a825c041-26dc-4488-8707-17697871d08e/checking-your-solution-for-nuget-vulnerabilities-or-deprecated-packages"
---

# Checking your solution for NuGet vulnerabilities or deprecated packages

While your software might be the best in the world, it's only as good as the libraries it uses. In this small blog post, we will discover how to check your solution for NuGet vulnerabilities or deprecated packages. 

## Motivation
You might check your own code for common issues like Cross-Site Scripting (XSS), SQL Injection, etc. But what about the libraries you use? They might have vulnerabilities or be deprecated. Attackers could use a **supply chain attack** to inject malicious code into your software.

### What is a supply chain attack?
A supply chain attack is a cyber-attack that seeks to damage an organization by targeting less-secure elements in the supply chain, like, say, a third-party package. 

## NuGet to the rescue
Since some versions (.NET 5 SDK), NuGet will report vulnerabilities and deprecated packages on their website and, of course, also via the CLI. And this is what we will use in this blog post. We can leverage the `dotnet` CLI to check for vulnerabilities and deprecated packages.

Let's create a simple project like this:
```xml
<Project Sdk="Microsoft.NET.Sdk">

    <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>net8.0</TargetFramework>
    </PropertyGroup>

    <ItemGroup>
      <PackageReference Include="System.Data.SqlClient" Version="4.8.5" />
    </ItemGroup>

</Project>
```

`System.Data.SqlClient` in Version 4.8.5 has a known vulnerability. If you go to the NuGet website, it looks like this:

![Nuget Website](https://linkdotnetblog.azureedge.net/blog/20240312_Nuget/Nuget.webp)

So, the website tells us that there is a vulnerability in this package and there might be a newer version available.

If we do the same with the CLI:
```bash
dotnet list package --vulnerable
```

This will result in:
```no-class
The following sources were used:
   https://api.nuget.org/v3/index.json
   https://ci.appveyor.com/nuget/benchmarkdotnet

Project `Vulnerable` has the following vulnerable packages
   [net8.0]: 
   Top-level Package            Requested   Resolved   Severity   Advisory URL                                     
   > System.Data.SqlClient      4.8.5       4.8.5      High       https://github.com/advisories/GHSA-98g6-xh36-x2p7
```

We could leverage that in a CI/CD pipeline to check for vulnerabilities and fail the build if there are any. Currently, the CLI always returns 0 as an exit code, so we have to parse the output to check for vulnerabilities. There is a ticket on GitHub to address that issue: https://github.com/NuGet/Home/issues/11315

If you do feel it is worth having, give the ticket a thumbs up. Alternatively, you can utilize tools like `grep` in your CI pipeline. Here is an example of how to do that with GitHub Actions:

```yml
- name: Check for vulnerable packages
  run: |
    set -e # This will cause the script to exit on the first error
    OUTPUT=$(dotnet list package --vulnerable)
    echo "$OUTPUT"
    if echo "$OUTPUT" | grep -q 'no vulnerable packages'; then
      echo "No vulnerable packages found"
    else
      if echo "$OUTPUT" | grep -q 'vulnerable'; then
        echo "Vulnerable packages found"
        exit 1
      fi
    fi
```

If you have a project with the name *Vulnerable*, then you have to specify a bit more of the error string, as also project names are printed to the console, which will lead to a failure if you have "MyAssembly.Vulnerable.csproj".

## More things you can do
It doesn't stop here - you can also check for vulnerabilities in the dependencies of your dependencies. This is especially important if you use a lot of third-party packages.

```bash
dotnet list package --vulnerable --include-transitive
```

Last but not least, you can also check for deprecated packages:
```bash
dotnet list package --deprecated
```

## Conclusion
Keep track of your dependencies. It is important to keep them up-to-date!