Our AI strategy for preemptive security
Any time threat actors try to compromise an application, server, or another IT system, they search for weaknesses that they can exploit. These weaknesses are low-hanging fruit that makes it easier to achieve malicious goals, whether that means installing malware, encrypting systems with ransomware, or stealing sensitive data from your environment.
Modern IT environments’ fast-paced, ever-changing nature means new vulnerabilities constantly emerge. Businesses and security teams face a race against time to find vulnerabilities and deal with them before it’s too late, either through mitigation or remediation. This article clarifies the difference between risk mitigation vs remediation.
A vulnerability is a flaw in a system that weakens its security and could be targeted by a cybercriminal exploiting it.
Ever since curious-minded individuals began exploring computer systems, software, and networks, they found vulnerabilities that could allow them to retrieve hidden information, escalate privileges or access unexpected resources.
In 1967, a group of high school students found security vulnerabilities in an IBM network of computers and terminals running the APL programming language. This primitive form of ethical hacking helped to strengthen the security of IBM’s future computer systems.
Unfortunately, having a curious mind and hacking systems is not restricted to altruistic or ethical uses. Malicious actors today constantly probe IT environments for vulnerabilities using an array of tools and techniques. While there are many different types of vulnerabilities, here are some of the most common ones that hackers try to exploit:
The pervasive challenges in finding and eliminating vulnerabilities call for a dedicated vulnerability management strategy. The extent of these challenges was evidenced in a joint advisory published by CISA (US), NCSC (UK), and ACSC (Australia) highlighting the top most commonly exploited vulnerabilities in 2021 and 2020. One of these vulnerabilities had a patch available since 2017, while several others had patches released in 2018 and 2019.
Vulnerability management is a systematic approach to continuously identify and eliminate vulnerabilities in your IT environment. The typical steps in vulnerability management are as follows:
Vulnerability management should be an ongoing strategy that reflects how new vulnerabilities regularly emerge in IT environments.
Why this matters for “mitigating vulnerabilities”: lifecycle clarity ensures mitigation isn’t ad‑hoc; it’s a deliberate, measured response when full fixes must wait.
Discussions about vulnerabilities in cybersecurity are sometimes biased toward remediation as the only way of dealing with them. In most cases, the recommended advice is to patch your vulnerabilities and do it ASAP. But this neglects the fact that mitigation is another potential solution for resolving vulnerabilities.
It’s helpful to view vulnerability management in a way that links the process back to the more overarching strategic goal of cyber risk management. Each vulnerability has a certain severity level and a certain likelihood of being exploited. Whatever scores you use to rank your vulnerabilities, the outcome is often an increased risk of exposure or loss.
The question then is how do you want to reduce that risk? For vulnerabilities, you have two broad options:
Remediation through security patches is presented as the ideal resolution method, but it’s sometimes not possible or even necessary at the time. For example, the software vendor might not have a patch available yet, or an important operational system might be vulnerable for which any downtime is intolerable. Or, there could be out-of-date systems that have a vulnerability but those systems aren’t directly accessible or exploitable by malicious actors.
How to choose between them
In practice the choice is rarely a preference. It is decided by four conditions, and if you work through them in order you will usually find the answer is already made for you.
Is a fix available? If the vendor has not shipped a patch, or the fix requires a code change your team has not scheduled, remediation is not on the table today. Mitigate and set a review date tied to the patch, not to the calendar.
Can you afford the downtime the fix requires? Some systems cannot be restarted inside a business cycle, and some patches carry a real risk of breaking a dependent service. If the fix window is weeks away, the vulnerability is unprotected for those weeks unless you mitigate now.
Is the asset actually reachable, and how critical is it? An exploitable flaw on an internet-facing host is a different problem from the same flaw on a system an attacker would need three other footholds to reach. Network reachability and asset criticality should move an item up or down the queue more than the severity score alone does. A medium-severity issue on a business-critical, externally exposed system outranks a critical one on an isolated internal host.
Does anything oblige you to fully resolve it? Compliance obligations, contractual security commitments and customer security reviews frequently require the flaw to be eliminated rather than contained. Where that applies, mitigation is a stopgap you will still have to close out, so plan the remediation at the same time.
The common answer is both, in sequence: mitigate today to reduce exposure, remediate when the patch, the maintenance window or the vendor is ready. Only remediation addresses the root cause; mitigation reduces the chance of that root cause being reached. What separates a mature program from an improvised one is not which it chooses but whether the mitigation was recorded with an owner and an end date, or simply left in place.
How long should a mitigation stand?
Only as long as the condition that forced it. That sounds obvious, and it is the single most commonly broken rule in vulnerability management.
A mitigation applied because no patch existed should expire when the patch ships. A mitigation applied because a maintenance window was three weeks out should expire after that window. When a compensating control has no expiry attached to it, it stops being a decision and becomes part of the architecture: the segmentation rule survives a network redesign nobody re-checked, the disabled feature quietly becomes a permanent product gap, and the original vulnerability is still there, now undocumented.
Three habits prevent it. Record the trigger that will end the mitigation rather than a date, because the trigger is what actually matters. Give it a named owner, not a team. And re-verify the control itself on the same cycle you re-scan for the vulnerability, because a compensating control that has silently stopped working is worse than no control, since the risk register still shows the item as handled.
The order is almost always mitigate first, remediate second. Mitigation is what you can do this afternoon; remediation is what you can do when the fix exists and the change window opens. The exception is a low-risk flaw with a patch already available and no downtime cost, where mitigating first just adds a step.
Approaches to remediation involve updating affected software/firmware to the latest version, applying a security patch, changing a configuration, or potentially even removing a vulnerable asset entirely from your environment (e.g. replacing one software solution with another).
Mitigation techniques fall into a few recognizable groups.
Virtual patching puts a rule in front of the flaw instead of inside it: a web application firewall or intrusion prevention system blocks the requests that would exploit the vulnerability, so the vulnerable code keeps running but the exploit path is closed. It is the closest thing to a drop-in mitigation, and the usual first move when a patch does not exist yet.
Network controls isolate rather than block: segmentation walls a vulnerable set of resources off from the rest of the network, and access control restrictions cut the number of accounts and hosts that can reach it at all.
Configuration hardening removes the conditions the exploit needs, by closing a port, disabling a feature or module, or tightening a permission, without changing the underlying code.
Temporary withdrawal is the blunt option: take the application or service offline until the fix lands. It is rarely popular and sometimes correct.
Your choice usually isn’t a straightforward either/or decision between vulnerability remediation and mitigation. In scenarios where remediation approaches aren’t feasible, you can temporarily mitigate before eventually remediating when the situation allows for it.
Positive Technologies research covering 2019 and the first half of 2020 found high-risk vulnerabilities on the external network resources of 84 percent of tested companies. It’s important therefore to identify and resolve vulnerabilities in your attack surface arguably before any other class of vulnerabilities.
Dedicated external attack surface management solutions prove useful for this task because they can quickly and automatically discover your complex and expanding external attack surface. These solutions then use the inventory of discovered assets and continuously scan for vulnerabilities.
The metrics worth tracking are the ones that tell you whether the program is getting faster, not just busier. Scan coverage and raw finding counts describe activity; the numbers below describe outcomes.
Mean time to remediate, split by severity, is the headline. Track it separately for internet-facing assets, where the exposure window matters most.
Open mitigations and their age is the number most teams do not have and most need. It is the direct measure of how much risk is being held rather than removed.
Reopen rate, meaning the share of items closed and later found again, tells you whether verification is real or nominal.
Patch availability lag, the gap between a vendor releasing a fix and you applying it, isolates the part of the delay that is yours.
Track these metrics over time and look for trends that indicate potential areas of improvement. Perhaps switch things up by looking for more ways to automate the process of detecting or resolving vulnerabilities.
Bugcrowd’s external attack surface management solution provides essential capabilities for identifying and prioritizing vulnerabilities in your external attack surface. You also get accelerated remediation by being able to connect your workflows and assign vulnerabilities to relevant teams with all the details they require to remediate each vulnerability.
Vulnerability remediation is necessary when organizations aim to completely eliminate identified vulnerabilities from their systems. This approach is typically required for high-risk vulnerabilities or when compliance requirements demand a thorough resolution.
Vulnerability mitigation is appropriate in situations where it may not be feasible or practical to completely resolve the vulnerabilities. This approach is often employed when immediate remediation is not possible or when the risks associated with the vulnerabilities can be sufficiently reduced through compensating controls or alternative security measures.
Vulnerability mitigation is typically considered a temporary or interim solution. While mitigation measures can reduce the immediate risk associated with vulnerabilities, they may not provide a permanent fix. Organizations should aim to prioritize and plan for complete vulnerability remediation whenever feasible and allocate resources accordingly.
Vulnerability mitigation should not replace vulnerability remediation as a general practice. While mitigation can help reduce immediate risk, complete remediation should always be pursued whenever possible. Organizations should prioritize vulnerability remediation to achieve a more robust and secure environment in the long run.
Mitigation usually comes first, because it can be applied immediately while remediation waits on a patch, a maintenance window or a vendor. The exception is a vulnerability with a fix already available and no meaningful downtime cost, where applying the patch directly is faster than standing up a temporary control. Where mitigation comes first, it should carry an explicit condition that ends it.
Yes, and for anything serious they usually should. Mitigation reduces exposure while the remediation is being scheduled, tested and rolled out. Treating them as alternatives is what leads to a vulnerability sitting untouched for a month because a patch was already planned.