DevSecOps is a thing. But it is not new. Security’s impact on application development has been a consideration from the moment applications required to and from access from the external world. What the DevSecOps term/movement brings is security as an embedded aspect in the development process, not a check external from it. In the modern development world, not only can you prevent security from slowing down development, you can leverage it as a tool to make it go faster.
Shift-Left Security—Not Effort
“Shift Left” is the term applied to development practices that were traditionally outside of the developer’s hands, and are now brought into the developer’s hands. This should, at some level, spark anxiety in the heart of the developer who feels the potential burden of quality assurance, DevOps, and security. But shift left that increases the work the developer needs to do is not accomplishing the key objective.
The goal of shift left is not to give the developer more work—It is to address security and quality concerns closer to their root cause. And nothing is closer than code creation. This reduces the cost of addressing those concerns dramatically. Shift left should be nearly 100% automated. When the developer sees more things running during integration tests, or on all their environments, this does not mean they are the initiators, or that they need to manually intervene in the processes. Developers should not be building and implementing security strategy. But the security mechanisms should be executed as they write code.
This means that effective DevSecOps requires specific types of tooling that are conducive to automation without additional effort on the part of the developer. Shift left also does not mean that the roles and responsibilities of quality and security go away. Someone defines the security strategies, and decides what the delivery chain and tools look like to accomplish their goals and stay compliant. But their effort is predominantly strategic, and the pipeline and tooling do the dirty work.
With the power of security scanning, visualization, and anomaly detection at the level of coding, the development team is exposed to new opportunities to release functionality sooner, and stick with smaller development teams.
Security-Enabled Canary Releases
One of the holy grails of development environments is something called canary releases. This is where functionality is created on-demand, near the point of inception, and released to the user base without testing. It seems crazy, but it is extremely effective for a lot of applications. The mechanism for doing this is shipping code via containers, and controlling your DNS in real time to switch between container versions so that if something breaks, you can address it in minutes or seconds—and the negative impact is very small.
The problem with canary releases is that for them to be practical, your environment needs to be responsive (you can automatically release and destroy containers based on application feedback), and your user base and or transaction volume needs to be very high (high enough that A/B/C testing can be done on a significant number of users, without impacting a large percentage of your user base). So canary release to production might not be for everyone. But releasing new functionality in a fail-fast manner is.
Tickets in your backlog have to go through a series of internal validations before you get to work on them. Why not let developers pound through backlogs without any particular prioritization? Getting features out the door based upon on-demand feedback can be accomplished more easily with security that is baked into the development process. If your containers are enabled with real-time application security, then you can release a container with brand new functionality, and respond very quickly if there are issues.
Maintaining Two-Pizza Teams
Developing in a DevSecOps way does not only impact the application, it impacts the organizational structure of those creating it. Shift-left security means that fewer eyeballs need to be on security at any given time, with fewer gates with manual checks. Thus it’s easier to maintain small, efficient development teams, which is critical if your application is already moving in the direction of microservices.
Each service in a microservices architecture brings its own set of variables—developers, configurations, containers, images, etc. If each service increased the effort of the entire environment relative to its unique elements, then development teams would end up being even more complex than in the waterfall days.
So the only way to support microservices is to have a delivery chain that can abstract all the variables, and perform quality and security checks at a global and service level at the same time. Shift-left security means that even though security tooling runs at the developer’s level, its impact is global, and the way security runs on services has parity with the entire development organization. Without application, container, and service-level security at the time of coding, it’s very difficult to support the concept of microservices without an increase in each new service’s overall effort and considerations.
Historically, security has been one of the biggest roadblocks in software development processes. But as the DevOps movement has pushed delivery chains further, any bottleneck must be attacked head-on, and recent tooling in the market is taking security from an inhibitor to an enabler. Shift-left security is supporting more efficient development teams, microservices, and fast feature releases.