Shifting security left means culture, not just tools

This is the second part of a four part series about building your Kubernetes AppSec strategy. The first part is here.

As organizations embrace DevOps practices and transform how they build and maintain applications, many aspects of application development are changing.

Traditional systems administration has changed in many organizations, with the embrace of site reliability engineering and a philosophy of “you build it, you run it.” Networks are increasingly described in software, especially with the rise of service mesh. Monitoring conversations are moving from solving for known unknowns to focus on observability and unknown unknowns. The pattern is clear. We are moving more and more aspects of running applications toward developers. When it comes to security, this movement is really just beginning. If we want security to make this move effectively, we need to carefully select tools and deliberately build culture.

Containers as the unit of software

Let’s use containers to explore the topics of tooling and culture. As noted in the previous post, containers are increasingly becoming the standard unit of software. We build images, discuss them across organizational boundaries, make assertions about them, and generally use them to abstract us from other platform or language specific packaging.

The idea of a single package format, a package repository, and a mechanism to install those packages in production isn’t new. For instance, RPM packages and repositories and tools like Yum arguably fit this model. But there are two important differences when it comes to containers that are more organizational that technical:

1. Use of operating system packaging was often dealt with by a separate team somewhere in the wider operations organization.

2. Few organizations use just one packaging format. Each different operating system, or different programming language, has its own packaging toolchain.

What’s new with container images is that the responsibility for packaging is invariably passing to developers and the development teams. That’s why you find more than 2 million Dockerfiles publicly on GitHub, for instance. Testing and security tools built for a previous generation of packaging, and previous organizational norms, don’t fit nicely into modern developer workflows and toolchains. As an example of this, the concept of patching is increasingly moving from making a direct change in production to rebuilding and redeploying immutable artifacts.

Curious about container vulnerability management? Learn more about how Snyk can help you secure your containers.

Developer-centric tooling

The standardization around images provides many opportunities for us to build truly developer-centric tools that embrace the shift we are seeing. What are some of the properties of this new generation of tools?

• Usable locally - most developers write and read code on their local machines, and tools that work locally allow developers to understand a new domain

• Integrated with IDEs - where developers use integrated development environments, the point is that the tools they use should be integrated

• Interact directly with source control systems - source control management system, increasingly Git based, dominate developers day-to-day work. Developer tools need to become part of the team, especially as more developers adopt approaches like GitOps

• Configurable in CI/CD pipelines - Continuous integration is a prerequisite for effective software delivery and the perfect place to integrate quality controls where the feedback loop for developers is still short

One of the advantages of tools that span the software development lifecycle (SDLC) is that it helps developers understand the application better, and voids the dreaded “works on my machine.”

A devops culture of sharing

Quality and security are not the sole domain of developers; skilled operators and security experts are still essential to success. Experts are needed to guide and educate about shifting security left as responsibilities are pushed down to development teams. Just as site reliability engineering (SRE) teams support developers to help them better operate their applications, security needs to adopt the same mentality.

Tools that facilitate sharing between different disciplines, often across organizational barriers, are required not just desirable. The alternatives, either separate functions with their own competing tools, or one group with a second-class experience, are insufficient. Operators using one set of tools, and developers using another, will only lead to organizational silos. This rarely means one tool to rule them all. Modern developer tooling focuses on application and on feedback into the development process. Developer tooling should integrate well with operations tooling (capable of low-level investigation and over-time reporting) and work with the abstractions used by the different roles.

Conclusion

Conversations about “shifting left” often talk about moving responsibilities from classic IT functions toward development teams, with the intention of speeding up the feedback loop. But fundamentally changing how we work, without also changing the tools, rarely works. The development of complex software is itself a complex socio-technical system. As we involve developers more deeply in owning security challenges, we need to also appreciate the tools they need will look different from the previous generation of operator-focused tools.