Virtualization Technology News and Information
The Road to Opensource Stackrox

By Michael Foster, Principal Product Manager, Advanced Cluster Security, Red Hat

I first joined StackRox in 2020, coming from a Kubernetes-centric background and in the middle of the pandemic. At the time, StackRox was a startup hitting its stride, consisting of people located worldwide and filling a security gap massive Kubernetes adoption had created. StackRox was not open source, as there were few security tools, and no complete security platforms, that were. And while companies in the software industry, whether startups or big companies, look at open sourcing their products, it is a massive challenge and undertaking to do it and do it well. In April 2022, we open sourced the complete Kubernetes-native StackRox platform, and this is the story of how we did it.

StackRox was founded in 2014 at the beginning of the container revolution, but hit its stride in 2017 when the company pivoted to be a Kubernetes-centric security platform. Growing up with the many open source projects around us, as well as Kubernetes itself, StackRox was no stranger to open source and the benefits that came with it. The Kubernetes open source community rapidly expanded, pushing out four releases a year and constantly providing feature and stability updates. The StackRox team had to grow at the rapid pace at which that community was growing. We were there through all of the community's challenges, along with a few internal challenges of our own; because StackRox itself utilizes other open source projects and integrates forks of the Falco and Clair projects, our engineering and product teams had to be in tune with the communities from which we were pulling.

StackRox was the first company to build a security platform entirely around Kubernetes. We took on bigger and more established security companies and did it with open source assistance. We started with a subscription model for the paid platform, while discussing ways that we could give back to the CNCF community with an open source project of our own.

Our first open source project was KubeLinter, a command-line interface to identify misconfigurations in Kubernetes objects. It was created as a completely open source, community project, using security knowledge we'd acquired from supporting customers on StackRox. KubeLinter enabled developers to integrate security checks directly from the command line and their CI/CD workflows. It was easy to use and exemplified the term "shift left", referring to making security automatically accessible at development time, that we constantly see in security discussions. It rapidly became popular, with over a hundred users and developers forking it on GitHub.

We learned a lot from our first open source effort, like anything else you do for the first time. We faced significant issues from not preparing enough for a flood of contributors and involved users in the project. KubeLinter required community management and project infrastructures like contribution guidelines and issue and pull request triage. Without these processes, you rely on engineering to discuss changes in Slack threads, something that is not the best use of their time. The KubeLinter engineers got invitations to present at virtual conferences and meetups, events that are typically during workdays or late at night, when they should be getting time to relax. We were flattered by the project's success, even though we could have done more to enable its growth and development. Overall, it was a great example of filling a gap that the community was looking for and validating that we were on the right track.

Then, at the beginning of 2021, Red Hat acquired StackRox. The acquisition seemed to happen overnight, and with it, one thing was guaranteed: StackRox's code would be open sourced.

The first few months were set for the team to settle and onboard. Ali Golshan, a StackRox co-founder, led the open sourcing effort. At the time, the open source roadmap was uncertain, so the first effort we focused on was creating the framework for the project, the community website at We wanted to promise the community that our security platform would follow the Red Hat way and be freely available to the community. 

As the year moved along, it became more and more apparent that the community stood to gain a lot from a Kubernetes-native open source security platform. With log4shell and other exploits in the news, it seemed necessary to speed up our timeline to release.

To be considered an open source project, you simply need to have code that is publicly accessible-anyone can see, modify, and distribute the code as they see fit. But that is not the mark of a successful project and simply giving the code to the community didn't sit right with us, anyway. We desired community feedback, opened GitHub issues, made documentation updates, and released deployment documentation. All of these additional requirements led to some significant decisions and engineering effort.

A few of the questions and decisions included:

  • Where will we host the code?  Should we use our existing repositories or create new ones?
    • We decided to host the code in our organizational GitHub repository, letting us flip the switch easier and create a minimal barrier between our engineers and the community.
  • What license(s) will the repositories have?
    • With many repositories being set to Public, it meant reviewing each repository for the correct license. There have been a few cases of open source abuse from incorrect licensing, something that we never want to encourage or fall victim to.
  • What will the build process look like?
    • Red Hat Advanced Cluster Security has its own internal build process and it was challenging to modify this so that the community could have the open source builds.
  • Where would the community application images going to be stored?
    • Hosting the community images in and not Docker was partially due to the ease of the internal build processes. 
  • Who will lead community activities?
    • Finding volunteers to help with the community efforts is challenging. It is not usually a part of your job description and the effort scales depending on how much engagement and users participate.
  • Are we going to have online public meetings?  When?

There were many human considerations to add to the practical issues. For example, how would our paying customers react to the open source StackRox platform? There tends to be a significant amount of hesitation in open sourcing security applications, and for a good reason. A big concern is that the code is out in the open and left to scrutiny, where bad actors can exploit faults in your application. At Red Hat, we see this as a benefit and not a burden. Open source projects patch security issues significantly faster, and the openness of the code means that users don't have a "black box" security application.

Another human aspect is how to manage community contribution to the project. Since users are donating their time, we want to make it easy and rewarding for them. Our team can only directly test so many use cases, and we needed our community for feedback.

And lastly, as a surprise to us, staffing was a significant factor that delayed the launch. Several people moved on to new jobs, COVID issues lingered, and the war in Europe affected many of our European-based team members. We had to push back much of our work because assignees were simply not available.

In the end, the launch went well, with a few hiccups. Open sourcing a large, commercially successful software project is a significant undertaking, where your biggest problems will come from the most unexpected and unknown.

The end goal for our team was that our code be available for the community and that users had a safe forum in which to contribute and triage issues. Thankfully, after a year of hard work, we have achieved that. In large part, from the guidance of others who have traversed the open source road before us. Hopefully, this article will help you travel that same path in the future.


***To learn more about containerized infrastructure and cloud native technologies, consider joining us at KubeCon + CloudNativeCon Europe 2022, May 16-20.


Michael Foster Principal Product Manager, Advanced Cluster Security, Red Hat


Michael Foster is a Principal Product Marketing Manager at Red Hat (formerly StackRox). Michael is a passionate tech enthusiast and open-source advocate with a multidisciplinary background. His work allows him to review, discuss, and contribute to the CNCF ecosystem through various media forms. Michael enjoys helping people become more security-focused during their cloud-native journey and invites you to join the open source StackRox community at

Published Friday, May 13, 2022 7:32 AM by David Marshall
There are no comments for this post.
To post a comment, you must be a registered user. Registration is free and easy! Sign up now!
<May 2022>