With the shift to the cloud, there’s been much talk over DevOps and how it can make processes effictively more efficient – full scope.
DevSecOps is about introducing security earlier in the software development life cycle (SDLC). The goal is to develop more secure applications all stakeholders within the SDLC responsible for security. Having business, tech and security work together to produce secure products seems like a dream come true – silos anyone? Perhaps too good to be true? Let’s investigate more and determine if DevSecOps is indeed the silver bullet we all need in building our Holy Grail of secure products.
Firstly, let us ask why there is a need for DevSecOps. Years ago, software products followed the waterfall methodology. The waterfall model is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks.
With the ever so present shift to cloud computing and dynamic provisioning of resources, developers have gained numerous benefits around speed, scale and cost of application development. These benefits dovetail nicely into the adoption of the DevOps movement. DevOps not only support but requires automations and monitoring at all steps of the SDLC. The goal is reduced development cycles, increased deployment frequency and much more stable releases, aligned with business objectives. Stable infrastructure and applications do not necessarily equate to secure infrastructure and applications.
At present, most development teams use the agile methodology for software development. In an agile environment, primary focus is rapid delivery. By using iterative planning and constant feedback results, teams continuously align product deliverables with business needs. The adaptability to change requirements is great for product delivery, though with quick turn release dates, when do you test for security vulnerabilities? Traditional security processes unfortunately have not kept pace in agile/DevOps environments rendering security a hinderance in software development where it is then usually bypassed. The thought is that if the security hinderance is not bypassed, the dev team has rarely enough time to address issues before launch, which means an insecure application was born in to this great world. The irony is that ignoring security to avoid the risk of missing a deadline injects more risk into the application. Security defects built-into the SDLC can lead to serious vulnerabilities like well know “0-days”. This in of itself defines the need for “DevSecOps”.
In DevSecOps “speed of delivery” and “secure code” converge into one streamlined/automated process called a CI/CD pipeline. The intent of DevSecOps is to build on the collective mindset that “everyone is responsible for security.” In other words, make everyone buy-in and have a shared responsibility. It is about pushing security left and automating the core security tasks throughout the entire and all iterative processes. This then lends to a new methodology that is herein nested called “infrastructure as code”. (That’s a whole other story.)
We want to push security to the left of the SDLC to ensure that application security starts as codified. By shifting left, teams quickly discover and analyze vulnerabilities in an automated fashion and then adapt their code to mitigate against those vulnerabilities .
DevSecOps will allow agile developers to focus on writing high quality / secure
code, enabling teams to release secure applications with relative benefits:
— security introduced from the agile start will reduce vulnerabilities
— automated security tools running in CI/CD pipelines allow security teams to
focus on high value targets
— better collaboration and communication between all teams
— improved development , IT, and security operations supporting the enterprise
Lets
not get to far ahead of ourselves. There is however some challenges we must
logically take into account. Lets take a few examples:
1.) A vulnerability scan process is blocking a build/deployment step due to a
vulnerability finding. The developer re-works the lines of code in question to
circumvent the finding just to get the build released.
2.) Another example is when dev teams only decide to final the code build IF
the severity of the finding is High enough. While this certainly helps identify
and address high priority issues immediately, consequences are that medium and
low rated findings make it to production builds. What defines acceptable risk within
processes for your organization?
As I digress for a moment, we should ask is DevSecOps the mystical magic easy button? DevSecOps may not cure all security related infrastructure issues or development issues, though it will most definitely create a better foundation for us all to build our future efforts upon. This foundation will inherently create better practices, better testing, better visibility and better validation at all layers throughout all iterative processes.
Reference:
Fedak,
V. (2018) What is DevSecOps? The 6 steps to secure your software delivery.
Retrieved from: https://medium.com/faun/what-is-devsecops-the-6-steps-to-secure-your-software-delivery-447906a6bd9f
Kukhnavets, P. (2019) Agile vs Waterfall: the Difference between methodologies. Retrieved from: https://hygger.io/blog/the-difference-between-agile-and-waterfall/
Chaudhry, A. (2018) What is DevSecOps? Retrieved from: https://medium.com/@aditi.chaudhry92/what-is-devsecops-cb14cfd457b2
Wikipedia Waterfall model. Retrieved from: https://en.wikipedia.org/wiki/Waterfall_model