Security and the Evolution of Software Development Speed
Speed is critical in software development. Speed gives software companies the agility and maneuverability needed to navigate the complicated competitive landscape. Speed and quality are both necessary to acquire new customers, fulfil contracts, gain market share and stay competitive overall. However, the need for speed has never been as front and center as it is right now. Software security adoption had ups and down as software development speed got more attention.
1. The Era of Waterfall
The Waterfall model of developing software is a breakdown of projects into linear sequential phases, where each phase depends on the deliverables of the previous one. That actually worked pretty well for software security.
Like quality assurance testing, software security testing can be divided into two main categories: automated testing and manual testing. Automated testing is scalable, and fast but lacks the sophistication of actual attacks. Manual testing is thorough and sophisticated but slow and unscalable.
Since Waterfall software development is slow by design. It was easy to integrate software security testing into the process, taking a few weeks to test a piece of software was not bad given that development would probably take 6-12 months, and testing would take 3-6 months, etc.
Based on that model, the enterprise would hire a central team to handle software security, either through whitebox testing techniques, black-box testing techniques or both. This central security model remained the only model to ensure a systematic approach to shipping secure code.
2. Agile Development
During the late 1990s and early 2000s, the industry and especially Silicon Valley became frustrated with the Waterfall development model. In 2001, the Agile Manifesto was born which set the stage for the whole agile movement including Scrum, Kanban, etc
Since Agile development remained mainly a novel approach adopted mainly by startups during the 2000s, security was not actually a welcomed addition to any agile development workflow since the main reason behind agile is to speed up software development and client feedback. While Agile was a great addition to the speed and quality improvement of software development, it didn’t really add much to security at that time. The central security model was still prodimemant. Development teams replaced Waterfall with Agile. However, security was only introduced when it was showtime, i.e. when the software was ready for production. Security remained an afterthought that was done by a “function” separated logistically and fundamentally from software development.
As Agile development processes started to be mainstream, and as code found its way to production faster. At the same time another shift in the industry happened, the mass adoption of cloud computing, making it even easier and less expensive to develop software and push code to production. However, another roadblock emerged which is the disconnect between developers and operations that prevented software from being deployed at the required speed. DevOps is the combination of cultural philosophies, practices and tools that increases the organization’s ability to deliver applications and services at high velocity. Again, during the first few years of DevOps, security was not a welcomed addition since the industry was mainly focused on speed and quality. There were shy appearances for security but it was never defined or measured correctly. Again, the central security model remained predominant during this phase.
Although the first few years of DevOps didn’t focus on security. However, DevOps created the perfect framework for software development teams to adopt security practices. As DevOps started to gain traction and become a more mature discipline, DevSecOps emerged. While DevOps is the cross-functional mode of working between development and operations. DevSecOps, is the cross-functional mode of working between development, operations, and security. Before DevSecOps, it was really hard for software development teams to fundamentally integrate security into the process without slowing everything down. Finally, this theoretically would provide an excellent alternative to the central security team, a model that does not scale very well. By integrating security controls and tools into the DevOps pipeline, this would ensure security checks are run and code is verified against security concerns before it hits production.
Thanks for reading 🙂