DevOps, DevSecOps, shift-left, security posture, cloud native, etc.
Chances are you’ve heard these terms or similar buzzwords when discussing modern application development life cycles. These new industry words can be beneficial – by providing a framework that explains complex processes – or harmful through misuse or overuse. Whether misuse is intentional or not, a buzzword can convey a context that the user doesn’t truly represent.
DevOps and DevSecOps are examples of terms that are often negatively received due to both their overuse and misuse. Since it was first coined in 2009, there have been many different iterations of what DevOps encompasses. The word’s negative connotation likely stems from its utopian use in conversation and the less than realistic implementation. Although many organizations claim to be DevOps-centric, few accurately represent the word. And yet, DevOps methodologies, when correctly practiced, are incredibly beneficial to teams and businesses.
What’s the difference between DevOps and DevSecOps?
The premise of DevOps relies on five core components:
- An Agile framework
- Build-once, run-anywhere development
- Communication and Collaboration
If fully embraced, DevOps leads to faster deployment times, fewer failures, and quicker recoveries. All with a focus on giving a faster, more adaptable, and better product. Now, this newfound agility raises the question. Where are the security considerations? DevSecOps attempts to expand upon DevOps core principles by bringing security concerns into the discussion. The problem has been gaining traction recently, even though the definition has not made its way to Wikipedia pages yet.
One way to understand DevSecOps is to break down those core DevOps components and see where security fits in.
An Agile Framework
The agile methodology remains a staple in the software development lifecycle (SDLC) today. In contrast to the Waterfall method, Agile focuses on shorter cycles and smaller changes, enabling an organization to react quickly to customer feedback.
However, the Agile framework suffered from the same buzzword pitfall. Where was the operational feedback? Were the security requirements followed? The framework excelled in accelerating development cycles, yet operations and security requirements often hindered it. Developers were able to move fast enough to relegate operations and security to an enablement tool whose sole purpose was to pave the road for developers.
Agile was focused on developer speed, and it succeeded, however, the conversation was always around the development, with operations and security being an afterthought.
Container technologies changed the SDLC for the better. A truly disruptive technology, containers enabled developers to code, build, run, and test separately from operational resources. Now, operations could focus more on testing, security, and scaling since the required developer environment setup was gone. With containers, everything could be put into a Dockerfile and run anywhere. Developers had no reason to communicate with operations until it was time to hand over their images. Operations remained in the same boat they were before, as an enablement tool for the developers.
Despite these operational drawbacks, containers were still a significant improvement, made whole by the orchestration tool that unleashed their power.
Kubernetes enabled organizations to manage, scale, observe, and connect containers. It abstracted Dockerfile requirements into objects that could be managed and scaled. The declarative abstraction required developers and operations to communicate so Kubernetes could be effectively used. Over time the conversation finally matured enough to include security in the conversation.
How can security or operations teams enforce requirements on developers?
Automation is the key to enabling DevSecOps, by giving direct feedback to developers without hampering development speed. Unit testing, code analyses, and image scanning are a few of the tools that can be added to CI pipelines to inform developers of changes that will need to be made. These changes can be integrated into existing pipelines with collaboration from the development team. Operations and security teams should understand that the earlier they can provide automated feedback, the faster developers can adapt.
This is extremely important for security teams. Security teams are often viewed as erecting roadblocks to development to achieve the fictitious “100% secure” system. Implementing an effective DevSecOps program does not have to be this way.
With new tools and best practices, security can be an enabler for clean code by providing a stable, secure base image for developers to use. Teams can implement automatic checks in pipelines to monitor YAML files with elevated permissions, namespaces without a Network Policy, or container images with vulnerabilities or risks.
Everything as Code
The declarative nature of Kubernetes and other programming languages leads to more repeatable and understandable infrastructure and applications. YAML files enable teams to understand exactly what a container requires to be functional. Clock time, volume mounts, and injected secrets can all be visible from a single file, along with any additional comments. This method also makes your code work as documentation that you can version control and make iterative changes over.
Teams may use the newest and best tools, but it may all be for naught if your teams fail to properly document and catalog concerns. Without documentation, it is hard to share learned lessons across teams. As teams experiment with new pipeline configurations, their learned lessons will be useful to another team that may be just beginning. Use your code and version control system as a way to showcase your changes and allow further discussions. Otherwise, as individuals move on, the tribal knowledge will be gone along with it.
Communication and Collaboration
All of the code, applications, and security changes are for naught if your teams and individuals do not communicate. There is one aspect of communication that is often ignored in IT, and that is intent.
Inferring malicious intent is a core reason for DevOps and DevSecOps not reaching their full potential. Security teams are not trying to hamper development. They are merely doing their job and working to keep the application secure. Development teams care about security, but they are also trying to meet the deadlines for future releases.
Organizations must work to bridge the gap between teams, focus on learned lessons, encourage reasonable failure, and set realistic goals. From a cultural aspect, this change usually comes from the top. When an organization values this approach, the development, operations, and security teams will encourage conversations about what is and is not reasonable and be willing to compromise.
Where is DevSecOps Going?
To summarize, the following is a non-comprehensive list of requirements to be “DevSecOps” focused:
- Short, iterative software development lifecycle with embedded automated security checks
- Repeatable development environments with homogenous security controls
- Version-controlled CI pipeline
- Process for implementing organization- or team-wide changes to said pipelines to facilitate post-incident security investigations
- Robust documentation, preferably using declarative methods that enables security as code
- A culture of encouraging innovation and tolerating the failure that accompanies it
Notice that I did not specify any specific tools. DevSecOps is a cultural approach. Your requirements may only allow for particular tools. However, that does not mean that you do not employ the DevSecOps methodology in your organization. Pay attention to tools that take a collaborative approach to solving problems. These tools should provide for portability, observability, easy documentation, and most importantly, get buy-in from the teams to create a shared context.
DevSecOps is a growing movement, and with success stories, we can make it a positive term.