Is security shifting left or right?

December 2021: everybody was left hustling to find out if their software includes log4j software. The first step towards finding and patching the publicized security vulnerability CVE-2021-44228.

A story from the trenches

A platform team from one of our customers described their management of the log4j incident. 

Research

The first thing the platform team did was to identify all the components that contained the CVE. They did this using our Security Pack, which includes Starboard and Trivy. log4j was easy for them to handle because they were able to identify it on all running workloads in their clusters. This research was the prerequisite for an effective conversation with the development teams. 

Communicate

Then the platform team was ready to talk to the development teams. Rather than throw the information 'over the wall', the platform team spoke to the product owners (POs). Communicating the urgency to the POs then led to shifting priorities in the teams. They then knew how and why they should focus on the vulnerability.

Adapt

In effect, security and I&O experts acted as consultants. This could sound ground-breaking,  especially since many of us in IT are used to a model in which security is largely divorced from software development.

Shifting the paradigm

If you are reading this, you are probably interested in DevOps. In their book Discover to Deliver, Ellen Gottesdiener and Mary Gorman, describe modern software development as an infinite loop:

There's always something going on. Unfortunately, there's no end-point you can latch onto in order to take on tasks that used to be outside of core software development — tasks like security.

A paradigm shift is required. Although you may have heard of shifting left or shifting right, this language implies a start and an end-point, which may be less useful in the DevOps world. 

We are used to hearing about continuous integration (CI) and continuous deployment (CD). Why not continuous security?

This is especially important since attackers have also shifted their focus to applications. In fact, over the past five years, out of all published vulnerabilities, 76% were from applications. 

As organizations mature in their cloud native journey, there will be a move from securing the infrastructure to securing applications — a win on the security and the agility front. The story above exemplifies that the organization in question has truly adopted cloud native culture.

Security is no longer limited to infrastructure. It also can't be assigned to a security team at some specific stage in the development process. On the other hand, even if your team is composed of engineers skilled in agile and DevOps, they might still lack knowledge of secure coding. Hence, a big chunk of the paradigm shift is about education. Another piece of this is equipping developers with the correct tools to get this new job done. 

What happens now?

Next to shifting vulnerability scanning into the pipeline, another major change we see with security is that cloud native security is also better on the 'right' side. The dynamic environment has its new challenges but also lots of advantages. 

Security needs to get away from static lists towards dynamic security tooling. Oftentimes, this allows having even more fine-grained permissions that are kept up to date automatically through policies. We see security departments starting to implement their checklists in software now. The nice thing is that in a cloud native world, those tools are usually wrapped around workloads (mTLS, audit logs, vulnerability scanning, etc). The developers of the applications do not even have to understand all of it.

As with all things open source, researching, evaluating, integrating, and implementing are time-consuming and resource-intensive, and there are many open source tools available in the cloud native landscape. However, if you would like the advantages of DIY without the hassle, Giant Swarm is now offering a Security Pack. 

For more information:

Read our Managed Security Solution announcement or simply contact us — we're happy to help.

You can also check out the complete list of the software affected by the log4j vulnerability.