Secure Coding Training To Break ‘the Bug Cycle’
In 2010, when I was managing the portfolio of COBIT training solutions, I wrote an article about software development for ISACA’s COBIT Focus newsletter. The article explained how COBIT could support the software development lifecycle. While things have changed tremendously in the world of software development – some examples include COBIT being updated to Version 5, Axelos’ launch of their RESILIA™ Cyber Resilience Best Practice, the rise in popularity of ISTQB and the boom in mobile development – what hasn’t changed much is what we might call:
The Sad Cycle of ‘Secure’ Software Development
- Programmer produces code that is believed to be secure and bug-free.
- Product is tested. 26 bugs are found of which 10 are security related.
- Programmer fixes 16 of the bugs and explains to the testing department that the other 10 are not really bugs.
- Testing department finds that five of the fixes did not work and discovers 14 new bugs.
- Repeat step 3.
- Repeat step 4.
- Due to pressure from the business and an extremely premature product announcement based on an overly optimistic programming schedule, the product is released.
- Users find 139 new bugs.
- Original programmer is no longer with the company.
- Newly assembled programming team fixes almost all of the 139 bugs, but introduces 567 new ones.
- Original programmer sends underpaid and overworked testing department a postcard from Hawaii. Entire testing department quits.
- The product is hacked and a data breach is the result.
- Company’s stock plummets as result of the breach and it is bought in a hostile takeover by a competitor using profits from its latest release, which has 687 bugs.
- New CEO is brought in by board of directors. He hires a programmer to redo program from scratch.
- Programmer produces code that is believed to be secure and bug-free…
While this anecdotal situation is, of course, a bit exaggerated, the nature of the example is applicable to many of your clients:
Things go wrong and will go wrong, but finding the correct improvements and driving the change is another story.
During a session on secure programming, Vincent Jentjens, CEO of the Security Academy, mentioned that many software developers don’t know how to build secure software.
What’s needed is more secure software, NOT more security software.
Vincent Jentjens in Verizon Data Breach Investigations Report
The quote summarizes it all and shows there’s room for improvement.
What You Can Do; Secure Coding Training
Do your clients need software that’s developed to be secure from the start? They probably do.
Many opportunities exist for you as a provider of IT training to support clients improving their software development lifecycle. You can train your client’s employees on frameworks and best practices to improve the situation as presented in the software development lifecycle above with secure coding training.
In 2010 I explained how COBIT can be used to improve the software development lifecycle – that’s obviously still the case.
Looking back, Google Trend information shows that COBIT is slightly less searched for since 2010 which shows that the framework has matured. ISTQB has slightly grown over the last year and the growth of cybersecurity is no surprise. The same goes to development for mobile (e.g. see CMAP).
Have a look at the training content we have for software engineers – Secure Coding – ISTQB, CMAP, Axelos’ RESILIA is a bit broader and focuses on the IT, Risk, and Security functions in the organization, while all core business functions would benefit as well from understanding the risks and benefits of effective cyber resilience. Agile and Scrum can also be of help.
And if you want to get the conversation with your clients and prospects started, copy the Software Development Lifecycle above and send it along. Big chance it’s not too far off from the truth.