The Cloud Native Computing Foundation (CNCF) recently published its cloud native survey based on data from its members and the end-user community. The report shows record adoption of containers and Kubernetes across the board and it underscores that security comes as the second challenge after training shortage when using or deploying containers.

As more organizations adopt containers and Kubernetes, more attacks target the software supply chain to exploit vulnerabilities related to cloud native technologies.

Data from the software supply chain security report by Anchor show that:

“Software supply chain attacks have impacted 62% of organizations surveyed”

Furthermore, per the state of the software supply chain report by Sonatype:

“There has been a 742% average annual increase in software supply chain attacks over the past 3 years” 

A software supply chain is composed of the different people, parts, and pieces that go into making software including software developers, libraries, tools, and processes. 

Although the software supply chain goes beyond containers and Kubernetes, the purpose of this article is to shed some light on 3 things to consider when securing your container-based software supply chain.

Shift Left and a bit Right

It’s almost impossible to predict where and when the next attack will take place. However, by having guardrails at every step along the way of the software supply chain, we not only can detect vulnerabilities but also do so promptly and at a cheaper cost.

 For example, vulnerabilities detected and addressed during a peer programming exercise can cost ten to a hundred times less than in a live production environment.

This means having scanning capabilities of images during build time, at container registries, and in runtime as well. To avoid finding the needle in the haystack, consider using Software Bills of Materials (SBOMs) and VEX.

In addition, runtime security is vital by monitoring running application containers and detecting and stopping suspicious behaviors. 

Set Up Policies 

In an enterprise, it’s unlikely that one team will be responsible for software supply chain security. developers might be able to scan and address vulnerabilities in their code, operators might pitch in by integrating certain guardrails in the CI/CD, and security professionals can provide golden images for base images to build on.

It’s important to have a standard for enforcing security. That way, regardless of who did what, you can make sure nothing is falling through the cracks. That’s when a policy comes into play.

In a nutshell, a policy is a set of rules that defines what should or should not be acceptable when doing something. Having this in machine-readable files is what we call Policy-as-Code (PaC). This makes the whole process repeatable and easy to automate.  

For example, you might have a policy that won’t allow pulling images from public container registries and another that scans container images and doesn’t deploy any containers with severe vulnerabilities.

Assume Some Vulnerabilities Will Pass

It is reasonable to assume that some vulnerabilities will pass regardless of having guardrails in the supply chain. Although this might be alarming given the log4j nightmare of December 2021, it’s important to have the capability to respond quickly. 

Being able to detect and isolate vulnerabilities is one thing, and being able to respond quickly is another.  It requires a deeper understanding of your software, skilled practitioners, and particular tools and processes in place. MTTD and MTTR are two KPIs to consider. 

Software supply chain attacks are on the rise. Regardless of what industry or business vertical you operate in. You always want to take a closer look and make sure you’re prepared for the worst.

Shifting mostly left and then right, setting and enforcing policies, and assuming some vulnerabilities will pass but can be mitigated quickly are three strategies that can make you sleep better at night knowing that your software supply chain is secure and your team is capable of not only detecting threats but responding quickly.