Acing your open source vulnerability management – step by step 

In this blog post, we will first look at the different steps of vulnerability management and then discuss how Debricked can manage vulnerabilities in open source components.

Why vulnerability management 

Attackers can exploit vulnerabilities to gain unauthorized access to systems, steal sensitive data, or cause damage to an organization’s reputation. For this reason, vulnerability management is a critical component of any software development lifecycle. Simply put, vulnerability management is identifying and fixing vulnerabilities in systems, applications, networks, and databases. But we will soon expand this definition. 

Open source software is becoming increasingly popular and typically represents a majority of a code base. While open source software offers numerous benefits, including cost savings, flexibility, and faster time-to-market, it also introduces security risks. Vulnerabilities in open source components can affect the applications that use them. Thus, the importance of open source vulnerability management has grown in tandem with the increasing popularity of open source software.

Steps in vulnerability management 

Vulnerability management consists of a set of key steps. Depending on who you ask, these steps may be named a bit differently, but the order and activities involved are similar. In this context, we will refer to the vulnerability management steps defined by Gartner, namely Assess, Prioritize, Act, Re-assess, and Improve. 

Assess 

The first step in vulnerability management is to assess the system for vulnerabilities. Parts of this can be done manually, such as through penetration testing, but it is often more efficient to use automated tools that can scan for vulnerabilities. This includes scanning the network, operating system, applications, databases, cloud services, and web services. 

To perform a useful scan, it is important to have an asset inventory and an understanding of the importance of the different assets. Knowing the assets’ importance will help identify what needs to be scanned and prioritize the results. This leads us to the next step.

Prioritize 

Once vulnerabilities have been identified, the next step is to prioritize them. The prioritization should be based on their severity and potential impact on the system. This is typically done by assigning a severity score to each vulnerability based on a risk-based assessment of the likelihood of exploitation and potential impact on the system.  

Determining the severity requires in-depth information about the vulnerability’s nature and a detailed understanding of the vulnerable system, application, infrastructure, and configuration.  

In addition to this, prioritization can also consider the difficulty of remediation. For example, a low-risk vulnerability can be prioritized over a higher-risk one if it is quick and easy to remediate.  

Act 

When vulnerabilities have been prioritized, it is time to act on them. Acting on a vulnerability will intuitively mean remediating it. This can involve updating vulnerable software, changing vulnerable configurations, removing the part of the system that is vulnerable, and so on.  

In some cases, remediation might be too difficult, depending on third parties, or significantly impact an application, so it has to be postponed to later. In this case, mitigation is an alternative solution. When mitigating a vulnerability, it is still there but can no longer be exploited in an attack. Mitigation can take the form of firewall settings or filtering out exploitation attempts inside the application.  

For some vulnerabilities, the impact and/or the likelihood of exploitation is very low. Then, the effort or cost of remediating or mitigating it may not justify the reduced risk that such a fix would provide. In this case, the last alternative is to accept the risk induced by the vulnerability.

Re-assess

After remediating or mitigating a vulnerability, verifying that it is no longer exploitable is important. This can be done by conducting a manual test or re-scanning. In a way, this step is like the assessment step all over again, but with a different goal. Rather than scanning for new and unknown vulnerabilities, the focus is on using one or more known fixed vulnerabilities as a starting point and verifying that they no longer exist.  

Thus, this step can be much less extensive and more targeted, using the same tools and scanners used when the vulnerabilities were initially identified. At the same time, it’s important to think about the remediated or mitigated vulnerabilities and consider if there are other related ways of exploiting the underlying problem. A scanner may have found one instance, but there could be more elusive ways of exploiting similar weaknesses not identified during the initial assessment.

Improve

The final step is to use the results and the learnings from the previous steps to improve the security of the system or application. Why were there vulnerabilities in the first place? What actions can we take to make sure that similar vulnerabilities will not be found in future assessments? Developer training can be part of this step. 

Using vulnerability-related metrics can also help improve security and to decide on actions to take in the organization. If the number of vulnerabilities identified in assessments increases, more vulnerabilities are being introduced than fixed. Such circumstances must be analyzed for the root cause. Other metrics to look for are the time to remediate, the number of accepted risks, and the average risk scores assigned to the identified vulnerabilities.

Implementation notes

Vulnerability management is a never-ending process. When the final step has been reached, it is time to iterate back to the first step and conduct a new assessment. Hopefully, as time goes, fewer vulnerabilities will be found, the time to fix them will decrease, their severity rating will decrease on average, and the system or application will be more secure. 

In reality, the vulnerability management steps often exist all at once and in parallel. An organization often has several different scanners, each focusing on certain parts of the system and certain types of vulnerabilities. One scanner can be used for network vulnerabilities, another for configuration problems, a third for source code scanning, and another for third-party dependency scanning using software composition analysis. Some scanners are run periodically, with different time intervals, while others are run more continuously.

When the scan, i.e., the assessment, is finished for one scanner, the vulnerabilities found are moved to the prioritization step. Then, before these vulnerabilities have been remediated, another scan will find other vulnerabilities. Thus, this can be seen as several parallel processes, each in a certain stage. This complexity underlines the need for well-documented and established vulnerability management processes.

PDCA for vulnerability management

The steps for vulnerability management enumerate what you should do and when in order to identify and fix vulnerabilities. The PDCA cycle can be beneficial to oversee and improve the vulnerability management process. 

Also known as the Deming cycle, the PDCA cycle is a general management methodology. It consists of four stages, and if applied to vulnerability management, they can be summarized as follows. 

• Plan – Establish the vulnerability management program and determine goals and methods. 
• Do – implement the program. 
• Check – Monitor, review, and audit the performance of the program.  
• Act – Take actions to improve things identified in the check stage. 

Maintaining a successful vulnerability management program includes letting the last stage iterate back to the first. This will allow ongoing improvement by continuously updating goals and methods and assessing how the updates affect the program.

Open source vulnerability management with Debricked 

Debricked provides a Software Composition Analysis (SCA) tool that will help you throughout all the steps in vulnerability management for open source dependencies. Let us revisit the steps of vulnerability management and see how Debricked can help you in each of them. 

Assess with Debricked 

For assessing vulnerabilities, Debricked will help find all your dependencies and match them with known vulnerabilities. The dependencies you have directly included in your application and the transitive dependencies will be identified and scanned.  

There are several ways in which Debricked can perform a scan. The most common way to use the tool is to integrate your repositories. With just a few clicks, this is a very simple process in which you create an account and integrate it with your source code manager, CI/CD platform, or similar, such as e.g. GitHub, GitLab, Bitbucket, Azure DevOps, Travis, Jenkins, etc. Our documentation gives detailed information on how to use Debricked with these tools. Debricked will automatically look for dependency files, lock files, and/or SBOM files within your repository to identify the dependencies.  

If you do not want to integrate your repository or your CI/CD pipeline with Debricked, it is also possible to manually upload dependency files or SBOMs, and these will be scanned, presenting you with a list of all vulnerabilities in the identified dependencies. 

Prioritize with Debricked

Once a scan is complete and vulnerabilities have been found, Debricked will provide information for understanding and prioritizing them. For each vulnerability, you will get the base CVSS score, indicating the general severity of the vulnerability.  

Using a tree structure, the UI will also show where the dependency is located in the software.

Often, the vulnerability will be in a transitive dependency that was included by another dependency. Then, this tree view will give the context of the vulnerable dependency so that you can better understand how the software uses it. With a general description of the vulnerability and links to further information, you will have the necessary information to assess if and to which extent your software or application is vulnerable. 

You can mark a vulnerability as unaffecting or that your repository is vulnerable, calling for action to remediate or mitigate. It is also possible to snooze the vulnerability so that you will not be alerted for a set period.

To track the triage and prioritization, adding comments to each vulnerability is possible. 

Act with Debricked 

To act on a vulnerability in an open source dependency, the typical remediation is to update to a new component. Debricked provides you with different pieces of information to this end. First, the general information on the vulnerability will often include the vulnerable versions. Second, more specific information is given by the “suggested fix,” which will show you what version to update and in which dependency file(s) the updates need to be applied.  

Sometimes it is enough to update the affected dependency, but in some cases, you should instead update the dependency you included as a direct dependency. This is because the new version might not be compatible with how the downstream dependency uses it. Such a situation will cause so-called breaking changes, which we wish to avoid. Debricked will handle this for you and analyze which new version of the direct dependency is required for new versions to propagate down to the vulnerable transitive dependency. The previously vulnerable dependency will then be patched with no breaking changes in the dependency chain. This feature is currently available for JavaScript, Java, and Go, but more languages soon be supported. 

Debricked can automatically generate a pull request for JavaScript to update the dependency to a safe version. In this case, no manual work is needed, and the dependency file(s) will be updated when merging the pull request. 

Recall that prioritization should also include the difficulty of remediation. To this end, Debricked supports bulk update pull requests. This means that with the click of a button, Debricked will generate a pull request that fixes all vulnerabilities without risk of breaking changes.

There is no reason to triage and analyze vulnerabilities if we can remediate them with basically no effort. This will only leave the vulnerabilities that require severity assessment, freeing up time for the development organization. 

For more information on Debricked pull requests, see our documentation. Information on the language support for different features is also tracked in the documentation. 

Re-assess with Debricked 

Verifying that a vulnerability has been remediated and is no longer present in your software is automatic with Debricked. Since a scan is conducted in the CI/CD and triggered (by default) on a push to the repository, a new patched branch will also trigger a scan. You will be able to immediately verify that the new branch does not have the vulnerabilities. 

Improve with Debricked 

Fixing a vulnerability is one thing, but it would be best if it were not there in the first place. This is, unfortunately, not really possible. If you have software, you have vulnerabilities. So, the second best option would be to lower the probability of having vulnerabilities. This means choosing open source software with strong community support, good development practices, and efficient handling and patching of vulnerabilities in the software. To find this software, you can use Debricked’s Open Source Select database.

This database has metrics for millions of open source packages. The metrics can be used to understand the popularity of a package, data regarding the contributors, and security. This will help you pick an open source package that has a higher chance of being of high quality. 

Debricked also helps you assess how you have handled vulnerabilities historically. In the overview, you will see how many vulnerabilities you have and how this has developed over time. If you fix a vulnerability or mark it as unaffected, it means you have handled it, and it will be removed from the chart.  

Conclusion 

Vulnerability management consists of several steps and includes handling vulnerabilities on your network, in your in-house developed software, and third-party open source components. For open source components, Debricked will help you through all steps in the process, from assessing and prioritizing vulnerabilities to remediating them, re-assessing and verifying the fixes, and improving your vulnerability management process.

Sign up for a free account and start your open source vulnerability management work today to try it out.