Mitigation & Remediation

Organizations known for successful vulnerability management have proactively created both mitigation and remediation plans to handle threats and vulnerabilities when they arise. While it is cost-prohibitive to remove risk entirely, these two approaches to risk management play distinct and very important roles in protecting organizations’ applications from third-party threats. They may sound similar or even interchangeable, but their differences are important.

  • Remediation means correcting or counteracting something. This is the more permanent approach in a vulnerability management response. Remediation aims to abate the threat entirely. A remediation plan is more than simply having a flowchart or decision tree to guide an organization’s response to a vulnerability. There are numerous factors to consider, and there is no perfect equation to adequately remediate risk because each organization has unique business priorities and differing thresholds for risk.
  • Mitigation, on the other hand, means making something less severe. In an ideal world, your applications are free from vulnerabilities because your organization’s remediation plans effectively prevented them. When this isn’t the case, however, the alternative is accepting the risk, which is at the heart of mitigation. An organization knows the risk is there but but determines that it is acceptable risk when weighed against the effort/cost to address it through remediation.

Remediation Strategies at a Glance

There are typically four general strategies to remediate vulnerabilities, each with their own pros and cons based on an organization’s specific set of circumstances. They are as follows:

StrategyWhat it isProsConsCost/EffortRisk
Component UpgradeUpgrade to better version• Most effective
• Least expensive
• Can be automated
• Wait time for version releases
• Transitive dependencies problematic
• Requires slower pace to prevent introducing more risk
• Upgrading legacy code and breaking changes cost-prohibitive
DIY PatchRemove vulnerable code from execution path. Patch the component yourself; push back to maintainer’s repo.• Opportunity to contribute to OSS community
• A cheap and quick solution
• Creates technical debt
• Long-term commitment to maintenance
• Difficult to remove all risks
Switch ComponentsFind alternative component• Move to component with better hygiene
• Use fewer parts
• Standardize on common components
• Refactor could be expensive
• May not return additional value
• New grass may not be greener
Remove Component EntirelyRemove component; replace with your own code• Remove external risk
• Reduce project bloat
• Slower innovation
• Expensive
• Potential vendor lock-in
Table 2. Remediation strategies, what they are, their pros and cons, cost, and risk

Component Upgrade

Upgrading the component to a safer, better version is the most effective remediation strategy. It is the least expensive option and can be automated (saving even more time and resources). The down side can include a possible longer wait time for the version to be released by the maintainer. If you have any transitive dependencies to worry about, those could be cumbersome to deal with. This option requires a slower, more methodical approach so as to not introduce more risk in the process of fixing the initial problem.

DIY Patch

One of the benefits with any do-it-yourself solution is that you are at the helm and control the code. With the DIY patch strategy, you are removing the problematic code from your execution path and replacing it with code that you write yourself. Hopefully you decide to share your coded solution with others who also have included the vulnerable component in their projects. Contributing to the community is, after all, what it’s all about. Another benefit is that this is a cheap and quick remedy, something that your leadership will especially appreciate.

Switch Components

While you most likely chose the vulnerable component initially because it provided precisely what your application required, there are often other components you could swap. Plus, if the swapped component has been hygiene, it’s a win-win. On the other hand, the grass isn’t always greener, and that’s one of the cons associated with this approach. The refactor process could be expensive in time and resources for your team and may not return any additional value. 

Remove Component Entirely

If your organization can manage to lose the affected component, the benefit of removing it entirely from your application is that it removes the threat entirely. This is ultimately safest because, if you must retain the functionality the component provided, you can write and maintain the code yourself. While this can be a slower strategy to implement, you reduce the external risk.

Mitigation Strategies at a Glance

There are two main strategies to mitigate vulnerabilities, each with their own pros and cons based on an organization’s specific set of circumstances. They are as follows:

StrategyWhat it isProsConsCost/EffortRisk
WaiveKeep component; mitigate as necessary• Good option if not a direct risk• Creates tech debt
• Future upgrades more difficult
Baselining/GrandfatheringAccepting the legacy risk• Reduce noise
• Focus priorities
• Ignores risk
• False security
• Creates tech debt
Table 1. Mitigation strategies, what they are, their pros and cons, cost, and risk


The most common mitigation strategy is to waive the violation. Some common reasons an organization would choose this approach are as follows:

  • There is no current impact to the application (aka not exploitable).
  • A grace period is put in place to fix the violation.
  • There is no current priority to remediate the issue (not in the budget).
  • There is no path forward to resolve the issue.

When organizations choose to waive a violation, there are some best practices to follow:

  • Use waivers instead of ignoring violations.
  • Document a common format for waivers so they are understood and accountable.
  • Avoid permanent waivers. Waivers should be reviewed periodically so that the reasoning remains consistent.  
  • Review waivers for high-threat risks more frequently than low-threat risks.
  • When possible, consider switching components even if the application is not exploitable. Most often the component is still a risk by remaining in your application.


For legacy or low-impact applications without active development, the cost of remediation and rework is determined to be out of scope. All existing issues are accepted as a baseline for the application, and any remediation efforts are focused on new violations. Organizations that choose this strategy should regularly review the grandfathered violations to fix issues that can be fixed. This method can also be used for automatic enforcement by grandfathering those policies.

0 0 votes
Article Rating
Notify of
Inline Feedbacks
View all comments