Red Hat moved on its long-standing plans to open source its Kubernetes-native cluster security product, adding extra flair to the move by naming it the StackRox project in honor of where the vendor initially received the platform.

Red Hat launched its Advanced Cluster Security for Kubernetes product last year. It’s based on technology the vendor picked up when it acquired Kubernetes security startup StackRox in early 2021. StackRox initially developed a Kubernetes-native security platform for cloud-native applications, containers, serverless, and Kubernetes targeted at DevOps and security teams (DevSecOps).

Red Hat integrated that technology into its OpenShift Platform Plus product.

Shortly after launching the security tool, Red Hat introduced the StackRox community as the first step in moving toward open sourcing the platform. That migration is now complete with users and developers able to test and contribute to the project’s codebase via GitHub.

Michael Foster, principal product marketing manager at Red Hat and a former StackRox-er, explained that the move to open source the StackRox base was a significant process.

“As soon as we got bought we knew we were gonna have to open source because Red Hat is just a huge purveyor of it and all its other applications are open source,” Foster said in an interview with SDxCentral. “We didn't build the product ground up to be open source, and in fact there's very few security solutions that are, so there's just so much in the background that we had to do.”

Foster described having to go to customers to make sure they were on board with the move and that there would be no sharing of anything proprietary in their respective code bases. The end product involved releasing around 12 repositories for the platform, making sure there were licenses for each of those repositories, and making sure that each continuous integration process was hardened and secure.

“You can imagine why you started to see some of these companies come out as open source from the beginning because it’s a little bit easier knowing that as the background,” Foster added.

The end product is a Kubernetes-native security platform that differentiates itself in the market. Foster noted that similar products like Sysdig’s Falco or Aqua Security’s open source Trivy products provide runtime or scanning, but not a full set of Kubernetes-native features.

“To get a whole platform that allows you to do all of that in the cluster, in an environment that's disconnected or in a hybrid cluster that you can install central in [Google Kubernetes Engine] and then install the sensors in [Azure Kubernetes Service] or [Elastic Kubernetes Service], and you can do all this for free,” Foster said.

The StackRox project launch follows Red Hat’s unveiling last week of new security features running on its OpenShift platform. These included a software supply chain security pattern, a technical preview of Ansible content signing technology, and several improvements to the aforementioned Advanced Cluster Security for Kubernetes services.

Red Hat’s move also continues a growing push by security vendors toward bolstering DevSecOps teams, which has become especially important in light of the recent Log4j and Log4Shell exploits.

Red Hat explained that the project will help “DevSecOps by integrating security capabilities within the development and deployment lifecycle.” This is the “shift-left” model of security that moves the security burden further toward the developer.

Foster did note that it would have been preferable to have had this project up and running before those exploits hit the scene, but he also explained that the speed in which those exploits were patched highlighted the benefits of an open source model.

“The tough thing about security and open source is it's this very specific niche of you need to know Kubernetes and security, and depending on what you want to do, if you are a developer or operator, you might use it differently,” Foster said. “We're trying to bridge the gap and say if you want to come and develop in StackRox, there's this path. If you're an operator and you want to use it in maybe some smaller, disconnected clusters, here's another way to use it.”