Last Updated November 2^nd, 2022

There were plenty of hot topics this year at KubeCon – projects like sigstore are continuing their hockey stick adoption curves, the Gateway API talks were all packed, new projects like GUAC are showing huge potential, and technologies like WASM and eBPF are maturing their capabilities. But if there were two main themes of the conference, they were clearly security and observability.

As the distributed, immutable, ephemeral environments¹ we design expand and scale, so does their complexity. But the security of these systems is not faring well.

Complexity breeds misconfiguration

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments using containers, service meshes, microservices, immutable infrastructure, and declarative APIs. That means things get complicated fast since this model easily and quickly allows companies to go from having one of a thing to having hundreds of things. It’s one of the benefits and the curses of the whole cloud native movement to Kubernetes, et al. You can scale insecure systems, fast.

What Ayse Kaya’s KubeCon keynote and related research showed were survey results and hard data regarding public container vulnerabilities and security (the building blocks of cloud native). They found that complexity is breeding vulnerabilities; 60% of the top public containers have more vulnerabilities than they did a year ago, while 88% of developers said it’s getting more challenging to ensure containers are free from vulnerabilities, with complexity being the #1 contributing factor.

This is all a strong reminder that simple software doesn’t equate to cheap or weak. Instead, it translates to elegant solutions.

Simplicity is something we live and breathe at Seiso. It’s even in our name — Seiso is not only a play on CISO but it’s also a Japanese philosophy about cleanliness, order, and efficiency and being able to better spot problems.

But, why?

Now why is security so hot right at the moment? There are a lot of reasons. We know that the discovery of software inside containers is imperfect², but improving, so an increase in vulnerabilities could be ascribed to simply understanding more about what exists in an image now than we did before. However, certain ecosystems such as JavaScript, Ruby, PHP, and Java are known to be particularly heavy on dependencies, and thus understanding their dependencies is more complex, as is exhibited in Veracode’s chart below.

Source: Veracode’s State of Software Security, Open Source Edition

The reason for the massive adoption of these dependencies is to greatly reduce the time it takes to accomplish a developer’s primary goal – functional software. Typically, the less code you write, the fewer tests you need to write, and the shorter/easier it makes code reviews. But this is a misnomer. There is actually greater potential for bugs or vulnerabilities when using larger or more numerous dependencies, as shown by the following chart. And while stacking your work on top of someone else’s often gets the job done more quickly, it also causes components to be included in your project that aren’t necessary. These moving parts breed additional complexity, opening up your project to software supply chain attacks.

Source: Sonatype’s 2021 State of the Software Supply Chain

And all we’re talking about so far are containers. We have yet to mention the behemoth of complexity that is our favourite container orchestrator, Kubernetes. We know that Kubernetes, and the CNCF ecosystem, are quite complicated and moving quickly, so finding every means to simplify components is in our favor. I discussed the complexities associated with doing controls assessments in my lightning talk at Cloud Native SecurityCon.

Source: The Cloud Native Landscape

Some things are getting better

All that said, I’m happy to report that there is some consolidation and standardization occurring in the cloud native ecosystem. An overwhelming majority of projects, including fluentd, jager, and others are aligning on OpenTelemetry to standardize how Metrics, Traces, and Logs are generated and collected.

In addition, support for the OCI v1.1.0 distribution and image specifications (which are both due to release soon) are priorities for OCI registries, with their killer Reference Types feature (read more about that here).

I believe that security is a byproduct of modern, cloud native engineering practices. Focusing on quality and observability can improve our ability to accomplish many of the security aspects we gained from the traditional confidentiality, integrity, and availability models. What do you think? Share your thoughts on social media, or hit me up on Twitter or LinkedIn, and if you feel strongly about this (one way or another), jump on a call with me. I’d love to chat.

Footnotes

1: Sounil Yu has used the DIE triad (Distributed, Immutable, Ephemeral) numerous times as a part of his presentations on the Cyber Defense Matrix, and we agree with his stance on the topic.

2: Many SBOM generation and vulnerability scanning tools leverage package manager metadata to discover software in containers, however that’s not the only way software makes it into containers. Multi-stage builds allow you to copy the results of installation processes into a final container image without the associated metadata and using tools like curl or wget are another popular way to get functional code into your container image without using a package manager.