From challenge to champion: Elevate your vulnerability management strategy
Source: Red Hat Blog
In the world of cybersecurity, vulnerability management is frequently a collaborative effort between vendors, software maintainers, and customers. It’s a continuous journey of discovery, prioritization, and remediation that we embark on together. Each challenge that we face provides valuable opportunities to refine our strategies and strengthen our collective security posture.
Based on our work with customers, we’ve identified a few common areas where we can all “level up” our vulnerability management game.
Let’s explore these patterns and recommendations.
Beyond the base score: The art of smart prioritization
A common starting point for prioritizing vulnerabilities is the Common Vulnerability Scoring System (CVSS) base score, which is provided by vendors, vulnerability‑scanning applications, and government databases like the US National Vulnerability Database (NVD). While this base score is a great upstream measure of intrinsic flaw characteristics, relying only on the base score in a downstream system can have teams looking for high‑scoring vulnerabilities that pose little actual risk to their specific environment.
Think of the CVSS base score as the manufacturer’s suggested retail price (MSRP) of a car. It gives you a general idea of value, but it doesn’t account for your specific needs, the car’s mileage, or current market conditions. In 2024, 40,000 CVEs were published. Of those, only 4,200 affected Red Hat products. If you compare the CVSS base scores of those 4,200 CVEs, you’ll find that 35 % had a Red Hat severity rating that was lower than a severity mapped 1‑to‑1 with the base CVSS score.
Our recommendation: Embrace context.
True risk is a combination of a vulnerability’s base characteristics and its context within your environment. CVSS was actually written with this in mind, and there are several good suggestions in the VulnCheck article “Common Vulnerability Scoring System (CVSS)” as well as the Tenable article “Vulnerabilities by CVSS.”
The overall goal is to enrich the risk‑prioritization approach by asking a few key questions:
-
Is this vulnerability being actively exploited in the wild?
Threat intelligence can help elevate a medium‑severity vulnerability to a critical priority. -
How critical is the affected asset?
A public‑facing production database is a higher priority than an isolated development server. -
Do we have existing controls?
A Web Application Firewall (WAF) or strict network segmentation might already mitigate the risk, lowering its immediate priority. -
Can we eliminate it ourselves?
You may not need to wait for a patch if the affected software is not used and can be removed.
By layering context—asset criticality, threat intelligence, and existing security controls—over the base score, we can focus our valuable resources on the vulnerabilities that truly matter most.
Gaining clarity: A sharper focus on container security
Scanning container images for vulnerabilities is essential, but it can sometimes feel like looking through a foggy window. On average, customer inquiries will mention several hundred vulnerabilities being reported in each container image. Analysis work is required to determine whether that CVE list is accurate. This ambiguity can lead to wasted effort chasing down risks that may have already been patched and aren’t exploitable. For example, some containers include code that’s unused and inaccessible for exploitation.
Our recommendation: Vendors and customers need to consider a layered approach.
Platform methodologies aren’t effective in the container space. Vendors and customers need better solutions based on the full lifecycle of an image—not just the final product. Vendors have a primary responsibility for these solutions; however, customers must also be aware and learn to assess container vulnerabilities using a layered approach.
-
Identify the layers – Container manifest files and content repositories give context into where a software component originates. Vulnerability‑scan results can then be mapped back to the origin to determine whether the vulnerability has been fixed at the source.
-
Timeline matters – Image versions are static and not updated like a platform product. New images are constantly required to keep up with bug fixes and patched vulnerabilities.
-
Focus on what’s running – Use tools that can differentiate between a package that is simply present in an image and one that is actively loaded and used by your application at runtime. This helps filter out the noise and pinpoint the real threats.
This multilayered strategy provides a much clearer, more actionable picture of your container security posture.
Beyond the patch: Building a culture of resilience
The ultimate goal of vulnerability management is remediation. However, a “check‑the‑box” mentality that solely focuses on applying a patch can be limiting, especially when a patch isn’t available or is difficult to deploy. Kaspersky’s 2024 report reveals a significant gap in protection: despite universal adoption of endpoint security, just over half of organizations invest in staff security training. The report also points out that within almost every industry vertical, revenue losses from security incidents more than doubled the investment in security. True security resilience comes from investing in a deeper technical understanding of risk and the creative use of all the tools at our disposal.
Instead of just asking, “Is there a patch?” we should expand our thinking.
Our recommendation: Mitigate first, re…
Mediate Smart
Think of this as cybersecurity first aid. A patch isn’t always immediately available. The average patch time for important CVEs affecting Red Hat in 2024 was 31 days. While efficient, that window still represents a period of exposure. To close this gap, we can apply compensating controls to protect the asset and reduce the risk to an acceptable level.
Practical Compensating Controls
- Leverage security features – A well‑configured WAF can block the specific attack pattern of a web vulnerability. Strict firewall rules can prevent an internal service from being accessed from the Internet.
- Understand the “why” – Know the vulnerability itself.
- Is it a SQL injection flaw? An input‑validation control might be a powerful mitigation.
- Is it a remote code execution (RCE) vulnerability? Limiting network access could be a crucial first step.
Why Shift the Mindset?
By moving from a patch‑only mindset to a mitigate‑and‑patch strategy, we empower our teams to be proactive. This approach doesn’t just check a box; it:
- Builds a more resilient and defensible environment.
- Fosters a deeper culture of security awareness.
If you would like to discuss these recommendations, please contact a member of the Red Hat support team to start that discussion.