The 2024 Red Hat Product Security Risk Report: CVEs, XZ Backdoor, SSCAs, AI…oh my!

Grab a large sweet tea or a cup of coffee and read  the 2024 Product Security Risk Report from Red Hat Product Security. As someone striving to stay informed about the open source ecosystem and its security challenges, I found this year's report noticeably longer, but the depth and detail didn’t disappoint. In fact, one notable addition to this year’s report is the discussion of AI. 

The numbers game: up, up, and...wait, what?

First, let’s break down the raw numbers. Red Hat Security Advisories (RHSA) hit a new peak in 2024, clocking in at 2975. There has been a steady increase over the past few years. Interestingly, while Important and Moderate advisories saw a significant jump, Critical advisories decreased slightly, leaning towards more proactive security practices and faster detection.

The common vulnerabilities and exposures (CVE) count skyrocketed to 4272, a significant increase from previous years, which were relatively stable. What caused this? The report highlights the Linux Kernel Organization becoming a CVE Numbering Authority (CNA) in February 2024. They began assigning CVEs to numerous kernel issues, many of which wouldn't have received assignments previously. If you filter out those new kernel.org CVEs, the trend line appears more familiar, with a slight increase, likely reflecting Red Hat's growing portfolio but nothing alarming. 

Digging deeper, most new kernel CVEs are rated Moderate and Low, and only 45% of the CVEs assigned by kernel.org in 2024 affected current Red Hat Enterprise Linux (RHEL) kernels. Further, the focus should remain squarely on those Critical and Important vulnerabilities that align with where actual exploitation attempts are seen. This approach is validated by Red Hat’s rapid turnaround for over half of the Critical CVEs, providing the first fixes in 7 days or less, and 3 fixes on Day 0.

Without the above context when looking at these metrics, you might think, what is Red Hat doing? The raw CVE count increased significantly, but the underlying risk profile for Red Hat products didn’t actually change in parallel. These numbers reinforce that relying solely on the CVE count is insufficient; you must also consider severity, exploitability and relevance. Red Hat's focus on patching Critical and Important issues is validated by the data, showing that's where most real-world exploitation occurs, proving that a risk-based approach makes the most sense.

XZ Backdoor: the elephant in the room

Who can talk about security in 2024 without mentioning the XZ Backdoor incident? It was a well-thought-out supply chain attack that still haunts the dreams of the open source community. A trusted maintainer who spent over 2 years building rapport in the community introduced a sophisticated backdoor into the XZ library. If Andres Freund hadn't noticed the performance lag it caused, it could have compromised Secure Shell (SSH) access across countless systems.

In this report, Red Hat reflects on the open source response, while taking a moment to highlight the inherent risks and showcase the open source model's strengths. The rapid, collaborative analysis and information sharing were possible because the source code and interactions were public. The report also discusses the barriers within their own pipeline, like Fedora testing and RHEL quality engineering, that could have caught it, though it's impossible to say for sure.  

The XZ Backdoor incident was a wake-up call. This incident will have long-lasting effects on trust and contribution processes in open source. Supply chain attacks are growing in number and sophistication. Attackers are finding ways to target common tools and shared code that developers use daily, hoping to cause widespread problems. These types of attacks show that software vendors need multiple layers of protection: automatically checking the safety of any prebuilt code parts used, having a secure assembly line for building software and carefully inspecting any new pieces before adding them. It's good to know that Red Hat had several checks in place that could and would have caught the recent XZ security problem, emphasizing that these layers of security truly help. Security will never be a one-and-done activity.

Supply chain woes

The escalating number of Software Supply Chain Attacks (SSCAs) and the reliance on open source components is almost unbelievable yet statistically true. Black Duck’s analysis paints a troubling picture: a staggering 97% of commercial codebases rely on open source components. While this increases the speed of innovation and development, it can create an extremely attractive target for malicious actors with data showing that they aren't passing up any chances. Red Hat's tracking of publicly reported SSCAs revealed 89 incidents in 2024, a jarring 68% increase year-over-year. Sonatype's report echoes this unsettling trend. Software supply chains are increasingly under siege.

The XZ Util compromise and North Korean threat actors who used elaborate employment fraud schemes to gain insider access were just 2 examples of the evolving tactics used by malicious actors. The problem with this is that for most of these attacks the motive is largely unknown, and a massive amount remains unclaimed. It's hard to defend effectively when you don't fully understand who is attacking or why. We know some attackers want money or are trying to spy, but we don’t know the goal for many attacks. This complicates the whole situation with cyber threats and is hard to predict or model. Targeting developers and their access points makes perfect sense from an attacker's perspective, as they hold the keys to the kingdom, but it also means that the very human element of building our digital world is a prime target.

These SSCAs demonstrate the escalating exploitation of critical open source dependencies by skilled, anonymous attackers. We can't simply stop using open source given that it substantiates modern software. Therefore, we need a fundamental shift moving forward. We need more proactive security protocols embedded throughout the development lifecycle, not just when we are reacting to breaches. This includes better vetting of dependencies, robust security practices for developers, and, as highlighted by the XZ response, a shared responsibility model where vendors, communities and users invest in securing the ecosystem. The sheer scale of our reliance demands a proportional investment in its security. We’re still playing catch-up against adversaries who are clearly several steps ahead.

Ode to AI

In case you missed it, over the last year, generative AI (gen AI) has exploded—from chatbots to coding assistants to creative tools. The momentum is not slowing down, with gen AI predicted to grow at a rate of 37% every year until 2030. That is mindboggling, to say the least. 

But like with any shiny new technology, there’s a honeymoon phase where everyone is focused on what it can do. How fast can it work? How much can it create? How might it change the way we do just about everything?

But now that we see the real value, especially in highly regulated industries like healthcare, finance and government, where mistakes can have major implications, we have to start thinking  about the serious stuff. How do we keep AI usage safe, secure and trustworthy? Can we trust it not to mess things up or leak private information? Decision makers say that keeping data safe is already the biggest worry people have about AI for this year. That makes total sense. You don't want your personal information getting out or AI making bad decisions because it wasn't built securely. As you’ve read above, we already have some high visibility targets in open source. 

What I appreciate is that we’re not just jumping on the AI bandwagon; we’re actually working to figure out how to make AI secure and safe. But, that’s not an easy task. 

One of the first things Red Hat points out in Building Trust: Foundations of Security, Safety and Transparency in AI is the need to separate an AI security vulnerability from an AI safety issue:

• Security vulnerability: A hacker finding a way to break into the AI system.
• Safety issue: The AI itself saying something inaccurate, biased or even harmful, even if no one "hacked" it.

These issues need to be addressed differently because fixing a bug is not the same as teaching AI to not be toxic or make things up. They need different rulebooks.

It's reassuring to see that companies like Red Hat, governments like the EU and the US, and various industry groups are working hard to figure this out. They're trying to create guidelines, standards and ways to track these different AI risks. They're looking to build this technology responsibly from the ground up, training their engineers and creating secure designs. What’s significant is that Red Hat isn’t just talking, we're building.

So, what does all this mean? The AI boom is exciting and it could change many things. However, it comes down to trust. As with any good relationship, trust is foundational. Our relationship with AI has to be built on trust for us to get the full benefit of it, and that is more than flashy demos. It comes from working hard behind the scenes to make sure the tech is safe, secure and behaves as expected. It sounds like the right people are focused on that, which is good news. We need to be careful and build guardrails now, rather than trying to fix huge problems later. We need people who trust AI to do this!  

Behind-the-scenes, the SDLC hustle

In 2024, Red Hat proved that behind every reliable product is a whole lot of hustle to make sure nothing falls through the cracks. Our approach goes beyond merely following NIST security standards. Red Hat is developing its own unique methods to help verify that everything we build, including AI technologies, is reliable and trustworthy from the start.

The Red Hat Secure Software Development Lifecycle (RHSDLC), which provides our plan for building software focused on security, is now smarter and even more aligned with the current real-world security challenges. But we aren’t just checking the boxes. We’re creating our own standards, such as the RHSDLC, to make sure the software supply chain is security-hardened from start to finish by maturing the Security Operating Approvals (SOA) procedure. This includes verifying third-party tools, automating checks and flagging risks before they become problems. It’s like catching the leak while it’s still a drip, instead of waiting for the flood. We are dedicated to empowering customer confidence in our products by thoroughly exploring security details and prioritizing trust, transparency and resilience.

I loved seeing the standardization of Security Architecture Reviews (SARs) into the RHSDLC. These reviews support the classic, battle-tested security principles, such as “only give access to what’s absolutely necessary,” “layer your defenses” and ensure security is baked into the product design from day one. 

Lastly, there’s RapiDAST. If you’re into open source or even application development, this tool is a hidden gem. It’s Red Hat’s dynamic application security testing tool, and in 2024, it got some serious upgrades. RapiDASTS didn’t just become more powerful, it became easier to use. For example, it’s able to provide support for Kubernetes operator testing, better automation and a much simpler interface. Now, it can export results straight to Google Cloud Storage, making collaboration more efficient.

Red Hat is building all this directly into our CI/CD pipelines, the very systems that developers use daily to build and release products. And for those who rely on tools, whether you’re developers, IT pros or end users trying to keep systems safe, a commitment to security-focused development really matters. In a world with constant cyber threats, knowing your software vendor is intensely focused on security, from the design phase through testing and component tracking, is reassuring. Red Hat treats security as a core part of quality, not just an afterthought.

‘Till we meet again in 2025

This year’s report is a reminder that security is always moving. With changes in how CVEs are reported, ongoing supply chain risks, the growing impact of AI and prioritizing vulnerabilities, there’s a lot that users must consider.

Having transparent reports like this one is so important. They help all of us—from developers to IT teams to curious readers like me—see what’s going on, understand the challenges and more informed choices. From my perspective,  it’s not just about preventing problems; how we respond to them is just as critical. The way the open source community came together during incidents like the XZ Backdoor? That’s the power of collaboration in action!

Read the full Red Hat Product Security Risk Report 2024.