Finding Surprises in Old Projects

I don’t know about you, but I have written a lot of code over the years. Some of this code is no longer running in production, some of it probably won’t even compile on my latest laptop. Some of it is still being used years after I thought it would have been long forgotten or abandoned.

As software ages, the code it depends on also ages. Over time lots of security issues can creep into our old code bases. This is where it is important to be aware of this issue and ensure that the code is perodically scanned for issues.

At work recently, I was tasked with scanning some old projects to assess the security of the code. From a static analysis perspective, we are using SonarCloud to scan our code for defects, code smells and other security issues.

Surprisingly, SonarCloud doesn’t do dependency scanning. There are ways to add plugins for SonarCube (self hosted etc) to add this missing feature.

But in the SaaS solution - No luck!

Please SonarCloud Support this soon!

.NET Core makes security scanning trivial

Recently in .NET core, microsoft has introduced a really nice built-in features to do this out of the box.

Open a command-line prompt in your project’s root folder and simply type

dotnet list package --vulnerable

Scanning Transitive Packages

It would be easy to believe that the job is done and that we are in the clear. But the above scan ONLY scanned the explicit nuget packages in our project. Each of our projects direct dependencies have dependencies of their own.

Microsoft are calling these ‘Transitive’ dependencies, and we have to add another switch to the command to include these.

dotnet list package --vulnerable --include-transitive

Read the Offical Blog to get a better understanding of the different switches and understanding the results.

Fixing the Issues

Now that you have scanned the project, there might be some issues to address. Thankfully, this is also fairly easy to fix. The scan of my recent open source project revealed a couple of High severity issues.

If we follow the links, we can read more about the particular issue and which versions have been fixed.

In order to fix the issue we need to update Newtonsoft.Json to version 13.0.1 (or greater). For older projects you might not want to jump to the latest version because of breaking changes (Except Newtonsoft of course). In some cases I have seen the fix being applied to older packages.

Once you have updated the nuget packages you should re-scan and see if the issues are no longer reporting.

What about the .NET Framework projects?

Wouldn’t you just love it if this was just built-in to NuGet CLI? I wouldn’t have thought that would have made more sense. Then the same tool could have just worked across all of .NET Core and Framework.

Instead we need to look elsewhere.

Why didn’t microsoft just put this inside NuGet.exe?

Having googled for awhile, the best free option I could find was the tool by Jeremy DependencyCheck. I downloaded it hoping it would just work out of the box. But let me save you some time. Especially if you don’t have Java setup on your local machine.

The following batch file will work beautfully if you have docker installed on your machine.

@echo off

set DC_VERSION="latest"
set DC_DIRECTORY=%USERPROFILE%OWASP-Dependency-Check
SET DC_PROJECT="dependency-check scan: %CD%"
set DATA_DIRECTORY="%DC_DIRECTORY%data"
set CACHE_DIRECTORY="%DC_DIRECTORY%datacache"

IF NOT EXIST %DATA_DIRECTORY% (
    echo Initially creating persistent directory: %DATA_DIRECTORY%
    mkdir %DATA_DIRECTORY%
)
IF NOT EXIST %CACHE_DIRECTORY% (
    echo Initially creating persistent directory: %CACHE_DIRECTORY%
    mkdir %CACHE_DIRECTORY%
)

rem Make sure we are using the latest version
docker pull owasp/dependency-check:%DC_VERSION%

docker run --rm ^
    --volume %CD%:/src ^
    --volume %DATA_DIRECTORY%:/usr/share/dependency-check/data ^
    --volume %CD%/odc-reports:/report ^
    owasp/dependency-check:%DC_VERSION% ^
    --scan /src ^
    --format "ALL" ^
    --project "%DC_PROJECT%" ^
    --out /report
    rem Use suppression like this: (where /src == %CD%)
    rem --suppression "/src/security/dependency-check-suppression.xml"

I saved the batch file into a script folder that is on my system path. This way I can run the tool anywhere from the command prompt.

The output is saved into a ./report relative to the scanned bin folder.

When did you last scan your dependencies?

image credit