I could not agree more; however, I am not sure I fully agree with the suggestions. It is suggested, above all, that Developers should take on the burden. Moreover, the article sort of suggests that securing the code is central to securing the enterprise.
I have been recently speaking to a highly innovative company in the UK whose main product is Software based. In a nutshell, they develop all-software contact centre solutions around which companies can keep in touch with customers over a plethora of channels. As such, secure code is of paramount importance.
Question is, this is not enough and, more than suggesting a 4-fold approach to a cyber security programme, I would never put the burden on secure coding on the developers.
The 4 work packages I have suggested should be obvious:
- the internal organisation operations
- the product delivery plan -- for the case of installing their products in the client but having no further responsibility over operations after a signoff
- secure software development lifecycle (S-SDLC)
- secure hosted operations
As for the role of developers, they should keep doing what they are doing now -- but the whole project delivery needs to be adjusted. Quite critical is to engage the developers in Risk Assessments and Table-Top Exercises before and after implementation. Engaging with 3rd parties (such as pestesting or code analysis) or having a non-developer (the CTO if needed) to do code sanitisation are key steps that do not need to interfere with the normal, and always personal, development style.
Overall, most of implementing a Secure-SDLC can be done around the current practices and free-style of each developer. Key steps to achieve this is by inserting extra steps in their release plan -- so to prevent design/implementation flaws --, engaging with 3rd party services, designing policies that enable the cyber security office to vet a release with adequate checks and reserving some resources for software maintenance at the security level.
My message being: do not drop the onus of security on the developers: let tehm freely work, add security as just another well-defined/deliverable requirement and build the rest around them so they can focus on the key functionality.