Chasing the holy grail: Why Red Hat’s Hummingbird project aims for "near zero" CVEs

In the world of enterprise software security, few metrics are as coveted, or as elusive, as "zero CVEs." Simply put, a zero CVE (Common Vulnerabilities and Exposures) approach aims to deliver software components that are completely free of known security vulnerabilities at the time of shipping. For many organizations, particularly those in highly regulated industries, this is not just a "nice to have," it is a mandate. 

Initiatives like FedRAMP and various strict security frameworks increasingly demand that software supply chains be clean of known risks before deployment. As the industry has tapped larger and larger supply chains full of open source software, however, the volume of reported vulnerabilities has exploded, making a near zero CVE state an incredibly difficult achievement. These efforts prompted Red Hat to introduce Project Hummingbird, an initiative designed to ship minimal, hardened container images that target this "near zero" standard.

The myth of absolute zero

While "zero CVEs" is the industry’s holy grail, seasoned security professionals understand that it is a moving target that is effectively impossible to maintain for long. With hundreds of new vulnerabilities reported every day, a component that is "clean" at 9:00 AM might have a newly disclosed vulnerability by 5:00 PM, so, it is more accurate to describe the goal as a "near zero" CVE approach.

This also only applies to known vulnerabilities, but there are always unknown vulnerabilities, which means a build may have zero CVEs, but not zero risk. And even when zero known vulnerabilities are achieved, this only addresses one layer of trust—it says nothing about how the component was built, what hardening standards (like FIPS) it adheres to, or what critical attestation data is available to verify its provenance.

Trying to fix absolutely everything instantly is a Sisyphean task that conflicts with a modern, risk-based security strategy. In a risk-based approach, security teams prioritize issues that represent real, exploitable risk rather than burning cycles on theoretical flaws that cannot be triggered in their specific environment.

As noted in an InfoWorld article, "Why zero CVEs makes zero sense," chasing a perfect score of zero CVEs can sometimes be counterproductive if it distracts from deeper defense-in-depth strategies. Starting from a baseline that is practically empty of known vulnerabilities and built in a trusted pipeline, highlighted by “Zero CVE's: The symptom of a larger problem,” is one of the only ways to give security teams a fighting chance.

The vulnerability management nightmare

The primary driver for Project Hummingbird is the overwhelming complexity of the modern vulnerability management process. Today’s security scanners are incredibly thorough, producing massive reports that can run into thousands of lines for a single application stack. Sifting through these results to find the "needle in the haystack"—the one vulnerability that actually matters—is daunting and time-consuming.

Security teams are also forced to navigate a labyrinth of security metadata from conflicting sources, including vendor security advisories, public open source databases (like NVD or OSV.dev), and governance-specific resources. To make matters worse, this data comes in a dizzying array of formats, CSAF, VEX (Vulnerability Exploitability eXchange), openVEX, CVRF, and OVAL. Interpreting this data requires deep security expertise and significant effort.

This constant storm of potential vulnerability findings creates a huge amount of friction, often resulting in a frustrating "ping pong game" between security teams, who aim to fix everything to mitigate risk, and development teams, who prioritize rapid feature delivery. This friction wastes time and reduces productivity, causing frustration on both sides.

By using Project Hummingbird’s "near zero" components as a foundation, organizations can drastically reduce this friction. When the base image is clean, scanner results shrink to a manageable size, highlighting only the vulnerabilities introduced by the customer’s specific application code—the part they actually control and can fix, or mediate the impact of, quickly.

Additionally, if images are built in a trusted pipeline that meets industry supply chain security standards (such as SLSA compliance), and that contains comprehensive attestation metadata, it is possible to verify how components were built and by whom. This includes augmented build time software bills of material (SBOMs), with a full inventory of artifacts used during the build process, including their provenance. 

Does this mean other Red Hat products are less secure?

In short, no. It is important to clarify that the challenges of vulnerability management do not imply that other Red Hat products, such as the Red Hat Enterprise Linux (RHEL), are less secure than Hummingbird components. Different solutions address different use cases and Project Hummingbird is intended to be used by those needing only a minimal, hardened container image and not a full operating system.

All Red Hat products are built from sources and go through a wide variety of security and hardening tests. Red Hat checks every newly reported CVE and verifies how that new vulnerability affects the Red Hat portfolio, following a real risk-based approach during this assessment. 

The overall Red Hat software product portfolio is not only complex, it also supports multiple product streams with various version forks at the same time. Unlike Project Hummingbird images, which are incredibly small and simply rebuilt whenever needed, releasing patches for other products requires more time for testing due to size, and also includes back-porting to older, still-supported product versions. This requires precise patch consumption on the customer side, including security metadata verification by security scanners, a process which, as mentioned, is not easy.

Complexity in container builds and critical sectors

This reduction in noise is critical when dealing with complex build processes, such as modern container images, which often aggregate content from dozens of different upstream and downstream sources. In these complex artifacts, determining the real risk and impact of a specific CVE on a specific component can be incredibly difficult. Does a vulnerability in a library matter if the function using it is never called? Answering that question takes time—time that critical sectors like military and financial institutions often do not have.

For these high-security environments, the "assume breach" or "assume impact" mentality is safer. It is often faster and safer to apply an available patch (or update to a clean Hummingbird image) than to spend days trying to determine if a CVE is a false positive, potentially leaving a window open for attackers if the evaluation is wrong.

By providing a base that effectively assumes impact and remediates it proactively, Project Hummingbird enables these critical sectors to move with more confidence, reducing the paralysis of analysis. Our commitment to providing secure-by-default, minimal attack surface container images, and delivering fresh, up-to-date, near zero CVE content, are intended to help these organizations scale up their development efforts and deliver expected results in an accelerated manner.

Final thoughts

Ultimately, while the "zero CVE" holy grail may never be permanently achieved due to the evolving nature of cyber threats, Project Hummingbird represents a pragmatic leap forward. By providing "near zero" CVE content, Red Hat is not promising magic, but rather a massive reduction in the undifferentiated heavy lifting of vulnerability management. Our hope is that Project Hummingbird will help end users stop drowning in scanner noise so they can focus their limited resources on what matters most—securing the code and applications they are directly responsible for.

Learn more

• Zero CVE's: The symptom of a larger problem
• Extend trust across the software supply chain with Red Hat trusted libraries