As if DevOps was Not Enough…DevSecOps

Just when you think you've found a way through to completion, a new wallAs success with DevOps continues to make progress, it ventures into taking on other areas where traditional SDLC / IT practices have been less than optimal. Alongside this need, the IT Security technical landscape has been in rapid transition, making it near impossible for security teams to keep up with both increased DevOps velocity and the changing security landscape. Now, teaming up security in the continuous integration (CI) and continuous delivery (CD) model has a potential to be a game changer.

In the beginning, the movement started out being called DevOpsSec. ‘Sec’ was appended on to the end – almost like a caboose on a train – an afterthought. But in reality, security must be thought of, designed, and practiced throughout the process. In light of this, the more current term is DevSecOps – one where we weave security into our integration. Originally,  marketing hype from each security software vendor clouded the concept.  But, the movement is less about tools, and more about the way in which we work together, in parallel.

The Brick Wall of Doom

I’m going to recount a real life story which happened to my teams at an undisclosed company. I’m sure this story will resonate with most of us – it happens everywhere. I had two teams working to produce a web product. The product needed to be very secure. First, we interviewed and collected functional and non-functional needs from all the stakeholders – including security, audit, operations – etc. We began the typical Scrum ceremonies, producing demos of the product along the way. We finally got to our minimal viable product (MVP), and began the promotion to production.

That’s when the alarms went off. The security team that had been in the planning, original gathering of MVP requirements, and sprint planning was now telling the teams to halt, while they began a stand-alone waterfall process to evaluate the solution. ¯\_(ツ)_/¯

DevSecOps aims to help solve the brick wall of doom…. By incorporating security into the development pipeline we can work in parallel reduce the likelihood of this happening to our projects. Notice, I said reduce – not eliminate. I’m a realist. In our line of work there will always be the possibility of additional review gates, late requirements and changing requirements that can impact our success.


There’s lots of white papers from security vendors on how their product will solve this. While this may be true – it’s not our first goal. Avoid tools that solve problems, and focus on solving problems with proper selection of the right approach, process, and then tools…

  1. Agree on non-functional requirements. What benchmarks we are being asked to meet? Items like Must pass OWASP Top 10 make well defined delivery targets. Pass all security scans does not.
  2. Participate throughout system development. Encourage participation often and early.  Traditionally, security teams not accustomed to working this way. Find items from the backlog that address security achievements early in the project. Avoid de-prioritizing all of them.
  3. Evaluate tooling. Selection criteria needs to include the ability to integrate with existing CI/CD and transparency to the tests and their outcome. Transparency is important because it brings the value into the team – as opposed to a mandate from others.
  4. Identify WHERE in the pipeline the new tooling is to be inserted. Most practitioners agree that security testing is before promotion. The team MUST  resolve defects before the project can move past DEV. Best practice: BUILD > Unit Test > Integration Test > Security Test > Performance Test.
  5. Crawl before you run. Run the tools manually first.  Learn their idiosyncrasies. Apply what you learned to the automation.
  6. Celebrate success.  There’s nothing better than finishing with a return code zero!

The Next Steps

In today’s hyper-connected world, Security is paramount — We can no longer accept misaligned practices of the past. Waiting until you hit the Wall of Doom can be a ‘career limiting’ move. Agile requires an understanding of the MVP and that includes security.

At TeraThink, we are pushing the movement into the DevSecOps world. We are incorporating security earlier in the process, building security foundations upon which our projects can succeed. It is never too late to start. Let us know if you would like to talk to us about how to better incorporate security into your development processes and begin the move to DevSecOps.

[Editor’s Note: This post was originally published on the blog of Dominion Consulting. On November 1, 2017, Dominion Consulting merged with TeraThink and are now operating jointly as TeraThink. All blog posts migrated from the Dominion Consulting website have been updated to refer to ourselves as TeraThink.]