Application Security slows down development.
Ask any developer, manager, tester or even security professional, and they will almost certainly agree with this statement. But is it actually true? And if so, what can we do about it?
Does Application Security slow down development?
In almost all cases, the answer is yes. Security is additional work on top of regular development work, no use denying it. But the common process to add security to an application is flawed and plays a huge role in why it's perceived so negatively by everybody except security professionals.
Security, the waterfall approach
Development has largely embraced an agile way of working. Even DevOps has become a common practice. But security is often still using the old waterfall approach. The development team creates the software, the security team points out everything that's wrong with it and development can start over again. This is the reason for missed deadlines, a "we accept the risk" mentality, and bad quickfixes that pass the tests but actually don't fix the security issues. We can do better than this.
Security, the shifting left approach
The security industry has pushed hard to shift security left in the development lifecycle. This approach promotes early and often security checks before and while the software is being developed. Security is integrated during development, not just added after it. It solves many of the issues with the waterfall approach and leads to measurably more secure software. But it still slows down development.
Security, the SRE approach
Once upon a time developers had to ask the operations team to deploy their software before it could be tested. This slowed down development a lot, and was solved by implementing DevOps, which has shifted the responsibility of deploying software to the developers.
Around the same time, the operations team started using more automation and engineering in their daily routines, which led to them being called the Site Reliability Engineering (SRE) team. The SRE team nowadays has 2 major responsibilities. While they are no longer responsible for deploying code, they do still assist and teach the development teams best practices, as the expert knowledge is centralized with them. Their second responsibility is to ensure the smooth operation of servers and infrastructure that runs the software. They are also the first responders to application outage incidents.
Due to the high level of engineering and automation, this model does not slow down development and scales well to large enterprises. We should use the same model for application security: Secure Software Engineering (SSE).
- High amounts of automation, using engineering and tools.
- The development team is responsible for the security of their code, not the security team.
- The security team assists and teaches the development team best practices.
- The security team responds to incidents.
Just as with the SRE model, the SSE model will reduce the negative impact of application security on the speed of development, increase the acceptance of the development team and management to include application security and thus ultimately increase the level of security in the application.
What if my organization is too small for a dedicated security team?
Start-ups and scale-ups often don't have the resources to staff a security team, or they might not feel the need to have one. But applying the "SSE model" discussed in this article they too can increase their application security while maintaining the speed of development. And instead of a dedicated team, consider contracting an external expert to assist and teach your developers security practices. This will train your developers in secure development and create a long-lasting culture of software security in your organization. Take a look at our software security services to learn how we can help.
