This quick post is about how you can use GitHub and the OSS Index to scan your project’s NuGet packages for vulnerabilities – a good example of how perform your application security early on in the application life cycle (also known as ‘shift left‘)
So here’s a problem
You’re working on a .NET Core application, and obviously using some of the libraries provided by Microsoft. Behind the scenes, Microsoft’s security teams have found a security hole in one of these libraries and issued a patched NuGet package.
You wouldn’t always immediately update NuGet packages everytime there’s an upgrade, but you definitely would upgrade if you knew there was a vulnerability in one of your dependencies.
How are you going to know that Microsoft have found and fixed a vulnerability, so you can prioritise an application upgrade?
GitHub is helping to solve this problem
A little while back I got a couple of notifications from GitHub that one of my projects refers to a Microsoft NuGet package – Microsoft.AspNetCore.All, version 2.0.5 – and the library contains a potential security hazard.
I was pretty surprised – I already use the Audit.NET extension within Visual Studio 2017 to audit my NuGet packages against the OSS index. This extension triggers an error at design time in Visual Studio if it detects that my project uses a package that has a known vulnerability.
If you haven’t checked out the Sonatype OSS index, I really encourage you to do so – it has a bunch of useful tools and information to identify if there are known security vulnerabilities lurking in your open source dependencies.
GitHub helpfully provided me with a bit more detail on what the problem was – my project used version 2.0.5 of the Microsoft.AspNetCore.All NuGet package, and this version is vulnerable to a couple of forms of attack (denial of service and excess consumption of resources).
This makes me extremely glad to be using GitHub to store my code, as it directly highlights to me that there’s a potential hazard lurking in the project dependencies. Now I can do something about it – like upgrade my libraries to the patched version v2.0.9, and push the changes to GitHub.
And after pushing the updated version, the security alerts disappear.
I like to ‘shift left‘ as much as possible with my application security testing – it’s unambiguously better to carry out security testing as early as possible in the application lift cycle. Having an security extra test automatically built into my GitHub source code repository is a great addition to the security testing process.