By Danny Bradbury
The days of thinking about security as an afterthought are over. DevSecOps can make security an inherent part of your software development lifecycle.
How do you handle security when developing software? Does a separate security team look at it afterwards and try to make enhancements? Or do you consider security during your design but then largely ignore it until the end? Building security into software development from start to finish is becoming more common. Combined with modern, fast software development methods, it could revolutionise the way that you deliver applications for your business. It’s called DevSecOps, and here’s how it works.
Traditionally, a software application would go through months or even years of development before a new release. By this point, customer requirements may have moved on. DevOps (Development + Operations) changed all this by making developers and operations staff jointly responsible for the delivery and management of the software.
Build on modern software practices
DevOps enables developers to manipulate the IT infrastructure using code (so that they can provision their own servers and storage from within software, for example). It automates parts of code development and review, using tools to test software quality at every stage. It also monitors application performance, feeding back data to software developers so that they can improve subsequent releases. All these things together can slash release cycles to days, if not hours.
This is all very well, but what happens if a developer spends up a virtual machine for testing and then forgets to erase it later? Then you have a security issue. And what about security bugs that may still find their way into software because the development team hasn’t included them as part of the QA process? These considerations are why security has become an important part of the DevOps process, giving rise to DevSecOps.
Involve people from the beginning
DevSecOps starts with the idea that everyone is responsible for security. Security decisions should be distributed quickly, to those who have the best contextual understanding to make them right now. This means spreading those security decisions to all members of the software development and deployment team.
DevOps pros should be pessimists, thinking about how software might be attacked or broken as they take it through the next stage in the process. They should be educated to start from the premise that the software is hackable, and to create protections for it as they go. This also calls for proper threat modelling during software design.
Automate where possible
To support this people-driven approach to security, DevSecOps teams can use chains of tools designed to automate security measures throughout the entire development process. These include everything from source code analysis through to integration testing. Evolved DevSecOps teams might also use code dependency checkers and static automated security testing tools that can scan code as developers write it to highlight security problems.
These automated security tools extend into post-deployment monitoring. One example is dynamic application security testing (DAST). This tests for conditions indicative of a security vulnerability in a live application, by looking at the exposed HTTP and HTML interfaces in a web application, for example.
By making security a first-class citizen in the development lifecycle, companies can get closer to the ‘security and privacy by design’ concept that was mandated in the General Data Protection Regulation (GDPR) rules. An application developed with security in mind from the beginning, including at the design stage, will be more secure than one in which security was bolted on as an afterthought.