DevSecOps vs. DevOps
Though there is overlap between Development Security Operations (DevSecOps) and Development Operations (DevOps), they are two distinct topics.
So, what is the difference between DevOps and DevSecOps?
Let's first start by defining DevOps. Roughly speaking, I see DevOps as the practice of using automation to turn code (“development”) into deployments on real infrastructure (“operations”) automatically.
On the other hand, we can define Dev_Sec_Ops as the integration of security tooling into the CI/CD pipeline to enforce security at each stage of the development and release process.
If you have a CI/CD pipeline, you’re implementing DevOps. If you run Brakeman during CI/CD, you’re implementing DevSecOps.
DevSecOps as Company Culture
For a deeper dive, I really like this description of DevSecOps by Snyk. It's worth noting that Snyk’s DevSecOps definition along with the one from RedHat both use the word "culture" in characterizing the practice.
It's not a mistake or a hyperbole; embracing DevSecOps demands moving beyond the old "set it and forget it" mentality. You are probably already adopting DevSecOps at some level; you just may not be doing a satisfactory job yet.
Adopting DevSecOps means embracing the additional responsibility that software security requires. It means using - and understanding - the relevant DevSecOps tools for each stage of the security lifecycle.
It's a bit of a paradigm shift; many software devs still consider security outside of their job description, and fairly so. But as security moves more and more into the software development lifecycle (which is now fairly married to the deployment lifecycle), it is necessary that all parties involved in that lifecycle be conversant with the security implications of their work. Christophe Limpalair at Spacelift puts it nicely:
"...most people view security as an annoyance and as something that adds extra friction to the development and deployment process. Instead of accepting that and putting security on the back burner, DevSecOps brings security back to the forefront by saying “you know what, security is critical and must be part of our process, so let’s make it fit in as painlessly as possible."
It's an elephant, but once we break it down we should see that each bite is manageable.
The US Department of Defense (DoD) does a very nice job of visualizing the DevSecOps lifecycle:
Read more in the DoD Enterprise DevSecOps Strategy Guide.
There are many similar diagrams online, but I find the DoD's to be the most clear and consumable.
So what do each of these steps mean? Let's break them down a bit.
Plan: Threat Analysis
List all assets that need to be protected (user devices, servers, developer devices), the actors they need to be protected from (ransomware gangs, “hacktivists”, advanced persistent threats like North Korea’s Lazarus Group), and the vulnerabilities those actors could exploit (unauthorized data access, server access, cross-site scripting, compromised SSL certificates).
A threat analysis plan is often articulated in a threat analysis chart like this one from Network Analysis, Architecture, and Design.
Develop: Secure Coding; Security as Code
Ensure that developers know the best practices around their language and framework (Ruby on Rails, React Native, etc.). Automate your security tooling using infrastructure as code.
Learn more by reading Snyk’s article on secure coding practices and GitLab’s security-as-code guide.
Build: Static Application Security Testing (SAST)
Analyze your source code for any recognizable weaknesses with SAST tools. This is language- and framework-specific. SAST runs as part of your build pipeline. Examples:
- Bundler Audit (ruby)
- Brakeman (Ruby on Rails)
- NPM Audit (JavaScript)
- Sobelow (Phoenix Framework)
Test: Dynamic Application Security Testing (DAST)
Actively scan for exploitable weaknesses. DAST software runs against a test environment. This is language-agnostic testing, usually for web applications. ZAP is a good example of DAST software.
Test: Penetration ("Pen") Testing
Bring on dedicated specialists to attempt to hack a test environment with a variety of tools, and provide a report of vulnerabilities after doing so. There are many consulting firms which provide pen test services.
Snyk’s penetration testing guide is a good introduction to penetration testing concepts.
Release: Digitally Sign
Use cryptographic signatures to verify that source code is unmodified from the version published by the source domain/package maintainer. If someone were to manipulate the file containing your program to include malicious code, this would be detected by a signature verification tool.
Deliver: Secure Transfer
Ensure that your code is deployed via an encrypted and secure connection. Most cloud platforms will do this automatically.
If using containers, ensure that the container registry and container image is secure using tools like Clair.
Deploy: Security Config, Security Scan
Define and configure your infrastructure using infrastructure as code tools like AWS CDK.
Scan that infrastructure with a tool like Cloudsploit (Multicloud), KubiScan (Kubernetes), or Amazon Inspector (AWS). Like SAST tools, the tools you choose will be specific to your platform.
Operate: Security Patch
Continually patch your code to the latest version. Use tools like dependabot and bundler-audit.
Monitor: Security Audit, Security Monitor
Continuously assess the security of your application's data. This step is best considered after you understand what it is you are monitoring (see everything above). This sounds obvious, but plenty of devs hook up a monitoring system without really knowing what is being monitored.
In addition to monitoring the software processes, a security audit should also review the user processes, i.e. how users access and share data within and outside of the application.
Shout out to Wazuh as a comprehensive monitoring/dashboard tool, while AWS has Amazon Security Hub. For auditing there’s a wide range of options, but TechTarget’s security audit guide is a good place to start.
Conclusion
Investing in a legitimate DevSecOps strategy at your organization is certainly no small investment, in time or resources. But it is a very surmountable challenge.
If we break the process down as above and become comfortable with each step of the process, we can weave these security practices into the existing fabric of our software lifecycle.
And if there is any question about whether this venture is worth the time or resources it demands, I would point you to research into the savings a company will realize by investing in a DevSecOps strategy.
If you're interested in jumping into DevOps or DevSecOps, or if you are already on your way and would like some feedback, shoot us a line. We'd love to hear from you.
Contributors:
Learn more about how The Gnar builds software.
Top comments (0)