How to transition from DevOps to DevSecOps?
When does a DevOps team or a person become DevSecOps? Is it after they start using one or two security tools as part of their workflow? Or is it after they hire or work with a security engineer/analyst to get their work reviewed frequently? The answers to these questions often differ depending on the organization, team or the leader who is championing DevOps and DevSecOps adoption. The definition could also differ depending on the DevOps/SRE book you read too!
As the creator of AppThreat, a free open-source application threat intelligence platform and as the Lead Product Architect at ShiftLeft, a next-generation DevSecOps company, I would love to say that DevOps teams would become DevSecOps once they start using our ShiftLeft platform. But nope, that’s not how it works!
I would love to say that DevOps teams would become DevSecOps once they are start using our ShiftLeft platform. But nope, that’s not how it works!
DevSecOps is an evolution
Like how DevOps is both a culture and a way of building and releasing products with technology (dev), automation and optimization (ops), DevSecOps is a much bigger evolution where security is understood, practiced and embedded into everything — technology, automation, and optimization. The handy infographic below explains this evolution:
If we start bottom-up, established DevOps teams tend to think problems as tickets on their board. These are either development tickets to build a new micro-service or a deployment ticket to automate or optimize a certain build or release pipeline process. The teams can have a velocity that can be measured, they can fail-fast and fail-often (FFFO). This is where I believe the agile and management of DevOps starts to fail.
When teams gets measured and rewarded based on velocity and are allowed to fail fast and often, there will be some corners getting cut and security will be one of them.
So, the idea that teams can be measured and incentivized to fail and produce something quickly and still claim that security was properly thought-out is a flawed argument. So, the next time you hear a vendor or a team claim that they built a product or a feature in 2 weeks or as part of a hackathon then you can assume it is insecure.
DevSecOps teams, on the other hand, include security as a thought-process at every step which would essentially slow them down. But this slowdown would actually speed up the entire organization, reduce wastage and improve security and profitability. How can slowing down speed you up?
Slow down to speed up
To start with, we know that 90% of the features, products, start-ups would fail. Your customers may not like or even bother using every single feature that gets built.
Did you know that Microsoft Word has a feature to take screenshot and capture screen but almost nobody uses them since they use the Print Screen key or some other more capable tool?
With a fail-fast and fail-often (FFFO) mindset, people would be busy building things that are never properly thought out. Like why build a feature if we know that it is going to put the customer’s safety and privacy at risk? (Hey Boeing!)
Those features, libraries, pipelines, templates, etc that are properly thought-out say based on well-architected principles would see tremendous re-use. Instead of each team designing and building their pipelines, a standardized pipeline template would get adopted. Features like GitHub repo templates when widely adopted would improve the overall velocity, kind of like a multiplier effect which is hard to measure and implement with an FFFO approach.
Another perceived benefit of the FFFO approach is pivoting. The ability to change the focus or priority depending on the customer feedback and response. But ask yourself this — whether pivoting is actually beneficial for teams? Imagine a car driving along the freeway. Pivoting encourages you to frequently change lanes depending on the traffic in front of you. This would slow down the dependent processes and teams (cars behind you) and can even cause traffic jams and collisions. Now imagine a car that carefully chose a lane and a speed for a particular destination. The car would reach the destination at the expected time safely. So pivoting sounds good in theory — may even work once or twice but surely not for every sprint.
How to implement DevSecOps properly?
ShiftLeft can help you here. Unlike traditional security vendors who love selling tools as a solution, at ShiftLeft we help customers to shift left by implementing security that is embedded into the DevOps lifecycle. Our platform can integrate with a range of CI/CD, project management and DevOps tools thus offering greater flexibility. With a guided DevSecOps rollout, we can also help gain buy-in from all the teams gradually.
To find out more about ShiftLeft or how our Fortune 100 customers implement DevSecOps with our platform do not hesitate to contact us.
How to transition from DevOps to DevSecOps? was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Prabhu Subramanian. Read the original post at: https://blog.shiftleft.io/how-to-transition-from-devops-to-devsecops-70362ca51305?source=rss----86a4f941c7da---4
