Similar to the proliferation of mobile devices in the enterprise several years ago where organizations were feeling the pressure to have a mobile strategy but didn’t know where to start, we’re seeing the same situation with development methodologies. To accelerate development velocity, teams are feeling the pressure to “do DevOps,” and when integrating security, to “do DevSecOps.” But much like during the initial mobile wave, many companies say they’re implementing these methodologies, and might even think they are, but in reality, they’re not. Yet.
First, it’s important to remember that DevOps and DevSecOps are not job titles or roles. They are paradigm shifts in thinking and culture. Big shifts. But necessary ones. If companies don’t embrace them, or at least a more agile and secure way of developing, they will fall behind. According to Gartner, by 2018, 90 percent of organizations attempting to use DevOps without specifically addressing their cultural foundations will fail.
If you were writing “War and Peace,” would you rather edit and course correct as you write, or pile all the corrections on at the end?
Second, the ship of change turns very slowly. In terms of integrating security into the software development lifecycle, regulations still require that testing be done just twice a year. In an environment where developers are continuously making changes and hackers are continuously looking for vulnerabilities, scanning a few times per year doesn’t make sense and is actually reckless. Not only is a company exposed for days at a time, but since vulnerabilities are accumulated in between these testing windows, developers are then inundated with massive fixes, some of which are very likely already in the production environment. This is definitely disruptive to development velocity and reinforces the perception that security police are dream killers. I often use the analogy — if you were writing “War and Peace,” would you rather edit and course correct as you write, or pile all the corrections on at the end?
Third, as mentioned, developers view security policing as a barrier to innovation and to their velocity goals. And rightly so. Security has always been at the far right of the software development lifecycle. How do we bring them in and create this culture of DevSecOps? Development and security are speaking two different languages and neither has the time or inclination to embrace the big picture. Complicating this, organizations use a plethora of testing tools delivering different results and being deployed manually by an ever-shrinking workforce. There are different people running different tests getting different results, working through these issues with different developers. This creates inefficient pockets of information instead of a cohesive culture of understanding. It’s doing nothing to drive developer awareness of the bigger picture.
How can this cultural shift to DevSecOps start to happen?
Make collaboration a key component. Security needs to develop more of an engineering mindset and development needs to have better awareness and understanding of security vulnerabilities and start thinking about security with every line of code. Automating and orchestrating testing into the software development lifecycle can facilitate this process — from code commit, with static code analysis and source code composition on the far left, to deployment, with dynamic penetration testing and OWASP vulnerability detection on the far right. Employ continuous testing and feedback loops. Normalize and correlate the results of the different tools already in use to prioritize results for actionable items.
Development is not opposed to deploying secure code. They just need to be brought in sooner and with better communication. Continuous testing WILL surface continuous issues — make no mistake — but this process is far more efficient and targeted for development and impacts velocity far less. Normalize the culture with orchestration, automation and communication by normalizing the data and feedback.
Security has traditionally been viewed as a barrier to velocity and innovation. But by integrating it seamlessly and continuously into the software development lifecycle, it can actually accelerate innovation.
Feature image via Pixabay.