Written by Andrew Neale
In recent years DevOps has become one of the forefront methodologies for Cloud Computing, but now people have begun to introduce security measures into their DevOps strategies to become DevSecOps or rugged DevOps.
So, how do they differ?
DevOps was created to help bridge the gap between developers and operations and bring processes closer together. Current DevOps has achieved this by some margin as now using DevOps methodologies developers can release quickly and efficiently into multiple environments using continuous integration and development pipelines created by the Operations team (or DevOps as these employees have been royally decreed). Which is great as testing is now enforced and automated and the developers can quickly release into Production. But what about security? How does security fit into this new automated pipeline world?
Well DevSecOps has a manifesto which can help us in our journey:
Over Always Saying “No”
Data & Security Science
Over Fear, Uncertainty and Doubt
Open Contribution & Collaboration
Over Security-Only Requirements
Consumable Security Services with APIs
Over Mandated Security Controls & Paperwork
Business Driven Security Scores
Over Rubber Stamp Security
Red & Blue Team Exploit Testing
Over Relying on Scans & Theoretical Vulnerabilities
24×7 Proactive Security Monitoring
Over Reacting after being Informed of an Incident
Shared Threat Intelligence
Over Keeping Info to Ourselves
Over Clipboards & Checklists
So how can we start to achieve the manifesto’s ideals?
By introducing security into the design of pipelines you can start to embrace DevSecOps. Security is not there to be a blocker, slow releases down or stifle innovation as is sometimes perceived. By adding security testing into the pipeline with source-code testing, integration and post-deployment monitoring can help ensure that your application is secure, but also free up your security personnel to focus on more manual and time-consuming work without having to worry about the security around each and every release.
How can you move towards embracing DevSecOps?
If you have a fully-fledged DevOps with CI/CD set up and releasing into live best place is to sit down with your security team and explain the process and see where they can advise at which parts you can add any automated security testing or which parts could be secured more. By making them part of the DevOps culture and teams you will slowly work your way towards DevSecOps. But a word of warning, do not rush this process! Automated Security processes can often be very resource-intense and time consuming if running against the full code base or stack every day, which can and will delay or even break your release schedule. Try to set up dynamic automated security testing (DAST) which only runs against recent or new code which is more lightweight and help you catch security vulnerabilities early on.
If you are about to start your DevOps journey it is best to embrace DevSecOps from day 0, by designing your pipelines, CI/CD with security from the start helps to create much better security standards, instead of having to shoehorn security in afterwards that can break pipelines or slow them down. Start with a fresh set of tools that have security features built into them, that way you avoid the pitfall of having an array tools that become harder to manage. Using that new pipeline for the first time? Don’t turn all the security options on from the start, often DevOps is a new way of thinking and if you go from 0 to 100 on security it can cause the developers to become bogged down, start small by turning on SQL injection scanning for a start, when people are used to that turn on another feature such as Cross site scripting scanning and so on. By taking small steps you can enable the developers to work alongside the new security pipelines and practices.
At the end of the day it’s not whether to choose between DevOps or DevSecOps, DevSecOps is slowly becoming the “de facto standard” for DevOps and eventually it will only be DevSecOps or rugged DevOps, which ever wins that war. It comes down to if you want to start you DevOps journey with security or without and face the potential security issues down the road. Start small, start smart, implement ‘Security as Code’ DevSecOps best practices, it gets developers, security and operations working together.