Understanding Why Kubernetes Is So Crucial To Software Supply Chain Security

 

As some of you might know, I am getting ready to take my AZ 900 exam soon.  This is the Azure Fundamentals cert that is offered by Microsoft.  Although this is one of the most basic certs that one can get, I got to tell ya, I did learn quite a bit about Azure so far in exam preps. 

One area that you may have heard of is that of “Kubernetes”.  Prior to my studying, I did hear about it on and off, but it is a huge thing for the Cloud, especially when it comes to software development.

So what it is, you may be asking?  Well, here is a technical definition of it:

“It is an open-source system for automating deployment, scaling, and management of containerized applications.”

(SOURCE:  https://kubernetes.io/)

But despite its importance, many organizations are now shying away from it almost entirely when it comes to developing new web applications.  The reason?  The security that is involved with it.  According to the “2023 State of Kubernetes Report” published by Red Hat, it is a huge issue.  Just consider some of these findings:

*67% of respondents have delayed or slowed deployment of new projects.

*37% have experienced revenue or customer loss because of Kubernetes concerns.

*38% cite other issues with Kubernetes strategies.

The source for the above stats is the actual report itself, and that can be seen at the link here:

https://www.redhat.com/en/blog/state-kubernetes-security-2023

So what can be done to alleviate some of the issues cited?  Here are some key tips:

1)     Use an SBOM:

This is an acronym that stands for the “Software Bill Of Materials”.  In fact, I just wrote an article about this for a client this past week, and essentially, this is a document that states all of the components that are being used to build a software application.  As you can guess, it is mostly all of the software tools that go into it.  But keep in mind that this is just a first step.  Documenting all of this is no doubt important, but even more so is testing all of these components to make sure that all of them have a reasonably high level of security baked into them.  A good example of this are the APIs that are used.  Many software developers use the ones from open-source libraries, and they often go unchecked for any gaps or vulnerabilities.  While the software developers need to make sure on their own that the components, they are using are safe, the hosting repositories have to take responsibility here as well.  For example, they need to make sure that they have complete documentation about all of the APIs, and they also need to make sure that they are updated with the lates patches.  Also, digital signatures need to be put into place so that the authenticity and legitimacy of the APIs can be confirmed.  More information about the SBOM can be seen at this link:

https://www.darkreading.com/application-security/building-a-better-sbom

2)     Using the VEX:

This is an acronym that stands for “Vulnerability Exploitation Exchange”.  This is a specialized type of documentation where software developers can report to the public about the vulnerabilities and gaps that they have found in the tools that they are using to build a web application.  An added feature of this platform is that it can even help prioritize the vulnerabilities which need to be addressed first. 

3)     Confirm that all is working:

Apart from the VEX documents and the SBOM, one of the final seals of approval is what is known as the “Attestation”.  This is where the managers of the DevSecOps team signs off that all and any vulnerabilities that have been found in the source code development phases have remediated, and should no longer pose a problem.  True, anything can happen in the future to the web application once it is handed off to a client, but at least there will be some piece of mind and protection knowing that you have done all in your power to address any security issues that cropped up.  You might even want to take this one step further and even Penetration Test the source code, and put that in the Attestation document.

My Thoughts On This:

This whole issue of Kubernetes Security comes down to one thing:  The resiliency of the software supply chain.  This can be compared to building a car.  For example, your rely upon different suppliers to provide the parts to it, and then they all get put together in once central location (at least this is my thinking). 

The same is true of creating web applications.  Apart from what it is stated in the SBOM, there also could be many other attributes, artifacts, and even objects that could be used as well.

While the above tips are meant to help secure your software development to a certain extent, the true level of security starts at the very beginning of the software supply chain.  Any weaknesses or gaps there can easily and quickly trickle down in a cascading effect.