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.