Although there is an increasing number of applications being deployed on Kubernetes clusters, managing the applications and ensuring the security of the software supply chain continue to be key considerations. While there is a growing awareness of the need to produce a software bill of materials (SBOM), organizations need a better understanding of the different components of the Supply-chain Levels for Software Artifacts (SLSA) as a whole.

In this episode of TFiR Let’s Talk recorded at KubeCon + CloudNativeCon EU, Swapnil Bhartiya sits down with Kenny Johnston, Senior Director of Product Management at GitLab, to discuss the trends in securing the software supply chain and what is new in GitLab 15.

• There is a trend toward operationalizing cloud-native infrastructure, such as enabling developers to easily deploy it and ensuring that the software that is being deployed to the cloud-native environment is secure. Johnston shares his insights into the trends he is seeing.
• GitLab is seeing a pattern where larger organizations are creating platform teams to help their developers use tools that are endorsed by the central organization in order to ship code easily without some of the overhead. Johnston explains how GitLab is enabling that relationship between platform and ops teams.
• More applications are getting deployed to Kubernetes clusters closer to the edge. Johnston discusses the challenges with the complexity of managing more applications and operating a platform of that size.
• GitLab 15 aims to improve observability, security and compliance, end-to-end enterprise agile management, and data and MLOps. Johnston goes into detail about what is new in GitLab 15 and how it will help developers.
• There needs to be greater awareness of securing the software supply chain. Johnston feels that although one of the components of the SLSA levels is an SBOM and organizations are aware they need to produce one, other components play an important role and organizations need a better understanding of them.
• Organizations need more awareness of the different types of vulnerabilities so that organizations can better assess critical and non-critical vulnerabilities and know what they are shipping. Johnston explains why he feels this is so critical.

Connect with Kenny Johnston (LinkedIn, Twitter)

The summary of the show is written by Emily Nicholls.

[expander_maker]

Here is the automated and unedited transcript of the recording. Please note that the transcript has not been edited or reviewed. 

Swapnil Bhartiya: Hi, this is Swapnil Bhartiya and welcome to another episode of TFiR Let’s Talk here at KubeCon + CloudNativeCon in Valencia Spain, and today we have with us, once again, Kenny Johnston, senior director of product management at GitLab. Good to have you on the show.

Kenny Johnston: Yeah, Thanks for having me.

Swapnil Bhartiya: Today we are going to talk about, you know, version 15. Before we go there. Could you tell us, you know, you’re here at KubeCon, what kind of energy you have seen so far?

Kenny Johnston: Yeah, it’s been great. Lots of excitement. I’m definitely seeing a trend towards kind of operationalizing cloud native infrastructure. So that can be things like enabling developers to easily deploy to it, or ensuring that the software that you’re deploying to cloud native environments to clusters is secure. We’re hearing a lot about secure software supply chain and software bill of materials here at KubeCon. And it’s just great, you know, it’s a great showcase of open source community and the kind of power of open source KubeCon has become a kind of definitive conference for open source tech and for developer enablement of open source tech. So it’s been really exciting to get to be here.

Swapnil Bhartiya: Of course it’s running in production, but also the kind of use cases that are there. You know, of course, biggest skill companies are there, there a lot of adoption is smaller. What does it mean for your space because the expertise that people have in Kubernetes is also different, we are seeing adoption of look or low code. There are still, you know, a lot of Greenfield use because there are still folks who are new to Kubernetes. Yeah.

Kenny Johnston: Yeah. And I think that is one of the things that, I mean by operationalizing we’re enabling developers to more easily deploy to Kubernetes. The pattern that we see at GitLab is larger organizations have created platform teams that enable their developers to use tools that are kind of blessed by the central organization to ship code easily, to understand how their code gets shipped to Kubernetes environments and get all the benefits of Kubernetes without having to kind of manage some of the overhead. So I’ve definitely seen the kind of level of chloroformization around Kubernetes develop and you know, one of the great things about GitLab as a DevOps platform is one DevOps platform is we enable that collaboration between platform and ops teams who are managing and enabling deployment and development and direct app dev teams who are trying to get their applications to production.

Swapnil Bhartiya: Once again, there are certain, you can look at trends or the challenges that could be niche specific to a specific industry, but there are some patterns. So what kind of patterns are you seeing there?

Kenny Johnston: We’re definitely seeing the pattern of Kubernetes getting pushed farther out to the edge. So you see that in Telco Space, lots of applications that are getting deployed to Kubernetes clusters closer to the edge. And we also see the pattern of applications themselves. You know, the whole cloud native movement is that you’re getting more and more applications and the management of those applications. So things like service mesh and just being able to easily understand all the different types of services. My application, if I’m an application developer, I might own one service, but I interact with and deploy to interact with and deploy to environments that have hundreds of applications. And there’s a lot of complexity involved in operating a platform of that size that still allows a developer to focus on kind of their singular specific service.

Swapnil Bhartiya: No, let’s talk about the version 15. Which, the reason I ask this question, some of that either features, functionality changes will also reflect on what is going in this space as well.

Kenny Johnston: Yeah, it’s exactly right. so at GitLab 15, we’re really excited to be improving observability, our security and compliance, end to end enterprise agile management, and data and ML ops.

So in observability, last year GitLab acquired a company called Opstrace. That is an observability distribution that enables developers to out of the box have access to an observability platform. So they can not only collect the metrics that they need about their application in production, but also they can get integrations of that data directly into the, that context that matters.

So think about a developer who’s writing code. They want to know about recent errors that have happened in that directly related to that code while they’re writing it or a developer who wants to know about recent incidents that happened as a result of code that they’re touching so that they can make sure they’re running extra performance tests or regression tests while writing code, that kind of experience is something that only one DevOps platform and GitLab as one DevOps platform can provide.

In observability. We’re also improving the way that you can see the value stream of your application development. So our users use GitLab to do everything from planning, what work they’re going to do to delivering that work to production. And that kind of complete one viewpoint of your entire DevOps process allows GitLab to be the central place for spotting bottlenecks in that process.

Or places where you can improve as a DevOps team, whether that’s, “Hey, we really need to break issues down in a more robust way,” or, “We need to improve our time to merge,” or, “We need to make sure that our deployment process is testing correctly. Because we’re having a lot of failures of deployment,” or “We are seeing a lot of incidents and we’re not able to respond to them as rapidly as possible.” We’re going to be able to connect all of that together as the one DevOps platform to give you real true value stream viewpoint.

On security and compliance. I mentioned this has been a huge topic at KubeCon this week, but the idea of not only knowing the SBOM, the software bill of materials for what components are in your application, what dependencies you’re using, what dependencies those dependencies are using. Ensuring that they’re secure, but also attesting to the fact that what your developer wrote, that the developer is the right person. That the code that is tested is the same code that’s packaged and stored in your repository or your package registry. And that same package registry artifact is the same one that gets deployed to production.

There’s a movement called SLSA, secure software supply chain initiative that we call salsa, that kind of immediately gives you a categorization of how secure your software supply chain is. And GitLab is going to continue to invest in enabling you to out of the box, attain much higher levels like level three or level four in salsa designation, just by using GitLab as your one DevOps platform.

We’re also working to improve agile planning management. So think about if you’re an IT director or VP of product who wants to see how this initiative that’s being created in software is tracking. You can follow from the top level objective all the way down to specific merge requests that are having air cross tens of development teams to know the kind of current status.

And then lastly, you know, GitLab is seeing in the market that more and more applications are not just app code. They’re also data and ML models that are associated with that data. So think about the example of a Netflix style recommendation engine.

Developers are increasingly being asked to interact with those models and lifecycle manage the model, just like they do code. To know that the improvement to the model that they might have just tested and learned that improvement is actually an improvement. That the packaging of that model is actually easily deployable to production alongside the code. So we’re seeing, and we’re building a lot of capabilities to enable developers to not just manage code, but also manage models in data by, within GitLab.

Swapnil Bhartiya: So when you look at, you know, sort supply chain, you look at SBOMs. There are a lot of Open Source plug SPDX is there from the next foundation and there numerous other projects. But the main important thing is that awareness about understanding supply chain is not one monolith that all the code is coming from one source, their dependence on another.

Libraries, even the packages are coming from different sources, even though the same package can be created by different folks as well. Sometimes people don’t even understand what is there in their images. In their container images, what the dependents are, what the hard links are. So the first question is that how much awareness are you seeing? Because we can not solve a problem if people don’t even understand the software supply chain issue.

Kenny Johnston: I will say most of what we hear is coming from, “We are being told we need to produce a software bill of materials.” GitLab does that out of the box. In our ultimate tier, we have the capability to produce an SBOM that is multi-layered dependency analysis. That doesn’t just show you what those are, but also known vulnerabilities in those dependencies.

But yeah, I think oftentimes there’s a, “I’m being mandated to produce this document GitLab, can you do it?” And it’s really nice because we, our answer is yes, we do it definitively it’s available. It’s been a part of our product for some time.

Now it’s the next steps though, that I think any organization who’s being is saying, “I need an SBOM,” is tomorrow going to be asking for, “I need attestation of the kind of, I call it the chain of custody of software through my development process.”

And that’s what salsa levels are meant to provide. One of the components of the salsa levels is an SBOM. It’s in the build phase, but there’s also the other components of ensuring that a developer signed their commits, that you can confirm that it’s that developer, that the package was signed and not tampered with between when it was stored in a package registry and deployed to production. So all of those other things are kind of the things that someone who’s asking for an SBOM today is going to be asking for tomorrow.

Swapnil Bhartiya: One more problem with the SBOM or the whole software supply chain is: Where does the buck stop? You know, it does it stop at the end user who has to worry about it? At the vendor? The SAS provider? Or the maintainers? So because it’s not just the supply chain of that code, it also has so many parties are involved in that.

Kenny Johnston: That from my understanding, the research in many of the organizations that provide guidance here, it’s important to be aware of certain types of vulnerabilities. And then critical vulnerabilities is places where you should be looking for alternatives in your dependency tree.

So if you are using an open source piece of software and it has critical vulnerabilities, you should be looking to either use a different piece of software or perhaps you could work upstream to improve that software…not very likely in most organizations… But yeah, I think it’s that even just awareness of non-critical vulnerabilities that many of these compliance regimes want to make sure that you have kind of, at least you and your organization are aware that there are vulnerabilities in these dependencies that you’re shipping.

Swapnil Bhartiya: Kenny, thank you so much for sitting down with me. Of course, we talked about the version 15, but also you talked the most important discussion that is going on these days is offer supply chain. There is still a lot of confusion, misunderstanding, and lot of awareness is needed.

And the most important thing was also that people still don’t understand whose responsibilities is to not only producing SBOMS. But also there were a lot of effort initiative from the federal government also last year, [inaudible] also there. So let’s hope that by next KubeCon it will become a kind of solved problem, but security is kind of a process. It’s not a product.

Kenny Johnston: So yeah, it’s an evolution. I think GitLab can certainly help organizations on their way along that journey. And there are, there are parts of our tool that make that easy out of the box, but you’re right. It’s important to not just take for granted what you get from a vendor, but to deeply understand your kind of security risks as an organization. So I appreciate you having us on the call today or on the podcast today.

[/expander_maker]