Vulnerability remediation is the process of fixing flaws in software components that can compromise the security and integrity of an application. It’s a key step in the vulnerability management cycle, whose workflow includes first identifying security vulnerabilities, prioritizing them for remediation, and finally monitoring metrics to ensure the fix was successful.According to the US National Vulnerability Database (NVD), the number of Common Vulnerabilities and Exploits (CVEs, or simply vulnerabilities) has tripled since 2016. As a key part of the software supply chain, open source libraries with vulnerabilities have been receiving growing attention from hackers over the past few years, who exploit these weak spots.As a result, secure supply chain efforts have long focused on vulnerability remediation in order to help reduce the risk of breaches, denial of service attacks, and other interruptions in operations. Simply put, organizations that ignore vulnerabilities in their software run the risk of being hacked. Similarly, software vendors that prioritize features over remediating vulnerabilities expose their customers to increased risk of being hacked. Unfortunately, multiple reports over time consistently find that ~80% of codebases are never updated once they’re created for fear of breaking the build.

Vulnerability Scoring

CVEs that are publicly disclosed are typically scored using a Common Vulnerability Scoring System (CVSS) in order to help organizations prioritize remediation. For example, open source software libraries and packages commonly have their CVEs tracked and scored by one or more CVVS. While each CVVS may label their “vulnerability severity” levels differently, the following chart represents the current CVSS standard:

Severity	CVSS v3 Rating
Critical	9.0 – 10.0
High	7.0 – 8.9
Medium	4.0 – 6.9
Low	0.1 – 3.9
None	0

Ratings are assigned based on a number of factors, including:

• Attack Vector (AV)
• Attack Complexity (AC)
• Privileges Required (PR)
• User Interaction (UI)
• Scope (S)
• Confidentiality (C)
• Integrity (I)
• Availability (A)

Note that severity levels are not risk scores. Rather, they provide an indication of relative importance of a vulnerability, which can help organizations prioritize assessment and timeframe for remediation. Each vulnerability will need to be investigated separately to determine its actual risk to the organization.

What is a Vulnerability Assessment?

Vulnerability assessment is the process of identifying, quantifying, and prioritizing the vulnerabilities in a codebase. These kinds of risk assessments can be automated using a variety of software, such as Software Composition Analysis (SCA) vulnerability scanners which will:

• Identify the components of a codebase.
• Preform real-time vulnerability scanning for each component by checking various online resources, (such as the NVD) to see if any of them are affected by a vulnerability.
• Notifications should be automatically sent to the codebase owner of any new vulnerabilities, while minimizing false positives.
• Provide vulnerability data, such as threat intelligence, security risks and the severity level of each vulnerability, all of which can aid in vulnerability prioritization for remediation.
• Optionally suggest more recent versions of the component that resolve the CVE.

By automating vulnerability assessments organizations can significantly reduce the Mean Time To Detection (MTTD), which is the average length of time it takes to discover vulnerabilities after they are publicly reported.

How Do You Resolve Vulnerabilities?

A vulnerability management program should be put in place to address security flaws as and when they crop up. Identified vulnerabilities can be dealt with using any one of a number of methods, including:

• Custom Code – developers may choose to manually patch an open source library rather than wait for the maintainer to provide an update or patch in order to speed time to remediation for critical vulnerabilities that pose an exceptional threat to the organization.
• Patch Management – open source maintainers may choose to release a patch for their code. Patching can speed time to resolution rather than waiting for a full release of a newer version of the library.
• Upgrading – vulnerabilities are typically addressed in newer versions of a library. By upgrading, developers can resolve multiple vulnerabilities at once.

The vulnerability remediation method chosen will largely depend on the organization’s standard processes, as well as the risk profile of the vulnerability in question.

Note that vulnerability remediation differs from vulnerability mitigation. The former eliminates the vulnerability, while the latter attempts to improve cybersecurity by limiting the impact of anyone attempting to exploit the vulnerability. Security team vulnerability mitigation strategies include:

• Reducing the attack surface of an application/system on which the vulnerable application is deployed.
• Implementing controls and tools to monitor and alert the organization when the application is functioning abnormally, which may signal an attack.
• Implementing intrusion detection/firewalls, as well as prevention tools to limit downtime as a result of the damage an attacker may cause.

How Quickly Should Vulnerabilities Be Remediated?

Simply put, the more high-risk a vulnerability, the more accelerated should be the remediation effort. Unfortunately, as remediation teams well understand, this is easier said than done. Patches and/or library updates are released 9 days after discovery of a vulnerability, on average, but according to various research studies Mean Time To Resolution (MTTR) can range from 60 to 150 days before application security is deemed good enough to be redeployed in production, depending on the severity of the vulnerability.

The problem lies in the fact that vulnerability remediation is largely a manual process. Remediation steps involve:

1. Investigation – depending on how a library has been implemented, an application may or may not be subject to a vulnerability. Developers need to dedicate time to performing code reviews and testing in order to determine the impact.
2. Rebuild – if a patch or update is applied to the affected library, the application must be rebuilt. Complications can arise when upgrading a library results in conflicts with other libraries, leading to dependency hell. Additionally, building the new library versions from source code for all deployment platforms can be problematic, especially if the build process has significantly changed.
3. Retest – this task often includes manual testing in addition to automated testing like penetration testing.
4. Redeploy – organizations that haven’t fully automated their deployment system typically have a deployment process that may involve passing a governance board, scheduling a deployment time, or even waiting for the next deployment window if their production system is locked down.

Some solutions, such as the ActiveState Platform can help automate and/or avoid significant portions of the remediation process. For example, the ActiveState Platform’s catalog shows you which versions of a library are secure and which are vulnerable, allowing you to choose a secure version. The Platform will then resolve all conflicts and automatically rebuild the runtime environment in just a ew minutes. In this way, you can better perform risk management while significantly reducing MTTR. Learn more.

Related Reads:

Data Sheet: Speeding Open Source Vulnerability Remediation

How to remediate your open source vulnerabilities quicker