The False Economy of Security Debt

While Australia is dealing with the recent data breach of Optus, confused customers - as they work to get a new driver's license -  are left wondering how this could happen.

 If you are a software developer, however, there is a good chance your immediate thought was not “how could this happen?”, but “thankfully it wasn't my team - this time”. We know it's a matter of when, not if. Security is usually the afterthought when writing software: it's the work that gets dropped when sales-driven deadlines rise up to derail roadmaps. Even if we care about it, it is never a top priority. It's the tech debt that gets accumulated to be resolved when we are less busy (re: never).  

Tech Diversity Lab’s capability gap analysis shows that application security is in the top 2 missing skills in the majority of teams: where software developer’s knowledge and practice of secure coding is “below level”. 

And yet, we know trading off security-debt is a false economy. The State of DevOps research demonstrates that teams who practice secure coding techniques are better able to protect customer’s data and respond quickly to attacks, and are faster at implementing changes for new regulatory requirements, such as GDPR. This is good for the top line, as it builds trust with customers and maintains the company's positive reputation. Dev teams that establish these security practices have reduced developer burnout, and deliver more market value, instead of sinking time into responding to inevitable security incidents. 

What does ‘shifting left’ on security look like?

“Shifting Left” refers to moving security concerns earlier in your system development life cycle, instead of it being the final step when it is harder to change things. Implementing secure coding practices means dev teams are considering security from the design phase, right through to release and monitoring: no longer testing for vulnerabilities just before something is deployed to production, or worse, when reacting to an incident. Where there is a security team, they are consulted on the architectural design before a line of code has been written, and help to test and approve third-party tools and libraries. Teams include static analysis and other vulnerability detection in their development and CI/CD pipelines. Everyone in the team is trained on handling Personal Identifiable Information (PII) and understands common security vulnerabilities.
‍

This does not have to be done to the detriment of delivering value: teams with the best security practices also tend to be those who deliver faster and more frequently as well. 

To find out more about how your secure coding practices stack up, talk to Tech Diversity Lab.  

‍