Containers have changed the security conversation in many organizations
There are many reasons why containers have become popular in recent years. For one, they help developers maintain consistency across platforms and through the software delivery chain. As a result, it’s now the norm to consider whatever is in the container to be the developers’ responsibility, while operators own what is outside of it.
Kubernetes has challenged that paradigm even further by providing developers with access to its native API, affecting operational parameters.
You could say that software is eating the world, open source is eating software and developers are eating the software life cycle!
Kubernetes, however, was built by system developers and (arguably) for system developers and has evolved into the golden standard of an “un-opinionated PaaS”—and in a large enterprise, that is still owned and maintained by an operator. As a result, one of the main trends in enterprise adoption has been to find operating models which empower devs while providing operators a good level of control over policy creation and enforcement.
User != Buyer
Security is a great example of the need for this new equilibrium. With the explosion of open source software (which is being leveraged in both open and proprietary applications) many security teams understand that their risk has shifted left, and in a cloud-native world that is moving faster than ever toward production. Snyk’s latest “State of Open Source Security Report” shows a significant increase in vulnerabilities—almost doubling in just two years. More importantly, the report also shows companies are struggling to tackle container security, with a four-fold increase in container vulnerabilities in 2018.
Unsurprisingly, the report shows a need for developers to be enabled to take more ownership for security. The figures reveal 80% of developers believe they should be responsible for the security of their open source code, yet only 30% rate their own security knowledge as “high.”
As a consequence, the security industry is experiencing a decoupling of the user and buyer personas for software security tools and services at large enterprises. Security officers still hold the budget authority in most cases, but increasingly, they fence off a good chunk of it for tools chosen by developers to be used in their development workflow to help them deal with security issues as early and as often as they commit code.
New Shared Tools for a New Age
The above is easier said than done, when almost all of the security industry is geared toward servicing security teams and helping them deal with “those pesky software engineers.” The challenge for providers in this rapidly changing reality is to provide tools designed for developer responsibility but also for joint accountability: the best user experience for the people “on the left” with the right levels of control and observability for the people “on the right.”
What do these tools look like? They move at the speed of code at the source control and IDE stages (rather than snapshotting or cloning repos for static analysis) to allow developers to find and fix issues early; they provide strong complementary gates at the build, CI/CD and registry (push) stages; they place clear controls at the gates to deployment, whether by using Kubernetes or OpenShift admission controllers, or integrating within a `cf push` command (as examples); and perhaps most importantly, they prioritize actionable insights over just plain data.
Shift Left Sometimes Means ‘Let Go’
In an operational sense, shift left doesn’t mean that platform or DevOps teams should own actions more to the left, encroaching on developers. Quite the opposite: It is about developer empowerment. With more bits of open source and proprietary code coming from increasingly disparate origins and sitting in increasingly distributed systems, this becomes at least as big an imperative for security teams. While CSOs and CISOs remain accountable, more and more of them bravely face the cloud-native future by allowing developers to be more responsible for the security posture of their own apps.
(Originally posted on Container Journal)