How are organizations managing security and compliance for open source packages nowadays? As you may recall from our annual State of Kubernetes surveys, security and compliance are always a top concern. Our recent survey, The State of the Software Supply Chain: Open Source Edition 2021, gives some great insight into how people are addressing those concerns. It also gives some guidance on how to build your own policies.
This topic is especially interesting now because Kubernetes is changing how applications are architected, how those apps use and integrate with services, and how to configure and release applications.
That last part—the build pipeline, software supply chain, or whatever your organization might call it—is one of the under-appreciated beneficiaries of Kubernetes.
Kubernetes improves the secure software supply chain
Applications that run on Kubernetes run in containers, with each of these containers, well, containing various parts of an application. Among other things, Kubernetes standardizes these containers, but also how they are packaged, configured, and deployed.
This is a major change in how software is built and released. Before Kubernetes, there were no widely agreed-upon standards. Rather, there were many—oh so many!—to choose from. So, most people ended up customizing that process for their organization or, worse, for each app. Because Kubernetes standardizes how containers are packaged, you can now centralize and standardize how your own apps are built, configured, and deployed.
This opens up many new capabilities for managing and securing software, especially the third-party software you depend on, like open source projects. If you're putting your Kubernetes strategy in place, one of the first things you need to consider is how your apps are packaged, especially how third-party dependencies are packaged. This is just good and necessary, but now you'll have many better options for enforcing security and compliance controls and policy.
So, that's what brings us to this survey on open source packaging. Our survey asked 518 people about their packaging practices, regardless of Kubernetes use. Fifty percent of respondents were from companies with 5,000 employees or more, and 37 percent of respondents worked at organizations that have 500 or more developers. The survey focuses on open source packages, but I'd argue that the general guidance gleaned from the responses applies to all software, and likely public cloud services.
Let's look at a couple of the findings to provide the basis for thinking through how you're securing the build pipeline in your Kubernetes strategy.
What people need
One of our questions asked what could be improved about open source package management. As you can see in the chart below, most of the answers are associated with patching and establishing trust and transparency with the packages.
Areas of improvement for open source packaging, according to the State of Open Source survey 2021.
Kubernetes standardization of packaging doesn't address these needs on its own, of course. Instead, it opens up new, more transparent capabilities. For example, using buildpacks and the application templating in VMware Tanzu Application Platform gives you visibility and control over each container. This means, if you're following Tanzu container building and packaging best practices, you can trigger updates to those containers when new patches come out.
Next, let's look at how people want to solve those and other problems.
Again, many of these can be addressed by building these capabilities into your platform from the start.
Who's responsible for all this?
Another interesting topic in the survey was around which teams are involved in and responsible for securing open source use. From the respondents here, that job looks more fragmented than it should. In 65 percent of organizations, more than one team is responsible for OSS packaging. And while 47 percent of respondents said that the security team was responsible for OSS security in production, three other roles soak up that remaining 53 percent: DevOps teams, operations teams, or the development or platform teams that choose the software.
Obviously, many people will be involved in securing packaging, but you can see that there is still a lot of security policy being done outside of the security team. It's hard to say if this is good or bad. Perhaps that 53 percent outside of the security team are using reliable, self-service tools to secure their code. That would certainly be nifty!
This reminds me of a take on "shifting left" that I heard recently. Too many people, the person said, were using the idea of shifting left to put more responsibility on developers’ heads. In my experience, that's not the point of shifting left. Instead, the point is for, in this case, security to get involved earlier in the software lifecycle. This means either building the tools and controls needed to enforce policy earlier in the process, or security staff actually getting involved earlier. Usually it means both. But it certainly doesn't mean relying on developers to do it.
Dig into more
There's more in the survey that I haven't covered here. As you read through it, I hope you'll see how it can be used to start putting together how software is secured in your organization. Security concerns kept 96 percent of organizations from putting at least one open source package into production. The benefits of open source are so blindingly clear that if you're not using open source, you're missing out. I'd even say that if your organization is not using open source, you've got a problem on your hands and should immediately figure out why. VMware uses and contributes to open source heavily, as do our customers. If you're putting together your Kubernetes strategy (which is, of course, open source!), this is a good time to revisit and reinforce your software supply chain and make sure it's as secure as possible. Check out the survey to start thinking through all of that.
