According to Shannon Lietz
“The purpose and intent of DevSecOps is to build on the mindset that “everyone is responsible for security” with the goal of safely distributing security decisions at speed and scale to those who hold the highest level of context without sacrificing the safety required. ”
During my time at Ensighten I learned a lot about how the private sector, and a CA startup works. The development teams are at the forefront of the organization. The development teams lead the overall direction of product or service. As a member of Ensighten’s Security team I was in charge or performing application security assessments and penetration testing of the companies main application base. The application development team was in the process of migrating to a DevOps Agile development method, and moving away from a waterfall development cycle. The teams also began to follow a new SDLC process. I started to realize that with new versions of the application being deployed weekly, our security assessments were being left in the dust.2 We as a security team needed to adjust and understand this new development process. As I started researching and learning about DevOps I came across I new security theory, DevSecOps.
DevSecOps, or RuggedDevOps, or SecDevOps. It goes by many different names. Whatever you call it, it all mean the same thing, integrating security testing into the agile development process. Ensighten used an Bug Tracker application called JIRA. JIRA is a product by Atlassian that allows for scrum development testing. The development team would address bugs in the application code using JIRA and could track them to a completion or fix state. I started thinking if our developers live in JIRA, why do we not utilize this process. Ensighten had a QA process as well that would perform functional testing on the application in the “staging” environment before the code base was prompted to production. I started thinking, all the pieces are in place. Let’s just integrate into this process and not reinvent the wheel. Enter CyAn.
CyAn, short for Cybernetic Analyzer, was an application i developed that integrated all our security scanners into one API driven mechanism. The results were then aggregated into a metrics portal for history, and CyAn automatically would create new JIRA tickets for “Security Bugs”. CyAn would run on the staging environment and would create JIRA tickets before the code was being promoted to production. Of course with any new process it was met with some trepidation by the development teams. I then realized it was rude of me to ask the developers to accept my new policy when I was not even understanding their process and procedures. To fix this issue I created a working group where I worked directly with the dev teams to understand there process, and even started following their SDLC process for our automated security testing. The working group also allows us as an organization to create an new SSDLC process, (Secure Software Development Process).
One last comment on DevSecOps, many believe this is a nonsensical term, as DevOps should include security testing by default. I do agree with that belief, however, we as security professionals cannot be so arrogant as to assume a developer will always think of security when they are under a time crunch to push code. I also believe that its important to physically see the work SECurity in the title.
CyAn has been open sourced and is up on my GitHub page.