Shift Left: Where Cloud Native Computing Security Is Going

At Kubecon Europe 2022, some of cloud native computing’s best and brightest security minds talked about where we’re at now and where we’re going. The really short version is, “We’ll be shifting security left into DevSecOps as fast as we can.” But all the experts admitted, that’s easier said than done.

The fundamental reason security is shifting is that threats can come from anywhere. Owen Garrett, head of products and community at cloud native observability firm Deepfence pointed out that “In the old days when we built an application it was like a castle. We protected it by building a big wall and putting a gate and a gatekeeper because we knew what the castle was and where people entered, and we could protect it by stopping people coming in.”

That’s no longer the case. Today, Garrett continued, our applications are no longer castles, they’re “like cities, that grow and change over time. They have porous boundaries, you can’t put a wall around it, and the threats come from outside or inside in a manner that opponents within the city aren’t fully trusted. So you have to take a much broader team view of how you can secure applications. That spans from development through to operations in order to ensure the integrity of our application.”

Cultural Change

As Liz Rice, cloud native security firm Isovalent‘s chief open source officer said, “There’s a cultural change there around the speed and agility of how things are developed and deployed.” In addition, “in cloud native, we deploy applications into pods and those pods get IP addresses allocated dynamically. A traditional network security tool using IP addresses and port numbers isn’t really meaningful in a cloud native environment. That’s where the cloud native generation of security tools stands head and shoulders above the traditional approaches for what we’re trying to do today.”

Therefore, Andrew Martin, CEO of cloud native security consultancy Control Plane, noted that we’re seeing a “morphing of responsibilities. Gitops gives developers access to provisioning infrastructure, thus making decisions that potentially affect the security of the entire system.” This means “security becomes everyone’s responsibility, he said. “This is why the automation and the shift left is so vital. In order to move quickly, we need to apply the security testing tools closer to the developer, and also ensure that everybody has that level of understanding as to what the implications of their infrastructure changes could be.”

What’s Different Now?

But, as one journalist asked, “We’ve been hearing about team responsibility for security for ages, what’s different this time?”

Well, for one thing, we don’t have a lot of choice in the matter now. You either get it right or your software ends up in a security news story headline. That said, Rice admitted, “it’s not straightforward and simple. And it requires a cultural change.”

Regarding that change, Martin said, “The actual concrete implementation of this to have a security champion within the team. That person must also be empowered to put a hard stop on features shipping unless it has the correct security criteria checked off.” That said, Garrett added that security’s not one person’s job. “Security responsibility is now shared across teams.”

Automate Security

At the same time. Gaurav Rishi, Kasten by Veeam’s VP of product and partnerships, said that while “no one likes going through a checklist,” this can be addressed by automating security using such methods as backups and data protection via policy-as-code.

As much as possible, all agreed, security must be automated. Garrett said what we all know, “What motivates developers is getting things done, A lot of developers don’t have the global perspective or, or even the maturity in the industry to take security as anything other than just an impediment to getting the job done.”

Part of what can be done is to make it valuable for developers to find security vulnerabilities before they can become security problems. As Rice observed, “It’s very striking that we give hackers measurable rewards for finding vulnerabilities in bug bounties and so on, but I haven’t seen anything around the next step — rewarding people for fixing them.”

Of course, it doesn’t help that security expertise is spread so thinly. Rice replied that you must have the right tools in place to cover scanning, signing, runtime protection, and the rest, and to apply them at different development stages and on different infrastructure layers. So, “You don’t just have one layer, you have lots of thin security layers that build up into a thick layer.”

Creating a Software Bill of Materials (SBOM)

The experts also talked about the difficulties of creating a Software Bill of Materials (SBOM). Sure Garrett said, “The automotive industry is very good at maintaining inventories of what went into the vehicle. But the reality is, it’s very, very difficult to maintain an accurate SBOM across the entire infrastructure. That’s because each third-party add-on has its own dependencies and components, and the overall situation is one of constant flux.”

Still, everyone agreed, SBOMs need doing. They hope that projects such as the  Open Source Software Foundation (OpenSFF) Alpha-Omega, which seeks to improve the supply chain security of most critical open source projects, will hopefully improve everyone’s SBOM security.

Finally, as I think we all know, security, like it or not, is becoming an ever more critical problem for cloud native computing. We must deploy it using automated tools as far to the left as we can while encouraging everyone to take security seriously. We really don’t have any choice in the matter.