Vulnerability Remediation: A Practical Guide
Table of Contents
What is vulnerability remediation?
To stay ahead of malicious attacks, developers and security teams must have a way to identify, prioritize, fix, and monitor vulnerabilities, a process known as vulnerability remediation.
When it comes to detection, organizations can use a variety of application security testing (AST) tools to identify vulnerabilities in software applications and other systems. For example, software composition analysis (SCA) tools verify the integrity of open source software components by checking them against vulnerability databases, security advisories, or issue trackers within the software development environment to ensure they do not contain vulnerabilities.
When an AST tool discovers an issue, the team then blocks or neutralizes the vulnerability, a step known as remediation. Remediation can be as straightforward as applying a software patch or as difficult as replacing a group of physical servers or hardware appliances.
The goal of remediation is to patch or fix the vulnerability before it becomes a threat to security, which can be complex to achieve at scale and on a continuous basis In a DevSecOps organization, development teams, system owners, security teams, and operations staff must work together to build an effective vulnerability remediation process.
The key difference between remediation and mitigation is that remediation fixes vulnerabilities, while mitigation addresses the resulting security threats that vulnerabilities pose, without necessarily fixing the underlying vulnerability.
While remediation is the more thorough and comprehensive solution, there are some cases in which it may be neither necessary nor possible:
- Sometimes, organizations cannot remediate a vulnerability for technical reasons. For example, some hardware appliances may not support software upgrades or patching. This is common for connected medical devices.
- In other cases, there may be organizational resistance to remediation. Organizations that do not practice a DevSecOps model may face disagreement when trying to remediate vulnerabilities. Development teams might claim they do not have time to implement remediation, while customer-facing teams might be concerned by the downtime involved, or disruption to customer activity.
- When organizations apply priority scoring to vulnerability management, they may choose to mitigate rather than remediate lower risk vulnerabilities that pose less of a threat. This allows them to prioritize the remediation of more serious threats, or free up developers’ time to focus on their main objective of building applications.
In these situations, mitigation offers an alternative until remediation can or should be implemented. Mitigation decreases the possibility that a vulnerability will be exploited, and enables an organization to buy time while it waits for a preferable opportunity to remediate a vulnerability. For example, the organization may choose to deploy a web application firewall (WAF) that can detect and block many application-layer attacks, even if the underlying application remains vulnerable.
When choosing whether to remediate or mitigate, it’s important to remember that mitigation will reduce the threat posed by vulnerabilities, but won’t eradicate it completely while the vulnerability remains. Remediation goes further and wherever possible, should be the preferred solution. That’s because ultimately, dealing with the root cause by remediating a security issue is better than mitigating the resulting threat.
The vulnerability remediation process
Vulnerability detection, prioritization and remediation tools are employed to find, analyze, and fix vulnerabilities and eradicate threats posed to your source code. Together, they perform a vulnerability remediation process that involves the following four steps:
1. Vulnerability detection
This involves identifying any known flaws in coding or system configurations, which an attacker can exploit. You can detect vulnerabilities through tests and scans. It is crucial to understand which assets or systems are exposed.
An example of a known software vulnerability is insufficient access control configuration, such as single-factor authentication. Less stringent authentication makes it easier for an unauthorized user to gain access and launch, for instance, a man-in-the-middle attack.
Ideally, you should use a DevSecOps approach to ensure that vulnerability scans are carried out throughout the software development lifecycle (SDLC). At this stage, you can also leverage tools such as software composition analysis (SCA), static application security testing (SAST), or dynamic application security testing (DAST).
Not all vulnerabilities require fixing. For instance, if you discover a vulnerability in a function that is not actually invoked by your product’s code, it cannot be exploited and there is no need for remediation. Another example is a vulnerability that is not severe and the impact of exploitation is low.
2. Prioritization
This involves identifying the risks posed by vulnerabilities and determining which issues are more urgent or require more attention. Organizations typically face too many vulnerabilities to manage quickly, and security teams are limited in staff. That’s why prioritizing vulnerability remediation is important.
Risks can be prioritized based on system configurations, the likelihood of a potential exploit, the business impact of an actual incident, and any existing security controls. You should insulate your most critical assets.
If the DevSecOps team identifies that a crucial system is at risk, you can prioritize remediation of the relevant vulnerability and distribute the workload across the team. This helps you avoid disrupting the development lifecycle.
To manage open-source vulnerabilities, it is recommended to use a tool that aggregates the information from the various repositories that list known vulnerabilities. This will help you filter security alerts and save time.
You can also use advanced SCA tools to identify whether your code is affected by a vulnerable component. Remember that the presence of a vulnerability does not always entail a significant risk. The advanced way to identify which vulnerabilities may effect your code, The most advanced tools offer effective usage analysis,is by using solutions which provides insight into the specific functionalities of open source components that actually affect your code.
3. Remediation
Remediation fixes vulnerabilities as quickly as possible. It may involve applying patches, removing or disabling vulnerable components, updating your system or its configuration, or blocking certain actions.
For proprietary code, you need to identify the root cause of a vulnerability in order to fix it. You can do this with SAST. You may have to combine automated and manual remediation processes, and you may add additional security measures to harden your perimeter. You should test the remediation efforts in a secure, isolated environment, such as a sandbox, rather than work entirely within the production environment.
For open source vulnerabilities, you need to consider the decentralization and collaborative nature of the open source community, which often publishes fixes across multiple platforms, so it may be difficult to find all the relevant support in one place.
One of the most reliable risk mitigation strategies is to keep your open source components continuously patched to avoid being exposed to known vulnerabilities. The best way to maintain this strategy is with automated remediation tools, which will find fixes and alert you when new fixes are published. Advanced SCA tools can recommend the best fix if there are more than one.
Updating a single source file is not an adequate solution for more sophisticated threats, so you may need to update the entire component. In some cases, new versions may not be compatible with your other components, so you will have to rely on changing your system configurations and blocking the execution of vulnerable actions in your components.
4. Continuous monitoring
You should continuously monitor your code (and open source inventory) for newly discovered vulnerabilities. You can use automated tools to provide real-time alerts and allow you to maintain an ongoing vulnerability remediation process.
Effective monitoring tools should prioritize vulnerabilities based on context, which is important to avoid inundating the DevSecOps team with low-priority alerts. In a continuous remediation loop, this fourth step can also be considered the first step of the next cycle.
Which tools can help with vulnerability remediation?
There are a variety of tools you can use to find and fix vulnerabilities. Vulnerability scanners enable you to find vulnerabilities, while security testing enables you to analyze and prioritize them. So, deploying a combination of these tools safeguards you thoroughly.
A vulnerability scanner can operate at several levels. It can scan:
- An entire host to discover the operating system, the software installed on the host, its current configuration, user accounts, and open ports. This can reveal security weaknesses and provide suggestions for hardening the host.
- An entire container or application to identify vulnerabilities in any component within the application.
- Specific libraries to identify known vulnerabilities or other security flaws.
SCA, static application security testing (SAST), and dynamic application security testing (DAST) tools all perform vulnerability scanning as part of their feature set. Let’s look at these tools in more detail.
Software composition analysis
SCA is a code scanning tool that helps identify issues in open source and third-party components within your applications.
SCA works by analyzing source code and detecting risks from third-party code and from sources. It also contributes to building a package or software bill of materials (SBOM). The SBOM lists the packages used to develop your applications. SCA then discovers any security vulnerabilities that were introduced via those packages.
The most advanced SCA tools can also assist with prioritization. For example, they can provide information on whether a vulnerability is actually exploitable by attackers, and is therefore a top-priority fix.
SCA is best leveraged from the earliest stages of development, at the far left of the software development lifecycle (SDLC). This makes it possible to discover open source vulnerabilities and remediate them during early development, which is far easier and less costly than if they are discovered later on.
Static application security testing
Static analysis is a mature technique for identifying security and quality issues in custom source code. Integrating static analysis into the continuous integration/continuous development pipeline can help identify vulnerabilities in the initial stages of the software development process, using a white box testing approach.
SAST automatically looks for vulnerabilities within the application byte code, source code, or binaries, line-by-line. This makes sure that security vulnerabilities, like those featured in the CWE Top 25 and OWASP Top 10, are not present in source code.
Advanced SAST can run within an integrated development environment, providing feedback to developers while they are coding. SAST tools can also operate after developers check code into a repository, or during the build process.
The advantage of the SAST approach is that it doesn’t need a running system when performing code security analysis.
Dynamic application security testing (DAST)
DAST tools interact with applications while they are running, trying to discover vulnerabilities. Applications must run on a virtual machine, container, or web server, either in a testing or production environment.
DAST tools proxy a web application’s communications, inserting themselves between the server (back end) and the browser (front end). They examine requests and responses to understand your application and how it is used. DAST tools perform crawling to identify all the pages of a website or web application, including authentication and authorization steps. They then perform fuzzing and dynamic analysis to uncover security flaws.
DAST tools can provide valuable feedback for developers, and demonstrate that security issues are actually exploitable. However, because they are used later in the SDLC, during testing or production stages, the cost of remediating vulnerabilities discovered via DAST will be higher.
Vulnerability remediation with Mend.io
With Mend.io, you can secure your organization by looking beyond just detection, to automatically identify and fix your open source security vulnerabilities at every stage of the software development life cycle. And you can achieve this by giving developers and security professionals what they need to manage open source security from within their native development environments. Using our tools and technology, they can:
- Detect all vulnerable open source components, including in your transitive dependencies, in more than 200 programming languages
- Prioritize the most critical open source security vulnerabilities so you can fix what matters most first
- Remediate security vulnerabilities with one click using automatically generated pull requests that identify the latest version of open source components. Mend SCA, which supports GitHub (server and cloud), GitLab and Bitbucket (server) repositories, automatically remediates open source vulnerabilities, while Mend SAST is the first-ever auto-remediation application designed for custom code.
In addition to providing industry-leading open source security with our SCA technology, Mend offers a SAST security solution for your custom code that integrates with your existing DevOps environment and CI/CD pipeline. Its scanning engine produces results up to 10x faster than traditional SAST solutions. And it supports 27 different programming languages and various different programming frameworks.
For more information about Mend SAST, click here.
