devopsy.kinsta.cloud

Tag: red hat

IBM and Red Hat Disclose Discovery of More Than 400 Java Vulnerabilities

IBM and Red Hat this week reported they have identified and remediated more than 400 previously unknown vulnerabilities in Java libraries since launching a Lightwell initiative earlier this year.

Additionally, Lightwell Clearinghouse, a program that enables IT organizations to submit specific open source software dependencies for priority review and remediation, is now generally available.

Ben Bread, a senior principal product manager for Red Hat, said the 400 unknown vulnerabilities represent twice the number that was expected to be uncovered and there will undoubtedly be more to come as artificial intelligence (AI) tools are used to analyze more legacy code.

Additionally, DevSecOps teams should expect a similar number of vulnerabilities to be discovered in libraries created using other programming languages, he added.

While IT teams are contracting with IBM and Red Hat to fix vulnerable code in their IT environments, the code fixes developed are being contributed back to upstream open source projects under responsible disclosure protocols.

IBM and Red Hat are not disclosing how many organizations are relying on them to help generate the code needed to remediate vulnerabilities in their legacy codebases, but they are delivered via secure repositories that connect to existing processes for building and deploying software. Via the Lightwell Network, IT teams can access verified patches, bring remediated software into their existing workflows and establish an ongoing process for addressing vulnerabilities. The more automated those processes are using best DevSecOps practices, the faster that remediation effort becomes, noted Bread.

In fact, the ongoing discovery of so many vulnerabilities in legacy code will prove to be a tipping point that spurs adoption of scanners and test automation platforms as the building and applying of patches becomes a more standard element of software engineering workflows, he added. Organizations that today require three months to validate a code fix are not going to be able to keep pace with the vulnerability deluge, noted Bread.

It’s not clear at what rate vulnerabilities are being exploited in the age of AI, but the assumption is cybercriminals will increasingly use AI models to both discover and exploit vulnerabilities in hours. As such, rather than patching software once a month to fix vulnerabilities, DevSecOps teams now need to be continuously patching software as more issues are continuously surfaced, said Bread.

Unfortunately, there are still many organizations that are not taking the threats AI poses to application security seriously enough, noted Bread. Many of those organizations will soon discover just how many vulnerabilities exist in codebases that many are assuming is more secure than it actually is. It’s only when organizations are able to preview the vulnerabilities and exploits that AI models are able to discover and create that the real scope of the issue becomes apparent, added Bread.

More challenging still, the cost of discovering a vulnerability is now as low as $30, so the economics of application security only continue to favor the attacker, he noted.

Hopefully, it won’t require some type of catastrophic event for more organizations to pay more attention to application security in the age of AI. The issue, of course, is that it’s not so much a question of when a breach will occur but rather how serious it is given the nature of the vulnerability being exploited.

October 8, 2026
IBM and Red Hat Launch Lightwell Catalog to Automate Remediation

IBM and Red Hat this week revealed that Lightwell Network, a catalog of more than 6,500 application-layer dependencies that drives an automated vulnerability remediation service, is now generally available.

At the same time, the Lightwell Clearinghouse Premier service, through which application development teams can both access validated patches and coordinate remediation efforts, is now available to a limited number of organizations.

Ben Breard, a senior principal product manager at Red Hat, said collectively these two offerings will make it simpler for organizations to address 30 years of technical debt that is now being exposed by artificial intelligence (AI) models that make it possible to discover vulnerabilities and create exploits in a matter of hours.

At the core of the Lightwell service is a remediation engine that software engineers are using to
help identify, validate, and remediate vulnerabilities across critical dependencies embedded deep within modern software architectures. Lightwell then employs automation to backport critical fixes directly to specific, long-lived production software versions to reduce the amount of time required to update applications.

Organizations that subscribe to the Lightwell Network receive a continuous stream of digitally signed binaries, source code, and compliance artifacts, including software bills of materials (SBOMs).

Technology partners working with IBM and Red Hat to provide software artifacts and updates include Amazon Web Services (AWS), AMD, F5, GitLab, Intel, JFrog, Microsoft, NVIDIA, Palo Alto Networks, and ServiceNow. Providers of IT services that are also participating include Accenture, Atos, Cognizant, Deloitte, EY, HCLTech, Infosys, Kyndryl, LTM, NTT DATA, Tata Consultancy Services (TCS), and Tech Mahindra.

IBM and Red Hat earlier this year pledged $5 billion toward the Lightwell initiative through which more than 20,000 engineers are working to remediate vulnerabilities that might have been created by humans many years ago or an AI coding tool a few days ago. For example, IBM and Red Hat have remediated a vulnerability dating back to 2001 involving a legacy Apache Debian package that is still found in enterprise environments more than two decades later.

Ultimately, the goal is to rapidly improve the quality of the code that will increasingly be targeted by cybercriminals as they gain access to more advanced AI models, noted Breard.

Right now, access to advanced AI models from Anthropic and OpenAI is limited in the hopes that organizations will be able to remediate code before the volume of expected attacks starts to rise. However, cybercriminals are already using a range of AI models to discover vulnerabilities and craft exploits. As those AI models become more advanced in the weeks and months ahead, the more lethal the attacks against software supply chains will become.

The fundamental challenge is two-fold. Organizations that have deployed software need to discover and remediate as many existing vulnerabilities in their code bases as quickly as possible. Historically, organizations tended to wait months before applying a patch to ensure that any update made would not inadvertently take their applications offline. That process, however, now needs to occur in days and weeks to prevent cybercriminals from exploiting those weaknesses.

The second element is providing the maintainers of the open source software that is frequently being targeted with the tools and expertise they need to resolve application security issues. At the moment, organizations are discovering issues using AI, but few are contributing validated code to help open source maintainers resolve an issue. Far too many of the contributions being made are created using AI tools that often introduce additional vulnerabilities and weaknesses that adversaries might easily exploit in a downstream application, noted Breard.

The concern is that if the maintainers of the open source project are unable to address the issues, organizations will then create their own secure private forks of that code. The end result, however, would be a fracturing of an open source community in a way that might prove to be ultimately unsustainable, said Breard.

One way or another, a technical debt bill that many organizations have been ignoring for decades is now coming due. The issue now is finding the means to pay it off as quickly as possible without breaking the bank.

July 9, 2026
Akrites: The Latest Attempt to Protect Open-Source From AI Attacks Has Arrived
Akrites, a new Linux Foundation initiative backed by many of the world’s largest tech and financial firms, is the industry’s latest attempt to get ahead of AI‑accelerated software supply chain risks by hardening critical open source projects before attackers can exploit them.

On June 25, the Linux Foundation unveiled Akrites, a coordinated industry program designed to find, fix, and responsibly disclose vulnerabilities in open-source software exploited by AI-based attackers.

It’s not the first such effort. But Akrites may be the most comprehensive. One such initiative is Chainguard’s Athena coalition, which seeks to repair open-source flaws before attackers can exploit them. Another is IBM and Red Hat’s Project Lightwell, which has similar goals.

These two, however, seek to provide safe code and a platform for managing compliance, SBOMs, and governance across heterogeneous open‑source supply chains. Akrites’ mission, on the other hand, is to give the industry “one coordinated way to fix vulnerabilities upstream before they’re exploited.” In this approach, maintainers stay in control. Its focus is squarely on open-source software projects and ecosystems rather than on any one enterprise’s stack.

The reason all of these projects are appearing now is simple. Frontier AI models have proven they can scan large codebases and find exploitable bugs in minutes. How bad is it? At the United Nations Open Source Week conference, Linux Foundation CEO Jim Zemlin said, “The mean time to exploit a vulnerability in software is now negative seven days.” In other words, by the time you find out there’s a security hole in your program, the hackers have had a week to exploit it.

It used to be that discovering and weaponizing serious flaws required deep expertise. Now, anyone with access to a top-level AI LLM can find security holes.

So it is that the Linux Foundation is positioning Akrites as a way to move defenders together, rather than leaving maintainers and individual vendors to fight a rising tide of machine‑generated vulnerability reports alone.

The effort launches with an unusually broad coalition of cloud providers, AI labs, financial institutions, telecoms, and security vendors. Founding commitments come from Amazon Web Services, Anthropic, Chainguard, Cisco, Citi, Endor Labs, Ericsson, Google, IBM, JPMorganChase, Microsoft, GitHub, NVIDIA, OpenAI, RapidFort, Red Hat, the Rust Foundation, Sonatype, Vodafone, and Zscaler. You may have noticed that the companies I mentioned previously as having their own initiative are backing Akrites as well.

That said, as Mike Dolan, the Linux Foundation’s SVP of Legal, noted, “the space is crowded, and the track record is mixed. What I think is genuinely different here is narrow: one coordinated process, so open source maintainers face a single partner instead of a hundred separate reporters. It’s not to say everyone will go through Akrites – many may not, but those who do help reduce the noise for maintainers.”

All that AI-generated noise has been a real problem. On the plus side, AI reports today are far more accurate. On the negative side, that’s still an enormous number of bugs.

Moreover, vulnerability disclosure for open source is often anything but coordinated. Maintainers are flooded with overlapping or conflicting reports from multiple companies, governments, and independent researchers. Different teams may privately discover the same issue, develop competing patches or forks, and send them upstream via separate channels. Even when everyone is acting in good faith, the result can be noise, fatigue, and fragmentation.

Akrites is intended to replace that ad hoc model with a single, predictable entry point:
- A shared Security Incident Response Team (SIRT) will serve as the trusted coordination partner for open-source maintainers, receiving vulnerability reports and managing remediation across projects.
- A standardized, confidentiality‑first Coordinated Vulnerability Disclosure (CVD) process will rely on the familiar ecosystem of CVE identifiers, traffic light protocol (TLP) markings, common weakness enumeration (CWE), CVSS severity scoring, EPSS exploit prediction, SSVC decision‑support, and VEX statements to track exposure and communicate risk.
- Fixes will flow back to each project’s original home on the maintainers’ terms, with Akrites explicitly committing not to “fork and fragment” open source as part of its response.
The idea is to give maintainers one clear signal—validated vulnerabilities and well‑tested, coordinated fixes—rather than a flood of duplicative requests.

As Dan Lorenc, Chainguard’s CEO and co-founder, remarked, “The software supply chain is only as strong as the upstream it draws from, and we see how thin that layer really is. As AI finds more vulnerabilities, the industry will rush to patch them. Without coordination, those fixes will fragment across different patches and forks, and maintainers who are already overwhelmed, unreachable, or haven’t touched a project in years. Akrites gives the industry one coordinated way to fix vulnerabilities upstream before they’re exploited, with maintainers still in control. Now the work is making sure there’s always someone on the other end to catch them.”

To address that last issue. Akrites promises to step in when a critical package has no active maintainer. In that “maintainer of last resort” role, Akrites will coordinate fixes to the latest supported versions so downstream users aren’t left stranded when essential libraries or tools go unmaintained.

Given how many legacy components sit deep within modern dependency graphs, this piece may prove as important as the AI‑driven discovery story. Sonatype’s Brian Fox, steward of Maven Central, underscores the leverage of upstream work: one vulnerable component can lie beneath thousands of organizations, and a single upstream fix can reduce risk across an entire ecosystem.

We can only hope that Akrites is successful. Even though Anthropic’s LLMs are part of the problem, Anthropic’s Deputy CISO Jason Clinton said, “Open-source projects collectively underpin much of the internet, and the existing model for coordinated disclosure has been outpaced by how quickly AI can now find vulnerabilities. Getting ahead of that requires the industry to coordinate on findings and get fixes upstream before they’re disclosed and exploited. Efforts like Akrites drive this level of coordination at the scale and speed this moment requires.”

Akrites will receive initial funding from Alpha‑Omega, the Linux Foundation‑directed fund that has already backed large‑scale efforts to identify and remediate vulnerabilities in critical open-source projects. Needless to say, the Linux Foundation will welcome anyone else who wants to contribute engineering resources or additional funding to the cause.

If Akrites succeeds, maintainers could gain a strong, organized ally just as AI shifts the economics of attack toward speed. If it falters, the same AI‑driven pressure that motivated its creation will continue to stress the open-source software our economy relies on. Open-source development and security are no longer something that happens in basements. While individual maintainers are still the spark-plugs of open-source development, they, and even the largest companies, need a coordinated industry-wide security initiative like Akrites to enable them to create, maintain, and support secure open-source software.
June 25, 2026
Can Chainguard Save Open-Source Software From Mythos? Can Anyone?

IBM and Red Hat aren’t the only ones that mean to lock down open-source code against AI hacking tools.

Last week, IBM and Red Hat launched Project Lightwell to protect open-source projects with $5 billion and 20 thousand engineers. Not to be outdone, with tongue in cheek, Chainguard’s CEO Dan Lorenc announced a $50 million, 100‑engineer commitment as an attempt to “build new trust infrastructure for open source consumption.” Why? Because Lorenc argues that open source consumption “is fundamentally broken, and no amount of incremental improvement is going to fix it in time.” I wish I could disagree, but he’s right.

In his blog post, The Hardest Fork, Lorenc warns “Mythos is real,” pushing back on those who dismiss Anthropic’s scary code scanner as hype or a “marketing stunt.” He describes the Mythos findings as “novel combinations of a few dozen issues out of thousands of things every SAST [Static Application Security Testing] scanner already finds, chained together into something much worse.” In short, Mythos is “not a better scanner” but “a different category of threat.”

This means modern AI is ruining coordinated vulnerability disclosure into an at‑scale problem: “A model can now find hundreds overnight in the long tail. The existing system is not going to keep up, and we all need a backup plan for the vulnerabilities that don’t get patched.”

Lorenc argues that the basic way enterprises use open source is unsustainable under AI pressure. He wrote, “The way the world consumes open-source software is fundamentally broken, and no amount of incremental improvement is going to fix it in time.” Open source is “going to have to change.”

After all, he points out that “modern apps are layers of dependencies,” where changing one component can cascade through an entire stack, especially in large organizations with legacy codebases. On the maintainer side, he notes that “some of the most critical software on the internet is maintained by one or two people in their spare time,” and that “automated scanners and AI-generated reports have already been burying them in low-quality noise for years.”

What to do?

Plan A: coordinated disclosure that actually scales

In the near term, Lorenc says the ecosystem needs both “a Plan A and a Plan B.” Plan A is “coordinated disclosure that actually works at scale,” which he defines as “a single, trusted group that routes fully vetted reports and patches upstream, and supports the maintainers who want help.”

That’s all well and good, but who will that be? IBM and Red Hat have certainly thrown their hat into the ring, but do you trust them?

Lorenc is certainly right when he states this can’t be left to “a dozen competing groups filing noisy tickets” and instead needs “one coordinated effort that maintainers recognize and trust, so their reports get bubbled to the top of every inbox.” He cites Project Glasswing’s current performance as a warning sign, writing that “Glasswing has managed to get about 6% of its findings upstreamed” and estimating that “we can get normal coordinated disclosure working, under hard time crunches, for maybe 50% of projects at best.”

Plan B: a “maintainer of last resort.”

For everything that Plan A can’t reach, Lorenc says the ecosystem needs a fallback: “For all of those, and for the projects where maintainers can’t or won’t patch at all, we need a maintainer of last resort.” He anchors this in the traditional FOSS right to fork: “Open source gives you the right to fork. To take a project, assume stewardship, and keep it alive independently.”

What’s different, he argues, is scale: “We’re not talking about forking one project. We’re talking about building the infrastructure to fork, maintain, and distribute thousands of them. Under time pressure, with real adversaries on the other side. That’s the hardest fork any of us has ever had to make.”

That is the role he positions Chainguard as helping to fill, leveraging AI to make this kind of “maintainer of last resort” function viable. In a comment, Lorenc adds, “We’re not going to be the maintainer of last resort, we’re just going to help with it.”

Three futures for open source

Looking further ahead, Lorenc lays out three possible futures he calls “forks in the road”: “The naive one,” “The chaotic one,” and “The hard fork.”

In the naive scenario, he writes, “you do nothing and hope,” and imagines a world where “Glasswing patches everything upstream” and “every maintainer responds to every disclosure within 24 hours” — a world he says plainly, “We do not live in.”

Indeed, we already live in that one, and you may have noticed that not a day goes by that there’s not another new open-source supply chain incident. Just ask Red Hat with its spectacular npm breach. Yes, there is more than a little irony here.

In “the chaotic one,” he warns that “every major cloud provider forks its own versions of critical libraries, each with its own patch sets,” while “three different security vendors ship competing forks of the same logging framework.” That, he says, is “the default if we do nothing.”

I really, really hope that won’t be the case, but I find it all too easy to see it happening. It’s everything that’s wrong about proprietary code with an open-source wrapper.

The third path is “the hard fork: a deliberate, coordinated, painful decision to build new trust infrastructure for open-source consumption, including “one disclosure pipeline that works at scale” and “one trusted place for maintained forks.”

Lorenc closes his essay with a mix of realism and dark humor: “Is any of this actually going to work? I honestly have no idea. But we have to start, and as the Programmer’s Credo says, ‘We do this not because it is easy, but because we thought it would be easy when we started.’ This one doesn’t even feel easy at the start.”

No, no, it doesn’t.

June 2, 2026
IBM, Red Hat Launch Project Lightwell to Secure Open Source Software from Frontier Models

IBM and Red Hat are bringing together what they’ve learned from frontier AI models and 20,000 engineers to launch Project Lightwell, a $5 billion initiative aimed at helping enterprises better secure their open source software, work that has become more challenging in the age of such models as Anthropic’s Claude Mythos Preview.

Mythos and similarly powerful frontier models are quickly collapsing the exploit window for organizations, reducing from weeks to days or hours the time between vulnerability detection and patching. IT and security vendors are scrambling to develop AI-powered protections and processes to match the machine speed at which bad actors can now operate.

It can be particularly difficult in the open source world. Anthropic researchers earlier this month wrote about their findings after the first month of Project Glasswing, an effort the AI vendor created to let a few dozen companies and researchers use the Mythos model to find vulnerabilities and to develop advanced security tools to protect systems from exploits.

They wrote that they used Mythos to scan more than 1,000 open source projects, with the model finding 23,019 security flaws, including 6,202 deemed high- or critical-severity. The researchers noted the importance of open source software – “which collectively underpin much of the internet – and much of our own infrastructure” – and the challenges that frontier AI models present.

“The bottleneck in fixing bugs like these is the human capacity to triage, report, and design and deploy patches for them,” they wrote. “Finding them in the first place has become vastly more straightforward with Mythos Preview.”

Combining AI with Engineers

IBM Chairman and CEO Arvind Krishna echoed the sentiment in announcing Project Lightwell.

“Open source is the backbone of today’s digital economy and the foundation of modern AI, and we are at an inflection point in how it is built, secured, and scaled,” Krishna said in a statement. “With Project Lightwell, IBM and Red Hat are helping define a new industry model, one that brings together AI, engineering expertise, and trusted collaboration, to secure open source software at its source and across the entire supply chain.”

He added that “this is about strengthening trust in the systems that power business, government, and society.”

A Clearinghouse for AI Threat Information

Project Lightwell has a few parts to it. It will create a clearinghouse that will act as a coordination layer for enterprises, including using advanced AI capabilities to validate and test fixes across massive volumes of open source code. The clearinghouse will be available through commercial subscriptions that will enable organizations to integrate secure patches directly into their software supply chains, complete with validation and lifecycle management capabilities.

Enterprises can use the clearinghouse to share security issues they’ve discovered in their software versions, deploy validated patches in production environments that run from Red Hat offerings to code from the open source community, and share fixes upstream so open source communities can include them as they maintain the open source projects.

It’s an important step, according to Mitch Ashley, vice president and practice lead for software lifecycle engineering at the Futurum Group.

“Frontier AI has made vulnerability discovery cheap and abundant, which moves the bottleneck to validated, production-safe remediation,” Ashley told DevOps. “IBM and Red Hat are positioning a commercial clearinghouse to own that remediation layer across the open source supply chain.”

At the same time, the 20,000-plus engineers, using advanced AI technology, will work across upstream and enterprise environments to focus on upstream maintenance in tandem with others in the open source community, run through high-volume and AI-assisted reviews, triage, and prioritization of security flaws, and ensure that patch development, dependency hardening, and release engineering are secure.

Learning from Frontier Models

IBM officials said the effort builds on its and Red Hat’s broad experience in open source, enterprise AI, and security, and builds upon what they’ve learned in both Anthropic’s Project Glasswing and OpenAI’s Trust Access for Cyber, an initiative launched by the AI vendor in February as an “identity and trust-based framework designed to help ensure enhanced cyber capabilities are being placed in the right hands. This reflects our broader approach⁠ to responsibly deploying highly capable models.”

It follows what other vendors, including Microsoft and Google Cloud, are doing to improve security capabilities through the work they’ve done with Project Glasswing and other initiatives.

Leveraging Agents

Project Lightwell also will use new agentic security methods developed by IBM, along with the open source capabilities developed by both Big Blue and Red Hat. IBM uses more than 62,000 open source packages and has expertise in more than 10,000, and Red Hat – which IBM owns – is a key player in the open source space. Between the two, they have deep experience in such open source technologies as Linux, Java, Kubernetes, Terraform, and Ansible.

Through the new project, the vendors are extending their capabilities in the application field, including independent libraries, language toolchains, AI frameworks, and data streaming platforms, officials said.

IBM and Red Hat already are working with a number of Lightwell early adopters from the financial services world, including Bank of America, JPMorgan Chase, Citi, Goldman Sachs, Mastercard and Visa.

“Security and platform teams can no longer assume volunteer-paced upstream maintenance matches AI-accelerated exploitation,” Futurum Group’s Ashley said. “That turns patch validation into a procurement decision, and the regulated buyers already deployed show how fast trusted remediation becomes a purchased control.”

May 28, 2026
Red Hat Previews AI Agent Integration with Ansible Automation Platform

Red Hat today revealed it is extending the reach of its Ansible Automation Platform for IT operations to artificial intelligence (AI) agents, in addition to making it simpler to build AI agents using existing application development tools.

Announced at the Red Hat Summit conference, version 2.7 of the Ansible Automation Platform adds a technology preview of an orchestration engine for AI agents that are able to invoke capabilities via an integrated Model Context Protocol (MCP) server.

Sathish Balakrishnan, vice president and general manager for Ansible at Red Hat, said these capabilities provide AI agents with a trusted execution layer through which they can automate IT operations. The overall goal is to make new and existing libraries of automation playbooks available to AI agents in a way that can be governed using a set of policies enforced via the Red Hat Ansible Automation Platform, he added.

As part of that effort, the Red Hat Ansible Automation Platform can now serve as an OpenID Connect (OIDC) authentication provider for HashiCorp Vault, which is provided by Red Hat’s sister subsidiary of IBM. That capability makes it possible to issue short-lived, job-specific tokens for event-driven tasks to reduce potential risks.

At the same time, Red Hat announced that a version of its Red Hat Desktop tool for building applications now includes an instance of the Red Hat Podman tool for building and deploying containers that can be used to isolate AI agents in a sandbox environment.

Additionally, Red Hat has enhanced Red Hat Advanced Developer Suite to include a set of Red Hat Trusted Libraries and a set of AI tools to determine if known vulnerabilities in generated code are relevant to a specific application runtime.

Red Hat also announced the general availability of Red Hat Hardened Images to provide application developers with a set of more secure containers for building cloud-native applications, along with a Technical Supportability Review capability for Red Hat with AI that transforms manual environmental audits into a set of automated, self-service function that can validate more than 600 touchpoints.

Finally, Red Hat also announced it is making available a Red Hat Enterprise Linux Long-Life Add-On option for organizations that need support for longer than three years.

It’s not clear to what degree DevOps teams are adding AI agents to workflows, but it’s now more a question of what degree of trust they will place in them rather than if. The ultimate proof in the proverbial pudding will be determining to what degree AI agents will enable software engineers to reliably automate workflows at scale across increasingly complex application environments that have large numbers of interdependencies.

Ultimately, a small army of AI agents that are supervised by software engineers should enable organizations to deploy more applications than ever at higher levels of scale. The challenge, of course, will be ensuring that the AI agents confine their activities to the narrow set of tasks they have been assigned versus, for example, deleting a production database for one unexplained reason or another.

May 12, 2026
Red Hat Woos Corporate Developers with Free Instances of RHEL

Red Hat today launched an initiative intended to make a free distribution of Red Hat Enterprise Linux (RHEL) available to individual developers working within a corporate environment.

Chris Wells, senior director of product marketing for RHEL, said the Red Hat Enterprise Linux for Business Developers program will reduce the level of friction that developers of corporate applications might otherwise encounter.

Red Hat already has a long-standing developer program that is structured around organizations rather than individual developers. Rather than needing to become part of a program set up by an internal IT organization in collaboration with Red Hat, the Red Hat Enterprise Linux for Business Developers program provides application developers with direct access to a repository through which they can download up to 25 physical, virtual or cloud-based instances of RHEL. Previously, Red Hat also made available a free personal RHEL license option to application developers.

The overall goal is to not only encourage developers to build applications using RHEL but also reduce the level of friction that might occur when applications are deployed in production environments that are based on RHEL, said Wells. Otherwise, a DevOps team would have to migrate an application developed on another distribution of Linux to RHEL, he added.

Red Hat now provides access to instances of RHEL that can be deployed using traditional package management tools or as an immutable container. That latter approach tends to especially appeal to individual developers who would rather rip and replace a set of containers versus trying to apply a patch each time a new RHEL update is made available, noted Wells.

There are, of course, any number of additional commercial services that application developers can also subscribe to if needed, he added.

As always, there is an ongoing battle for the hearts and minds of application developers. In the wake of changes made to how Red Hat makes its offerings available to organizations, Red Hat is now clearly trying to make sure that application developers are able to build applications on top of its operating system without incurring any cost.

It’s not clear how many application developers are building software on top of RHEL, but should application developers opt for a different operating system, Red Hat is concerned those platforms might one day supplant RHEL in production environments. Red Hat is also hoping that DevOps teams will encourage developers to build applications on top of RHEL to streamline application deployments.

Regardless of motivation, making it possible for application developers to self-service their own for building applications is generally a good thing as long as it complies with existing corporate standards. The challenge is that many application developers when it comes to tooling have a lot of personal preferences that often fall outside the scope of those standards.

Each organization will, naturally, need to determine how much freedom of choice they want to provide application developers, realizing, of course, that most of them have the resources and skills required to set up their own application development environments. Fortunately, it’s also not too long before most of those developers also conclude they would prefer to have somebody else manage those environments on their behalf.

July 9, 2025
Red Hat Previews Series of Updates to Ansible Automation Platform

Red Hat today at AnsibleFest 2025 previewed support for the Model Context Protocol (MCP) developed by Anthropic within Ansible Lightspeed, a set of generative artificial intelligence capabilities based on large language models (LLMs) specifically trained by Red Hat and IBM to automate IT tasks.

Any LLM or associated AI agent will soon be able to invoke AAP to execute a playbook. Additionally, IT teams can make use of Ansible policy enforcement based on Open Policy Agent (OPA) framework to establish guardrails for any AI agent or LLM accessing MCP.

Red Hat also previewed a customizable dashboard for the Ansible Automation Platform (AAP) that makes it simpler to surface the economic value created by an automated workflow. IT teams will be able to ascribe a value to an automation that will then generate a dashboard showing its value based on how often it runs. That dashboard can then be saved as a PDF file or embedded directly into a spreadsheet application that can be shared with finance teams to help evaluate the return on investment in automation.

Finally, Red Hat and HashiCorp previewed additional integrations planned with the Terraform infrastructure-as-code platform following the acquisition of HashiCorp by IBM, the parent company of Red Hat.

Sathish Balakrishnan, VP and general manager of the Ansible business unit within Red Hat, told conference attendees there will soon be more out-of-the-box integrations to enable automated workflows that include Terraform IaC tools that are widely used to provision IT environments. The two platforms together provide a highly complementary set of capabilities for automating IT workflows on a more end-to-end basis, he added.

HashiCorp CTO Armon Dadgar, meanwhile, added there will soon be more Terraform hooks into AAP to provide deeper integrations into production environments.

It’s not clear how many DevOps teams are looking to integrate Terraform with Ansible, but the opportunity to automate IT processes more fully presents an opportunity to streamline workflows. The challenge, as always, is aligning what are often different teams within the same organization.

Regardless of the approach, it’s clear that as more workflows are automated, the overall level of toil experienced by IT professionals should sharply decline in the months ahead—especially as AI models are more broadly applied—even as the number of applications deployed in production environments continues to exponentially increase.

It’s not likely those AI models and agents will replace the need for DevOps engineers and IT administrators any time soon. However, the nature of those roles is likely to profoundly change as more tasks are assigned to AI agents that are supervised by an IT team.

In the meantime, those IT teams would be well-advised to start identifying which manual tasks being performed today might soon be automated using a combination of Terraform tools and AAP that share access to the same core AI model and agent technologies. Truth be told, chances are high the bulk of that list will be made up of tasks that no one really enjoyed doing in the first place.

May 20, 2025
Best of 2024: RIP CentOS. Hello AlmaLinux Rocky Linux, CentOS Stream or RHEL
CentOS 7’s official end of life is June 30th, 2024. What should a DevOps team do? Here are your choices.

Back in December 2020, Red Hat, CentOS‘s Linux parent company, announced it was “shifting focus from CentOS Linux, the rebuild of Red Hat Enterprise Linux (RHEL), to CentOS Stream, which tracks just ahead of a current RHEL release.” CentOS users were upset, and many never stopped using the last supported version of “classic” CentOS, CentOS 7.

Just how popular is CentOS 7? According to LanSweeper, an IT asset management company, 26% of the 200,000 Linux devices they scanned run CentOS. According to Web Technology Servers’ count, CentOS is still used by 2.4% of all websites.

Why have so many stayed loyal to a dying operating system? For years, CentOS was the default choice of web hosting companies. The Linux distribution was fast, free, and reliable. Sure, if you needed top-notch tech support, RHEL was the operating system of choice in the Red Hat Linux family. But not everyone needs handholding. If you could manage a Red Hat Linux variant without tech support, especially for the express purpose of web serving and related server applications in the Linux, Apache, MySQL, PHP/Python/Perl (LAMP) family, CentOS was all you needed. And DevOps, like anyone else, are happy to operate on the “If it ain’t broke, don’t fix it” sentiment.

Now, however, it’s time to change. “Operating on a deprecated version of CentOS poses several significant risks,” said Esben Dochy, Lansweeper’s senior technical product evangelist. “Without continued support, these systems will no longer receive critical security updates, leaving them highly vulnerable to cyberattacks. Additionally, compliance with industry regulations and standards will be jeopardized, potentially leading to severe legal and financial consequences. Operational inefficiencies are also a concern, as deprecated systems may face compatibility issues with new software and hardware, causing disruptions and decreased productivity.”

Using a deprecated operating system may be okay for personal needs – but not for DevOps teams responsible for an organization’s infrastructure. If you really, really can’t switch from RHEL 7/CentOS 7, you might consider purchasing RHEL 7 Extended Lifecycle Support.

CentOS Alternatives

So, what can you do? The good news is you have several choices:

Red Hat, of course, hopes you’ll switch to RHEL 8 or RHEL 9. The company tries to make the transition easier using Red Hat’s DevOps tools, such as Red Hat Insights (which comes with RHEL subscriptions), the Red Hat Satellite add-on, and Convert2RHEL to convert multiple systems at the same time. Concert2RHEL can also be used to move from other RHEL-style Linux distros to RHEL. Ansible users can also use this powerful infrastructure as code (IaC) DevOps tool to automate CentOS to RHEL.

For CentOS users who run instances on the major hyperclouds, including AWS, Azure, and Google Cloud, Red Hat offers Red Hat Enterprise Linux for Third-Party Linux Migration. These migration tools are designed to assist users of CentOS 7 in smoothly converting in-place instances to RHEL 7.

Some of you may be asking – with reason: Wait, doesn’t RHEL 7 also reach its end of life on June 30th? Well, yes, sort of, but not really. Red Hat recently announced a new program, Extended Life Cycle Support (ELS) for Red Hat Enterprise Linux 7. Subscribers get a four-year add-on to provide security patches and updates through June 30, 2028.

Or, if you’re bound and determined to stick with CentOS 7, you can choose one of several third-party companies that offer CentOS 7 extended support, with critical updates and security patches beyond the official end-of-life date. These include:
- CIQ Bridge: CIQ offers a service that extends CentOS 7’s operational lifespan by up to three years, including critical updates and security patches.
- OpenLogic: OpenLogic’s long-term support program extends support through December 2029. Indeed, it even provides support for the long out-of-date CentOS 6.
- TuxCare: TuxCare offers extended lifecycle support for CentO S 7, ensuring continued security and stability for systems that cannot be immediately migrated.
You could also move to CentOS Stream, Red Hat’s RHEL development Linux distro. Stream is a rolling-release Linux distribution, which means it continuously receives updates, including the latest features, bug fixes and security patches.

On the plus side, Stream is free and offers the newest updates. On the other hand, Stream is not designed for production use. As a continuously delivered distribution, it doesn’t have the same level of stability as traditional CentOS or RHEL. It also doesn’t have an upgrade mechanism between major versions, nor does it have commercial support.

From my perspective, Stream is fine for cutting-edge developers but not for business use. Even if you automate managing CentOS as much as possible with DevOps tools, it will be a pain to manage.

You can also switch to a third-party RHEL clone, such as AlmaLinux 8.10 or Rocky Linux 8.10. Both are free to use and work quite well. I use both on my own servers. I’m far from alone. According to statistics collected by the Fedora Extra Packages for Enterprise Linux (EPEL) Special Interest Group, a project that tracks the RHEL Linux family’s use of popular third-party Linux applications, Rocky Linux is now the most popular RHEL-style Linux with close to a million instances running, followed by RHEL and AlmaLinux.

Both AlmaLinux and Rocky Linux offer CentOS 7 migration tools. With Ascender, an open-source Ansible AWX fork, you can also automate the transition from CentOS to Rocky Linux. if you haven’t looked at either yet, it’s high time you did.

You see, the clock has run out. CentOS 7 has been a loyal servant for years, but it’s time to let that servant retire and move on to something new and safer. Yes, you can keep using it with third-party support, but it’s time to move on.
December 24, 2024
Red Hat Adds Managed Instance of Ansible to Expanding AWS Portfolio

Red Hat this week made available a managed instance of the Ansible automation framework on the Amazon Web Services (AWS) cloud.

Announced at the AWS re:Invent 2024 conference, Red Hat and AWS also revealed they have formally struck a strategic collaboration agreement under which additional offerings such as Red Hat OpenShift Virtualization and multiple artificial intelligence (AI) offerings will be added to the AWS Marketplace.

As part of that effort, Red Hat is pledging to bolster support for Red Hat OpenShift Service on AWS, a managed instance of a cloud-native application development and deployment platform based on Kubernetes and make it simpler to migrate legacy applications running on virtual machines to that platform.

Matthew Packer, principal product marketing manager for Ansible, said as more organizations opt to rely on managed services it’s become apparent there is a significant number of organizations that would prefer to rely on Red Hat and AWS to manage Ansible and other Red Hat platforms on their behalf. That approach then enables those organizations to reallocate more of their internal resources to building and deploying software, he added.

Each organization will need to determine for itself to what degree it wants to manage platforms such as Ansible themselves, however, in the age of AI the pace at which IT workflows are being automated is starting to accelerate. Many organizations will soon have to determine when it might make sense to rely on a generative AI tool to automate a task versus a framework such as Ansible.

In theory, a generative AI tool makes it simpler to use natural language to automate a task, but the output created is probabilistic, which means it needs to be reviewed by an IT professional before being applied. In contrast, playbooks created using Ansible are deterministic in that they run the same way every time. On the pulse side, Red Hat via a Lightspeed initiative launched in collaboration with IBM has made it possible to use a generative AI tool to make it simpler to create playbooks that are implemented using the Ansible framework.

Regardless of approach, the level of expertise required to automate an IT workflow continues to decline. Historically, creating a playbook using a framework such as Ansible required an IT professional who in addition to having a deep understanding of the workflow to be automated also possessed the programming skills required to invoke Ansible. With the rise of generative AI, much of the code required to automate a workflow can now be automatically generated.

Hopefully, the overall amount of toil that IT teams typically experience will continue to be reduced as more processes are automated. In fact, many of the routine tasks that today require a lot of time to perform may soon be eliminated. IT teams will then need to determine what tasks are best left to a machine to perform while focusing more of their efforts on orchestrating workflows across IT environments that are only becoming increasingly complex to manage.

December 4, 2024