Building and deploying containers has become the de facto standard for cloud native development. Everything at Google runs on containers, from search to Gmail to YouTube. Now, there are many reasons for this, especially for large systems, working with containers is much easier than working on a single monolithic code base. Container-based applications are generally smaller, more lightweight, and thus their code is usually easier to understand.

A CI/CD pipeline makes it easy to quickly build and test new containers while Kubernetes makes it a breeze to deploy, upgrade, and scale them. Containers also provide consistency. Container-based applications are predictable environments that are isolated from each other. It really does not matter if you're deploying to development, staging, or production. Your code will always behave the same way. Containers provide security benefits as well.

Resource isolation ensures that a problem in one is less likely to affect the others. When a single container is compromised, the damage is usually limited. Containers allow for smaller, more granular permissions, which makes them easier to track and limit. And containers only require a minimal host operating system which creates a smaller surface of attack. Developing with containers offers many advantages, but they do not solve every problem. It does not eliminate the need for thorough security testing.

Like any other code, a container can pass unit and functional tests, but still contain critical vulnerabilities. Bugs that break user functionality are easier to identify. Developers and QA engineers understand what actions are allowed and what the results should be. Security vulnerabilities can be much more subtle. And because containers generally have a short lifespan, development teams usually are pushing out smaller, more frequent updates. This quicker pace can be a boom for developers, but a burden for the security team.

Traditionally, security testing tends to be very manual and slow. All proposed changes have to be reviewed and approved. Every new container image needs to be scanned for vulnerabilities and the entire system needs regular penetration testing to reveal any problems. Because of all the work involved, developers can often push out changes faster than the security team can keep up.

The solution to this problem is to shift left. Instead of relying upon a security team to identify the flaws at the end of the development process, security needs to become everyone's responsibility. Parts of the security review process should be shifted left so that they happen much earlier. Also, automation should be used where appropriate. In this way, the security team can properly scale and keep up with the quicker pace of development. Now, in order to achieve all of this, Google has provided a few important tools to help build, enforce, and automate your security process.