Performing Vulnerability Assessment In Azure DevOps

DevOps is a collaboration between the development and the operations teams. This collaboration has led to some fantastic benefits for organizations. DevOps has allowed people and organizations to ship releases faster to market. Applications or software products are released more often as they meet delivery deadlines.

 

But often, one aspect remains missing here: security. While developing web applications, we need to look into all possible vulnerabilities or loopholes present in the application. These can be present due to framework flaws or any third-party library used to build the application. We simply cannot afford to let our application go into the production environment without fixing the vulnerabilities. It can result in loss of data or business for our customers or end-users.

 

What is Vulnerability Assessment?

 

In layman’s terms, a vulnerability assessment is a way to find potential loopholes in the application, which can cause harm to your application and its business users.

 

Vulnerability assessments vary depending on the type of vulnerability in question. In this article, we will discuss how to integrate vulnerability assessments in the build pipeline to scan for any known vulnerabilities in the open-source libraries used in our application. Tools like SonarQube, SourceClear, and WhiteSource Bolt can help us achieve this objective.

 

For this article, we are using WhiteSource Bolt as it not only helps us to find vulnerable open source components but also provides remedies for the same along with a detailed report of the assessment. WhiteSource Bolt is also completely free, which makes it more attractive to use.

 

If you know how to install WhiteSource Bolt for Azure through the marketplace or already have it installed, skip to step 6.

 

Step 1

 

Login to Azure DevOps and go into your desired organization and project. As mentioned before, we will be using WhiteSource Bolt to conduct this vulnerability assessment. To access the application, if you don’t already have it, go to the marketplace to get the extension. To do so, click on “Browse Marketplace”:

 

 

Step 2

 

Once you land in the marketplace, type “WhiteSource Bolt” in the search box and click on the application. We can see there are two other options available from WhiteSource. These can be used depending on your requirements. For this article, we are going to work with WhiteSource Bolt.

 

 

Upon clicking on the highlighted region, you will be redirected to a new screen. Here, you will find the extension’s description along with some supported links and reviews. You need to click on Get it free to start the process of installing the extension.

 

Step 3

 

In this step, you would just need to ensure whether the selected organization in the drop-down box highlighted in the attached image is the right organization or not. For this article, our organization is named “TestWhiteSource.” Click on the “Install” button as highlighted in the attached image.

 

 

Step 4

 

Once the installation is complete, you can go back to your organization. Now, go to the project for which you want to do an assessment, then click on the repository. Here in the Azure repo, I have created a repository with an ASP.NET Core web application whose solution files are visible in the image.

 

 

Step 5

 

Before we dive into building the pipeline, we need to fill in a small form to use the “WhiteSource Bolt” extension. To do so, click on Pipelines, then on the WhiteSource Bolt button. Fill out the form and click on Get Started to use the extension in your pipelines.

 

 

Step 6

 

Now that we have this extension installed and configured, let’s start building the build pipeline for our application. To do so, click on Pipelines again. Then, click on the Create Pipeline button to begin creating your build pipeline.

 

The simplest way to create a pipeline in Azure DevOps is by using the classic editor. This is a personal preference – you can also use “YAML” scripts to create a build and deployment pipeline.  

 

Once you do this, you will be redirected to this screen,

 

 

Here, you would need to select the SCM which you are using for your project. In my case, I’m using Azure Repos Git. Then, select the appropriate Team project (in our case, it’s called WebApp) and the concerned repository. The default branch for this project is master and has been selected. Finally, after you have filled in all the necessary information required, click on continue.

 

Step 7

 

As we are creating a pipeline to build an ASP.NET Core application, we need to select the right template. Once you select the template, click on apply.

 

 

Step 8

 

The screen you are redirected to already has some tasks pre-populated in the agent job. Now, add the “WhiteSource Bolt” task. To do so, we would need to select that and click on the + symbol, type “WhiteSource Bolt” in the Search box, and then click on Add.

 

 

Once you have added WhiteSource Bolt, place it just after the restore task. This is actually a personal choice – you can set the task anywhere in the pipeline after all the nuget packages are restored for the project. Save this pipeline.

 

Step 9

 

Now, go to Pipelines again and click on Run pipeline to start the build pipeline, which we have created in the previous steps.

 

 

You will be redirected to a new screen where you can see the status of your build pipeline along with some more information like the total time taken by the build pipeline to complete and whether your pipeline has a build agent or not. Once the build pipeline is completed, you will see a green tick in the header. Click on WhiteSource Bolt Build Report to see the assessment findings shown in the attached image below,

 

 

You can scroll and see the complete report. Along with vulnerable libraries, you will know the severity distribution as well as the License and Risk compliance report.

 

Conclusion

 

Vulnerabilities are a concern for every organization and individual, and it is a known fact that a lot of the time, our applications have vulnerabilities. These can be caused due to a compromised server or the use of a vulnerable third-party library. We can avoid these vulnerabilities from creeping into our application by incorporating vulnerability assessment as part of our build pipelines.