Skip to content
Untitled design-Aug-24-2022-05-14-44-04-PM
Tim SmithJuly 18, 20224 min read

CVEs: Close the Gaps That Let in Attackers

800x418 blog feature images (3)-1

IT organizations are making cybercrime too easy. Projects like the National Vulnerability Database and Common Vulnerabilities and Exposures (CVE) warn about the doorways that hackers use to penetrate infrastructure. Software providers rush to provide patches for their vulnerable products. However, most IT teams don’t patch their systems when they learn about a problem.

Ignoring CVEs is gambling with your infrastructure

Unpatched software places your organization at risk for ransomware, data theft, and other costly and destructive cybercrimes. According to Gartner, through 2023, 99% of infrastructure breaches will rely on known vulnerabilities and misconfigurations.

Last year, the CVE program identified over 20,000 vulnerabilities and exposures in commonly used software. That's 20 times more CVEs than were discovered in 2000. With this explosion of known risks, DevOps teams struggle to identify and patch the most critical holes in their infrastructure. These holes are invitations for cybercriminals.

Many companies know they have a problem, while others aren’t aware of how vulnerable their systems are. A recent Outpost24 study revealed that only 47% of IT organizations apply patches when CVEs are reported. Organizations' self-reported confidence in their ability to patch systems promptly is at an all-time low of just 50%, according to research by the Ponemon Institute.

Why leave known gaps open?

What’s holding back organizations from patching their systems? The challenge is that we see exponential growth each year not only in reported CVEs but in the complexity of the typical IT infrastructure. Gone are the days of a few long-lived systems in a data center from the same OS vendor. Now we have multiple OSs, containerized microservices, and systems with production lifespans that can measure in just minutes.

Despite this radical shift in our infrastructure landscape, vendor patch tooling hasn’t changed much in the last decade. To distribute patches, we still rely on YUM, DNF, Zypper, and apt. The operating system tools often lack information on the security impact of patches. This makes identifying and prioritizing the necessary patches in your infrastructure an overwhelming task for teams.

Mondoo finds the gaps

We built Mondoo to help DevOps and Security teams identify and prioritize vulnerabilities in modern cloud infrastructure. Mondoo continuously scans and reports vulnerabilities in Windows and Linux systems as well as container images. Our shift-left approach to security identifies vulnerable software packages in container and cloud images during the development process.

Identify CVEs in production

Mondoo continuously scans production systems and highlights when a machine or container has a known vulnerable package, advisory, or CVE. To help with patch management strategy, Mondoo prioritizes issues from low to critical.

Mondoo CVE Scan

A one-click shortcut copies findings to the clipboard so that you can include them in reports and plans.

You can explore the details of individual vulnerabilities to learn more about the risks they pose. For each CVE, Mondoo provides:

  • A description of the problem and how it makes you vulnerable 
  • An overall risk score based on:
    • Attack vector
    • Attack complexity
    • Privileges required
    • User interaction
    • Scope
    • Confidentiality
    • Integrity
    • Availability

Learn which assets have a particular CVE

If a particular vulnerability is a concern for your organization, it’s important to understand the extent of the problem. Mondoo can find all assets in your infrastructure that have a certain CVE.

Mondoo CVE Detail

Each CVE detail includes a list of your assets that share the common vulnerability. You can click any asset in the list to learn more about it, including any other security and compliance issues that put the system at risk.

Identify and prioritize vulnerabilities before they go live

It’s important to find CVEs and other security concerns in production systems. However, waiting until production to scan for vulnerabilities is, essentially, racing hackers to find attack points. It’s also a time-consuming and expensive way to protect your infrastructure.

A safer and more efficient approach is to find CVEs as early as possible in the system development life cycle. This approach is an important part of a shift-left security strategy.

Don’t confuse shifting security left with slowing down the development process by inserting manual security testing. To truly shift left for the benefit of your organization, you must integrate security checks into your CI/CD workflow. Checking for CVEs needs to be an automated step in the fluid process of building infrastructure.

Mondoo’s CI/CD integration allows you to perform Mondoo security scans directly in popular CI/CD systems like GitHub Actions, GitLab CI, and CircleCI. Use Mondoo to identify CVEs directly in your system definitions by scanning Packer builds, Dockerfiles, or Kubernetes manifests.

Mondoo CI View

Mondoo makes this possible by codifying security policies. In our policy as code solution, each security policy is a piece of code that you can run as a part of your CI/CD automation. So, for example, scanning a container image for CVE-2022-1292 is part of a security policy that you automatically check against whenever Dockerfiles or even Kubernetes manifests are updated.

Find CVEs now

Policy as code doesn’t mean that you have to write policies from scratch. We provide more than 100 Mondoo- and CIS-certified security policies out of the box. They identify misconfigurations, CVEs, and thousands of other details that put your infrastructure at risk. That means you can start protecting your organization right away.

Find the gaps that hackers can use to breach your infrastructure. Scan with Mondoo now.

New call-to-action


Tim Smith

Tim Smith is a Product Manager at Mondoo. He’s been working in web operations and software development roles since 2007, port scanning class As since 1994, and downloaded his first Linux distro on a 14.4 modem. He most recently held positions at Limelight Networks, Cozy Co, and Chef Software.


view raw