We live in a world in which threats are forever evolving and the type of security tools that were effective in the past are not necessarily the tools that will work in the future. At one point in time, if you had a firewall at the edge of your network then you were considered safe. Now, a great deal of the threats are already inside of your network.

One of the most common types of threats these days are supply chain related. You may ask what encompasses a supply chain attack. A supply chain attack usually means that a hacker is taking advantage of a flaw in software that is a component of that software or they are injecting their own code in a trusted repository. The question then becomes how you know if you can trust the components in your software. The real answer is there is no way to really ever fully trust the supply chain, but you can get pretty close.

You can think of this as it relates to food. When you look at food packaging, you can instantly see what the food is made up of by all of the ingredients listed. You know that the food might have flour, sugar, milk and whatever else makes up that food. Additionally, the food has some kind of indicator for date of manufacture and some kind of code that can be used to trace the food and manufacturing back to the manufacturer. Food ingredients are analogous to what a SBOM (Software Bill of Materials) is. An SBOM lists the ingredients of software along with versions, licensing, and more. An SBOM by itself does not provide any security. The SBOM only lists the makeup of the software.

You might be asking at this point how you derive security information from an SBOM. We have already stated that the SBOM contains a bunch of information around the components and versions of each component. A vulnerability scanner can read these SBOMs and match them against public vulnerability databases to see if the components have any known vulnerabilities. Going back to the food analogy, you can think of the vulnerabilities as akin to food recalls. If you have ever got a notice that the bagged lettuce might not be too good and you should return it to your store, then you understand. The same thing happens with vulnerabilities. You get a notice that a component could be compromised, and you should use the new (patched) version of that component.

What tools can help you generate an SBOM?

There are a number of options to help you get a grip on the security posture of your cloud native application. The first thing you will want to do is create an SBOM. You can do that with many tools, but I recommend creating an SPDX format SBOM (there are others) with a tool called Syft (https://github.com/anchore/syft). This tool can be run against a container image and it will generate an SBOM - which is just a JSON formatted file that contains all of the information of the packages, versions, licenses, and more. Below is a quick way to use the tool:

syft <image> --scope all-layers

What tools can you use to check for vulnerabilities?

My tool of choice is Grype (https://github.com/anchore/grype). Grype is great for scanning an SBOM and listing out the vulnerabilities. You should remember that you are only as good as your last scan. Threats are constantly evolving and so is your security posture. Vulnerability scanners should run every time you commit new code as well as on a schedule. Remember that these tools just need to read the information from the SBOM file in order to test for vulnerabilities. Below is how you can run Grype on an SBOM file:

grype./file.sbom

Is there anything that can give an overall view into my security posture?

There is a great open source suite called OpenClarity that provides security tools for cloud native applications. The suite is continuously being built out and currently contains three main parts.

1.      KubeClarity (https://github.com/openclarity/kubeclarity) - a tool for detection and management of Software Bill Of Materials (SBOM) and vulnerabilities of container images and filesystems

2.      APIClarity (https://github.com/openclarity/apiclarity) - an open source, cloud native visibility tool for APIs that utilizes a service mesh framework to capture and analyze API traffic as well as identify potential risks.

3.      VMClarity (https://github.com/openclarity/vmclarity) - an open source tool for agentless detection and management of Virtual Machine SBOMs and security threats such as vulnerabilities, exploits, malware, rootkits, misconfigurations, and leaked secrets.

All of these tools contain an interface that lets you see your current security posture at any time. The tools can all be run on a command line, as part of a pipeline and/or as a dashboard. Below is an illustration of KubeClarity:

The nice part of the OpenClarity suite is that you can pull in all of the information from your favorite tools and then correlate the various sets of data.

For more info go to:

https://outshift.com/open-source

For an all in one cloud native application protection suite checkout:

https://panoptica.app

++

Join us at KubeCon + CloudNativeCon North America this November 6 - 9 in Chicago for more on Kubernetes and the cloud native ecosystem. 

##

ABOUT THE AUTHOR

Michael Chenetz

Michael Chenetz is the head of technical product marketing and has lead cloud strategy in the CTO org for Cisco. Michael has consulted for many fortune 500 companies in Networking, Security, and Cloud. Michael is the host of the popular podcast, Cloud Unfiltered that discusses trends in cloud native technologies. You can find Michael speaking at most major cloud native events and online media outlets.