We all know technical debt hurts, and we usually lean on tools to help us manage this pain. For open source software, there are two market leaders in the Azure DevOps world, Black Duck, and WhiteSource Bolt who can help us address technical debt and reduce the risks of vulnerabilities. We are going to focus on WhiteSource Bolt today, as it’s free to use.
Today, it is estimated that 98% of applications use open source components. 70-80% of these applications are using open source components with known exploits. Equifax, for example, was hacked using a known exploit published 6 months earlier. WhiteSource Bolt can inventory and identify known vulnerabilities in your libraries
Adding WhiteSource Bolt to our CI process
First, we need to browse to Azure DevOps marketplace, and find the “WhiteSource Bolt” task. You will need to be an Azure DevOps administrator to add this task to your Azure DevOps instance.

Next we add the YAML to run WhiteSource Bolt – which is about as simple as it gets, we just need “-task WhiteSource Bolt@19”. Here is the YAML in context:

Analyzing the results
Running the pipeline, we can see a new task appears in the build summary.

Looking at the results from the initial run, we see some interesting results:

- We have an overall vulnerability score of “medium”. Not great, but not terrible either
- There are 2 libraries with medium vulnerabilities, triggered by the “JQuery 3.3.1” library.
- Both of these libraries have very old vulnerabilities – older than 90 days – we probably should have upgraded this library some time ago
- The recommendation for these vulnerabilities is to update to “JQuery 3.4.0” or higher
License risks indicate OSS licenses that are incompatible with each other. We have one medium license risk in “Microsoft Public”, the rest are all low. We had to dive into why the Microsoft Public library is considered medium. It turns out this licence is more restrictive that other licenses, so you should be careful when using public software integrated with this license. The actual files triggering this are Key Vault and Authentication NuGet packages, which we can’t remove, we really do need them.

Finally, we are shown an inventory of all libraries found and the associated license – if known. This is useful to understand exactly what WhiteSource Bolt found in source control – sometimes you’ll find a library you thought had been removed or a library you didn’t know was still in the source control.

Making the fixes
To fix the JQuery libraries, we have to upgrade the client side libraries. As we created this Website using the ASP.NET CORE 2.2 template, it doesn’t seem to have an easy way to upgrade. To solve this, we are going to use the Client Side Library feature to replace the existing files. Right clicking on our website, we click “Add” in the menu, and then “Client-Side Library”

In the popup that appears, we start to search for “JQuery”, selecting the version 3.4.1, ensuring the target location is correct, and pressing the install button.

This adds a new “libman.json” file to our project, where you can see it references the new library we have added.

Once we have upgraded our libraries, we commit our code and review the pull request build, noting our WhiteSource Bolt build report shows a lot more green and we have a secure set of libraries. This doesn’t solve our Microsoft Public license issue, but we are OK with it and accept the risk.

Wrap-up
Many DevSecOps tools are easier to use than many realize, today we reviewed how easy it is to maintain our open source libraries for vulnerabilities and licenses. As DevOps spreads, these tools help provide automated protection against vulnerabilities, creating a safer world. For a small investment, you can ensure that your project is not the next Equifax. Note that WhiteSource Bolt is the “light” version, the full version allows you to set white and black lists, and create gates for many different rules – for example, to only allow certain packages or licenses to be added to projects.

Note: I am not an employee of WhiteSource and this post was not sponsored by WhiteSource, I am merely trying to show how easy and valuable the product is for DevOps pipelines.
References
- WhiteSource Bolt: https://marketplace.visualstudio.com/items?itemName=whitesource.ws-bolt
- ML License: https://web.archive.org/web/20150901065118/https://stackoverflow.com/questions/1424307/how-does-ms-pl-license-work
- Updating client side libraries: https://medium.com/@scottkuhl/updating-your-javascript-libraries-in-asp-net-core-2-2-3c2d985a491e
- Licensing scoring: https://whitesource.atlassian.net/wiki/spaces/WD/pages/483786970/Risk+Score+Attribution
Hi, thanks for your post!
We’re looking at implementing WhiteSource Bolt against a .Net 5 web app but it’s not picking up any of our libraries added via libman.json
Looking at the Bolt documentation, it requires Yarn, NPM, or Bower to work with client-side JS libs…
Do you have any of those configured in your source for this article?
TIA
LikeLike
I don’t have any of those configured. I only used libman.json to configure the upgrades on the existing frameworks. Saying that, setting up NPM or Bower isn’t complicated, at least just for the scanning (I have no experience with yarn).
At the same time, I didn’t need any of those things. I recommend you try with a new/smaller project and see if you get the same results – perhaps there is a complexity in your current project that means that something isn’t being picked up?
Sorry I don’t have more direct advice. Whitesource Bolt just worked for me – which is one of the reasons I wrote about…
LikeLike
No worries, thanks for confirming!
LikeLike