When developing software, security can sometimes be an afterthought rather than being thought about upfront and baked into the development process. Not only can this lead to embarrassing exposures, but it can also lead to a lot of remediation effort from the development team at the end of a project (if you have an InfoSec team that requires signoff before an application goes live), whilst also causing a lot of unplanned reactive work.
Thankfully there are tools available that can help improve your chances of deploying secure applications that can be included as part of your CI/CD pipeline to cover different types of testing including Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST), and Run-time Application Security Protection (RASP).
Recently Whitesource was rolled out by a client of mine to complement a number of other security tools in place such as CheckMarx to help build secure software. Whitesource helps by scanning Open Source Software (OSS) packages used within your application – this includes npm and NuGet packages.
.NET relies heavily on NuGet for hosting reusable components/libraries that can be imported and reused in a project. Often we as developers will try to reuse these components so that we do not reinvent the wheel and to speed up development, but what we don’t necessarily think about is how secure these packages are – even those from reputable companies such as Microsoft can have issues in them. This is where Whitesource can be very handy in reporting known CSV issues with OSS packages.
Executing Whitesource on our project for the first time via Azure DevOps Pipelines reported three errors. What was interesting was that none of the packages listed were direct references in any of our projects. This is where the hunt for the transitive packages began.
There are a couple of ways you can find transitive dependencies (unfortunately I couldn’t find a nice search via Visual Studio) – using the dotnet core cli and by looking in the project.assets.json. The approach I took was use the dotnet core cli first as this enabled me to narrow down the project with the dependency. The below command can be executed in the solution directory:
dotnet list package --include-transitive
After I found the project, I then used the project.assets.json file in the obj directory of the project to find the dependencies.
There is also another command that can be used to highlight vulnerable packages
dotnet list package --vulnerable --include-transitive
As of 02/March/2021, GitHub now has the ability to show CSV issues with NuGet packages – please see here for more information