Let’s face the reality: constrained by resources, many software developers ignore security entirely until they face an incident, or are tackling security by just focusing on the options they think to be the cheapest – which usually means just going through a checklist for finding some of the most common problems. But is this really the cheapest option? Just think about it: How much does it cost if the news are full of your device being broken or website being hacked again?
To date the software development community has learned the lesson: security started to be interwoven in the whole of the product development lifecycle. But do not forget: while – in theory – engineers have to be vigilant, eliminating every single bug in the code to make a product secure, for an intelligent attacker it is enough to find a single remaining vulnerability in a rarely-used module to use it as a vehicle for committing cyber-crime.
During the 2000’s the software industry started to realize the fact that in the long run, investing in their own employees is the most effective way of doing security. Training became the key initial phase in the Microsoft Security Development Lifecycle, and is also a standard practice within the Building Security in Maturity Model followed by many. Companies started to reserve more and more from their security budget to educate their employees, as education tackles the problem of security right at its source: the engineer.
But, just as we can’t put a policeman on every corner, assigning a dedicated security expert to a development group is not enough (still better though than not doing anything at all). Usually a single small mistake committed by one of the engineers is the root cause of a complete system compromise, and so the overall average preparedness of all involved software architects, programmers and testers is the one that actually counts.
From project management point of view, it is an easy formula: your engineers work hard each day, and produce vulnerable code, resulting in hundreds of security bugs yearly…
…and to correct.
You can send those programmers to a secure coding training, and they’ll start to write secure code from their next working day. The choice is yours.
A special prudence is needed however to teach security practices to software engineers: the trainer should not only be an experienced software developer, but also has to have strong security expertise. The courses should be practical but still go into enough theoretical details; shown problems should be supported by exercises giving hands-on experience, otherwise developers will forget most of the issues the next day; and classes should be intensive so they don’t pull away people from their everyday work for too long.
Our Secure Coding courses were formed based on a decade long expertise in product security and security research. In this sense with our courses we teach what we do. With a track record of thousands of attendees worldwide, the trainings in our portfolio are specifically prepared to serve diverse development groups of large companies developing any kind of software.
About Ernő Jeges - Instructor at Informator
Ernő has been a software developer ever since his childhood, working in the area of product security and security research for nearly fifteen years now. He has actively taken part in the elaboration of all course materials of SCADEMY Secure Coding Academy, and is the leading trainer with several years of teaching experience in both academic and industrial domain; he has held numerous secure coding courses for leading software developing companies all over North America, Europe, Africa and Asia.