Everyone is a fan of agile development. And while there are many benefits to adopting an agile methodology, one of the most important is that it speeds up software development. “Oftentimes products developed according to agile methodologies do end up getting shipped faster. This happens mostly because of the task prioritization in agile.”
The sooner the software ships, the sooner it can begin generating profits. For better or worse, in business, speed translates into dollars. For this reason alone, agile development is here to stay.
So, what’s the seemingly unsolvable problem of agile development? Things made fast are never as secure as things made slowly. Agile, with its emphasis on speed and agility, can be guilty of sacrificing security for speed. That’s a real problem in the business world, not just in software development.
A Real-World Problem
“In the real world, we must deal with problems like time to market and undersized teams. This means that we rarely have enough time and people to build the intended functionality, so ‘no essential features’ are usually left out. Unfortunately, this usually means less testing, a quicker design, or making less precise threat models, among other quality and security practices.”
Research shows that 34% of developers report that security can’t keep pace with the cadence of software releases. When organizations perceive a tradeoff between software release speed and security, security tends to lose. It’s why everyone is a fan of Agile, including hackers.
A Hard Truth
Developing secure software takes time. There is simply no way to do development with security as fast as development without. But, that doesn’t mean you can’t do secure development at “the speed of agile”.
The evolution of DevOps into DevSecOps is a step in that direction. Integrating the security component into development enables security to keep pace with the CI/CD pipeline. Still, security can only keep pace if it’s done right.
Doing DevSecOps right involves following two key ideas. First, security can’t be “bolted on” at the end of the pipeline. It must be integrated into it. It’s the difference between an add-on and a built-in process. And it must be built-in as early in the process as possible. That way it can take advantage of shift left.
Second, it can’t be a onetime thing. Just as software is continuously integrated and continuously deployed (CI/CD), security too must be done continuously. It might be more accurate to define a proper DevSecOps pipeline by the acronym (CI/CS/CD).
Integrating security early into the pipeline and doing it on a continuous basis avoids the needless chokepoint at the end when you try to do security “once and for all”. Avoiding that chokepoint translates into faster security.
Agile Development: What Research Shows
Successful DevSecOps requires keeping up with the pace of the CI/CD pipeline while fostering cooperation between security, development, and IT operations teams. Research shows that one of the best ways to add end-to-end security coverage while enhancing collaboration is with threat modeling.
Technology research firm Enterprise Strategy Group has recently authored a whitepaper titled, DevSecOps Should Include Continuous Threat Modeling. The whitepaper addresses many aspects of DevSecOps, including why DevSecOps should start with threat modeling and why that threat modeling must be continuous.
