Vulnerability Management - Strategy and Automation

It’s Monday morning: you get to the office, grab your coffee (hazelnut flavoured, of course), open the console of your favorite vulnerability scanner and… 5,000 newly discovered vulnerabilities, a number that almost makes you spit out that delicious nectar. And yet, they will have to be dealt with!

This article describes two strategies for handling the vulnerabilities you discover, while keeping in mind the reality on the ground because, as always, “you can’t fix everything by yesterday”, even if we’d love to.

Note: Should you wish to suggest an improvement or simply get in touch, you can reach me at contact@lionsec.lu.

Vulnerability sources

Within an organization, there are several ways to detect and inventory the vulnerabilities that affect (and sometimes impact) your assets: servers, workstations, HVAC systems, IoT, network equipment, web applications, cloud, etc.

Among these sources, the main ones are usually:

Vulnerability scanners (agent-based or agentless)
Static code scanners (SAST)
Dynamic scanners (DAST)
Dependency scanners (such as OWASP Dependency Check)
Internal or external pentest reports
Bug bounty, not mandatory but recommended
Cloud services (such as AWS Security Hub)
Any others you may have in place

Note: Aggregating all these sources can create duplicates, as well as reports in different formats.

Here’s the catch: a pentest report usually contains no false positives, because the provider makes sure to deliver a final report that proves, with supporting evidence, that the vulnerability exists and explains how to reproduce it (if not, change providers!). On the other hand, the various tools mentioned above can generate a lot of them (what is commonly called noise), which makes triaging the discovered vulnerabilities harder.

We will now look at two strategies (one manual and one automated) to handle a large number of vulnerabilities as quickly as possible, while cutting through the noise generated by scanners.

The manual strategy

When you aggregate several sources that have found different vulnerabilities, and time is short (which is very often the case), you need to quickly separate the most important ones from the rest in order to reduce the potential impact on your most critical assets. Often (and quite unfortunately), some organizations do this with an Excel file, which can remain acceptable depending on the size of the organization and the number of vulnerabilities discovered. Let’s now walk through this strategy, phase by phase.

Phase 1 - Sort by asset

The first filter is to focus not on the CVSS score, but on the value of the assets and their level of exposure (because attackers don’t necessarily go through the most valuable ones). The higher their value, the greater the impact of a cyberattack would be. Likewise, the more exposed they are, the higher the likelihood of an attack. So you will need to focus on these assets in particular.

The difficult choice of temporarily setting the others aside always leaves us uneasy, but since these assets are more critical than the rest and our time is not unlimited, we have to prioritize.

Phase 2 - Severity and exploitability

Once the vulnerabilities have been filtered down to these assets, several indicators can help us rank them:

The CVSS score: the Common Vulnerability Scoring System (version 4.0 at the time of writing) measures the severity of a vulnerability based on several criteria (vector, complexity, privileges, etc.). It is often the minimum indicator provided by pentest reports and automated tools.
The EPSS score: the Exploit Prediction Scoring System is a machine learning model that estimates the probability that a public vulnerability will be exploited in the wild within the next 30 days.
The CISA KEV catalog: the KEV catalog (Known Exploited Vulnerabilities) lists vulnerabilities that are already known to be exploited.

Some solutions such as Cyberwatch combine these three indicators into one, sometimes called 3D Prioritization, which lets organizations know straight away what to prioritize.

Phase 3 - Impact x Effort matrix

This is the step where your expertise in understanding vulnerabilities matters most. Indeed, despite the first two steps, you probably still have several critical or high vulnerabilities left, and telling them apart becomes more subtle.

Drawing on your knowledge of the environment, this step consists of building a matrix of vulnerabilities, ranked by potential impact if they were exploited, and then by the effort required to fix them.

It may simply be a false positive, which quickly settles the matter, or several vulnerabilities may only require an update (which is often the case on a critical production server that everyone is afraid to touch :)).

Note: I regularly hear of individuals who focus solely on a vulnerability’s CVSS score to demand that it be fixed. This is an error of judgment: your solution may be affected by a vulnerability that can only be exploited (for example) through the solution’s API, which you have never enabled.

In short, this step requires going through the remaining vulnerabilities with a fine-tooth comb and calls for business knowledge in order to prioritize more effectively.

Note: Likewise, your offensive security knowledge will have a role to play. Between an SQL injection and a reflected XSS, there’s usually no question, but what about a stored XSS? :)

Phase 4 - Parallelization

Depending on your structure and the vulnerabilities you have kept, it may be possible to parallelize remediation across different teams: vulnerability A could perhaps be assigned to the developers because it comes from vulnerable code, vulnerability B will have to wait, while vulnerability C could be assigned to the network / infrastructure team since it is a misconfiguration.

This cycle repeats indefinitely as part of a continuous improvement approach, moving from asset to asset. Of course, you need to update your policies and processes to reduce vulnerabilities over time, with well-defined SLAs because, if you are a software vendor, your customers will ask for them, especially for vulnerabilities such as those affecting PHP (CVE-2026-109618 and CVE-2026-109619), which are making a lot of noise at the time of writing. Or the famous Log4Shell vulnerability affecting the Log4j library, which triggered a wave of messages from customers (entirely legitimate, of course) asking for proof that it had been fixed in your products and environments.

Note: This vulnerability was disclosed on December 10, 2021, yes, right before the Christmas holidays :)

Let’s now explore the automated strategy because, as you can imagine, when the number of vulnerabilities to handle is far too large, the manual strategy takes an enormous amount of time, and that is exactly why solutions exist to help us.

The automated strategy

Fortunately, there are solutions that can automate this strategy (and much more). One of them is OWASP DefectDojo, which comes in a free (community) and a professional edition. The official GitHub page provides the addresses of the demos for both editions, credentials included, for a live preview of what they can do.

Key features include:

An overview of all vulnerabilities and their discovery sources
Deduplication
Auto-remediation capabilities through the SenseiAI agent (Pro edition)
Connectors to various vulnerability scanning solutions (Acunetix, Cyberwatch, BurpSuite Enterprise, etc.) (Pro edition)
A remediation center (very handy to see which updates can eliminate many vulnerabilities at once) (Pro edition)
An asset explorer (URLs, source code, dependencies, cloud resources, etc.)

Another open source option is Faraday, which also uses connectors to various vulnerability scanners and pentest tools. It is also available in community and professional editions.

Once you have installed the solution, deployed your connectors and configured your policies with your SLAs, you have an automation solution that is far more complete than a simple, hard-to-maintain Excel file.

Ignoring low-severity vulnerabilities?

This topic is usually up for debate and depends on the organization’s risk tolerance. Some decide not to bother with them, due to lack of time or simply because “the risk is rated as low”.

I always recommend at least taking a look because a cyberattack does not (usually) consist of a direct move from point A to point B, but rather of a succession of vectors. Attackers can use any useful information to extend their attack toward other, more interesting vectors. Sometimes, fixing low or informational (and even medium) severity vulnerabilities can help break an attack chain that the attacker might have tried to use.

Conclusion

Vulnerability management can seem complex at first, especially when an organization tackles it for the first time, but with the right strategy and appropriate solutions, it is possible to save a great deal of time and efficiency in fixing these weaknesses that could otherwise fly under the radar and cause you harm. Every organization is free to manage its vulnerabilities with its own methodology, but the strategies presented in this article already give a clearer picture of how to proceed.

Contact

For any suggestions or simply to get in touch: contact@lionsec.lu.