It’s 2019, and IT organizations everywhere are supposed to be living and breathing DevOps and DevSecOps. But the fact is that many are not. Data show that a mere 17 percent of organizations have fully adopted DevOps. The rest are likely still stuck with the comparatively inefficient, slow-moving delivery processes associated with Agile.
To be sure, Agile software delivery was innovative when the method appeared in the early 2000s. But that was almost two decades ago. If your organization is still relying primarily on Agile methodologies today, it’s missing out on important efficiencies, and should focus on upgrading to a DevOps practice. Once you’re there, you can take things a step further by achieving DevSecOps as well, which extends the benefits of DevOps to software security.
This post explains how to get from Agile to DevOps, and then onto DevSecOps.
Agile to DevOps to DevSecOps
Agile is software development from the perspective of a project manager. While it got teams to work at a more frantic pace, there were still silos between teams, and when things go wrong, it’s an endless blame game rather than finding a solution. Realizing these drawbacks, the ecosystem turned to DevOps, a methodology that seeks to integrate the three functions (Dev, QA, and Ops) into a single cohesive unit.
DevOps is an improvement over Agile because of its focus on people more than process and tools. Additionally, DevOps encourages collaboration between teams using a “shift left” approach where QA and Ops teams are active participants in the application design and development stages. Further, the DevOps approach prioritizes automation over manual operations. Whether it’s build automation, test automation or release automation — every step automated brings incremental gains in speed of development and reduces the time to market for an app.
While DevOps is a drastic shift of mindset from Agile, DevSecOps isn’t a big change if you’ve already begun adopting DevOps practices. Essentially, DevSecOps highlights the often-neglected aspect of security across the development pipeline. Much is said about automation, collaboration and other core pillars of the DevOps methodology, and in the process, security can be forgotten. DevSecOps looks to change this by giving security the priority it deserves.
DevSecOps doesn’t call for a separate security team, but rather looks to infuse security principles at every step, and into every collaborator, including developers and QA. It requires developers to follow security best practices when collaborating from Git repositories. This includes running automated “dry run” tests before committing new code. The QA team should include automated security checks as part of the build automation process so that bad code is stopped before it gets out into production. Establishing an immediate feedback loop between dev and test is key to realizing the benefits of “shift left.”
It bears mention that this type of modernization of the software delivery pipeline is possible only with the power of the cloud. However, simply running a few VMs in a cloud platform isn’t enough. It will require the use of multiple cloud services from cloud vendors, and niche services that cloud vendors don’t provide, which are better served by cloud startups that specialize in just one niche. This brings about a wholescale change in tooling, from vendor-specific tools to open source and cloud-based tools. The best way to describe this is that it is not just cloud computing, but cloud-native computing.
Containers are the new building blocks of cloud-native infrastructure. When using containers to package applications, some things are the same as before, but some things are new. For example, RBAC, encryption key management, and the principle of least privilege are not new practices, and they may only be implemented differently for a cloud-native environment. On the other hand, practices like running containers with non-root privileges, container image scanning, and configuring a service mesh for networking are all new approaches to software delivery brought on by the container revolution. Cloud-native security should be mindful of these new components within the system and establish new practices to secure applications that are built using these components.
With the distributed nature of applications and infrastructure, there is a lot of data to be analyzed for security purposes, and a large (albeit distributed) attack surface to secure. This is not possible by human review, and needs machine learning algorithms to analyze system performance and health metrics to identify and prevent internal vulnerabilities and external threats. Threat detection during runtime is a modern approach to software security that is essential when operating in a cloud-native world.
As a parting thought, let me make a point about taking a realistic approach to making the Agile to DevOps to DevSecOps journey. Don’t expect change to happen overnight. Instead, focus on slow but steady progression from Agile to DevOps and finally to DevSecOps. You want to determine your organization’s needs and goals and pick and choose the right solutions for your situation.
Sometimes, the solution is to “lift and shift” a monolithic app to the cloud and package it in containers, and in other cases, it may make sense to deprecate an older app and replace it with a newer, more nimble app that’s built to be cloud-native from the ground up. In each case, security should be considered right at the start and not as an afterthought. Doing so will put you in the DevSecOps mindset and help you achieve the ends you are pursuing.