A few months ago I joined a company that is building a SaaS written in .NET. The code base is a decade years old and like many companies using Microsoft technologies, it has been through a few framework upgrades. The intent was to move to modern technologies and refactor outdated components, but the execution was rather poor. By the time I put on my CTO hat, many of the NuGet packages in the solution became outdated and even deprecated.
In the absence of technical leadership, neither developers nor managers cared much about code maintenance, developer experience, and security. When I opened our backend monorepo for the first time, I noticed that there was no README, no .editorconfig, no pre-commit hooks, no CI pipelines that cared about code quality and checking the state of dependencies.
In Python and Go projects, I rely heavily on linting, static analysis, and formatting tools. Not having these essentials would make me and my teams less productive. In Python and Go projects, I rely heavily on linting, static analysis, and formatting tools. Not having these essentials would make me and my teams less productive. So the first thing I did was understand what modern .NET brings to the table in this area. And I started by scanning the NuGet packages we use in all of our projects in a single solution for potential vulnerabilities.
It turned out that developers could simply run dotnet list package --vulnerable locally to keep an eye on security. But without automation, it's too easy to forget about that.
My first local scan produced the following result:
...
Project `Planfact.Infrastructure.Calendar` has the following vulnerable packages
[net6.0]:
Top-level Package Requested Resolved Severity Advisory URL
> System.Data.SqlClient 4.8.3 4.8.3 Moderate https://github.com/advisories/GHSA-8g2p-5pqh-5jmc
High https://github.com/advisories/GHSA-98g6-xh36-x2p7
The given project `Planfact.Infrastructure.Common` has no vulnerable packages given the current sources.
Project `Planfact.Infrastructure.Currency` has the following vulnerable packages
[net6.0]:
Top-level Package Requested Resolved Severity Advisory URL
> System.Data.SqlClient 4.8.3 4.8.3 Moderate https://github.com/advisories/GHSA-8g2p-5pqh-5jmc
High https://github.com/advisories/GHSA-98g6-xh36-x2p7
Project `Planfact.Infrastructure.Locker` has the following vulnerable packages
[net6.0]:
Top-level Package Requested Resolved Severity Advisory URL
> System.Data.SqlClient 4.8.3 4.8.3 Moderate https://github.com/advisories/GHSA-8g2p-5pqh-5jmc
High https://github.com/advisories/GHSA-98g6-xh36-x2p7
The given project `Planfact.Infrastructure.Locker.Tests.Unit` has no vulnerable packages given the current sources.
The given project `Planfact.Infrastructure.Pool` has no vulnerable packages given the current sources.
Project `Planfact.Infrastructure.Repositories` has the following vulnerable packages
[net6.0]:
Top-level Package Requested Resolved Severity Advisory URL
> System.Data.SqlClient 4.8.3 4.8.3 Moderate https://github.com/advisories/GHSA-8g2p-5pqh-5jmc
High https://github.com/advisories/GHSA-98g6-xh36-x2p7
The given project `Planfact.Infrastructure.Rules` has no vulnerable packages given the current sources.
...
As you can see, there are several projects vulnerable to CVE-2022-41064.
.NET Framework System.Data.SqlClient versions prior to 4.8.5 and Microsoft.Data.SqlClient versions prior to 1.1.4 and 2.0.0 prior to 2.1.2 is vulnerable to Information Disclosure Vulnerability.
To get rid of the issue, it's enough to upgrade the package:
dotnet add package System.Data.SqlClient -v 4.8.6
Now, how can developers prevent such situations? You already know the answer: automation!
After sharing my observations with the team, I created a merge request with a new GitLab pipeline that runs for every open merge request and master branch.
These are the changes in the .gitlab-ci.yml manifest:
stages:
- security
vulnarable-dependencies:
stage: security
image: mcr.microsoft.com/dotnet/sdk:6.0-bullseye-slim
before_script:
- dotnet restore
script:
- dotnet list package --vulnerable 2>&1 | tee vulnerable-packages.log
- >-
! grep -qiw "critical\|high\|moderate\|low" vulnerable-packages.log;
if [$? -ne 0]; then
echo "🚨 Found vulnarable packages";
exit 1
else
exit 0
fi
artifacts:
when: always
expire_in: 12h
paths:
- vulnerable-packages.log
only:
- master
- merge_requests
tags:
- docker
The pipeline will fail if any of the projects in the solution have vulnerable packages. The downloadable log file contains the list of vulnerabilities and their severity.
This way, the team is always aware of the state of the dependencies and can take action to fix them.
References:
Top comments (0)