Conduct an online search and you’ll find close to one million websites offering their own definition of DevSecOps.Why is it that domain experts and practitioners alike continue to iterate on analogous definitions? Likely, it’s because they’re all correct. DevSecOps is a union between culture, practice and tools providing continuous delivery to the end user. It’s an attitude; a commitment to baking security into the engineering process. It’s a practice; one that prioritizes processes that deliver functionality and speed without sacrificing security or test rigor. Finally, it’s a combination of automation tools; correctly pieced together, they increase business agility.The goal of DevSecOps is to reach a future state where software defines everything. To get to this state, businesses must realize the DevSecOps mindset across every tech team, implement work processes that encourage cross-organizational collaboration, and leverage automation tools, such as for infrastructure, configuration management and security. To make the process repeatable and scalable, businesses must plug their solution into CI/CD pipelines, which remove manual errors, standardize deployments and accelerate product iterations. Completing this process, everything becomes code. I refer to this destination as “IT-as-Code.”
Whichever way you cut it, DevSecOps, as a culture, practice or combination of tools, is of increasing importance. Particularly these days, with more consumers and businesses leaning on digital, enterprises find themselves in the irrefutable position of delivering with speed and scale. Digital transformation that would’ve taken years, or at the very least would’ve undergone a period of premeditation, is now urgent and compressed into a matter of months.
Security and operations are a part of this new shift to IT, not just software delivery: A DevSecOps program succeeds when everyone, from security, to operations, to development, is not only part of the technical team but able to share information for repeatable use. Security, often seen as a blocker, will uphold the “secure by design” principle by automating security code testing and reviews, and educating engineers on secure design best practices. Operations, typically reactive to development, can troubleshoot incongruent merges between engineering and production proactively. However, currently, businesses are only familiar with utilizing automation for software delivery. They don’t know what automation means for security or operations. Figuring out how to apply the same methodology throughout the whole program and therefore the whole business is critical for success.Automation is king: When a DevSecOps team leverages automation correctly, solutions are repeatable and deployable in a few clicks. For engineers, this frees up coding hours to work on upcoming features, an endless list of bugs, or long-term projects waiting in the pipeline. For security teams, this frees up valuable time needed for threat hunting. For the company, automation results in an efficient and scalable business that can provide continuous value and meet future demand.
To meet the unlimited demand in the cloud, deployment is required to happen through a secure and automated process. Yet, in a survey presented at Google Next 2019 Partner Summit, researchers stated that 80% of core IT workloads are still on-premise. One reason for this is how a company views the cloud as an opportunity to do more than just a lift-and- shift operation, and instead refactor themselves to be more cloud native. This takes time and company-wide collaboration to plan and execute.The more crucial issue is the gap in essential talent required to run a competent DevSecOps program. DevSecOps frameworks and tools develop so rapidly that there simply isn’t enough talent that can keep pace with regular and rapid transformation. Lastly, moving to a full-fledged DevSecOps program means deferring to automation. The caveat being that automation comes with a steep learning curve. This includes dedicating time to researching and setting up the right tools, training employees and developing a proactive plan for the risks associated with incorrect misconfiguration.When we reflect on the obstacles that prevent enterprises from fully moving to DevSecOps, it’s easy to sympathize with their state of immobility. How can they overcome these considerable obstacles simultaneously?
Start small. Do not overcomplicate the process by automating too many tools or solutions at once. Start with a small portion of your development process and iterate until it runs smoothly. Choose an existing area that you need to repeat often and focus on automating this area first.Look for a CI/CD platform that supports the tools you need to utilize as well as facilitates collaboration between security, operations and development teams. Implemented correctly, CI/CD helps you reach peak productivity with a few clicks.Pick your tools carefully. When picking tools, look for best-in-class tools in each category, such as Terraform for Infrastructure-as-Code, Ansible for Configuration-as-Code or OpenSCAP for Security-as-Code. These tools typically come with substantial community support, so you can always troubleshoot quickly. Starting with open-source tools is a good option. However you should select platforms that can quickly roll back mistakes without interrupting your delivery.Insist on visibility. Work with tools that offer version control, such as Github or Gitlab. Visibility leads to more cross team collaboration, and version control ensures high availability to code and swift disaster recovery.Be patient with security automation. Often, this is the most difficult piece to automate as many tools provide alerts but stop at providing automation. Lean on your cybersecurity vendor or internal team by inviting them to assist you with shifting left. Furthermore, as you evaluate your security audits, identify a recurring pain point and automate from there to achieve the biggest gains immediately.
Rushing into the process and expecting results immediately. When a company changes its delivery framework, it needs to account for a transition period when team members will have trouble with change, leading to some resistance. Although, as we all know, resistance is futile! Managers should provide guidance and training to ease the transition. It is better to take lessons from this transition period and apply it toward the usability of your program instead of rushing ahead without recourse.
Overlooking existing resources. When shifting to DevSecOps, first look at the resources you have. There is no need to purchase completely new resources at the onset. Ascertain if you can utilize existing resources, such as a systems administrator who can code, or a security engineer with the aptitude to learn code and have them collaborate on workflows together.
Overautomating without having the proper checks in place. It’s easy to underestimate the time needed to properly plan an automation program. When starting out, ensure everyone is iterating on a short timeline, such as a two- to four-week cycle, so that you’re finding bugs and iterating quickly. Indiscriminate automation all at once runs the risk of taking down your entire system altogether. If automation tools are configured incorrectly and fail to establish a response protocol, there is no easy way to remediate from that point.
DevSecOps is demanding of even the most highly technical resources. To realize its value requires a substantial investment of time and money into the front end of building out your practice. However, as its etymology suggests, DevSecOps is a team effort.
The whole premise is to build a practice across the entire organization, so every team should be enrolled. By working together and leveraging automation, businesses will increase their agility and approach the ultimate destination, IT-as-code.
Mike started his career in the US Air Force working on F-15 weapon systems and later as a cybersecurity engineer. Mike has founded multiple tech companies and is a regular speaker at industry events, including Hashiconf, various Microsoft events, Red Hat AnsibleFest and All Day DevOps. He has published several articles including on TechCrunch, RSA 365, CRN, and The New Stack, and appeared on the cover of Channel Pro Magazine.