The "Secure SDLC"

Long before broken applications became the bane they are today, I worked on several software engineering projects and "secure software" projects including what we thought of as adding security to an SDLC.  The first problem was to agree an SDLC -- surprisingly contentious in itself.  The next was to agree requirements, which is where things tended to fall apart.  Policy dictates protection requirements but policy tends to be pretty useless when you are building something, it is typically written at the wrong level.  So, back to Step 1, agree an SDLC.  The SDLC must address all the big steps to be performed in the development processes.  Document Requirements, Design the solution, Implemement (code) the solution, Test the Code, etc.  In our complex world systems often use third party components, external networks and other bits and pieces sourced from hither and yon.  Then there is the code we do write.  We know quite a lot about web app vulnerabilities.  Often they result from a failure to adequately interrogate user input, it is a really silly mistake that is way too common. Software Engineering offers solutions, but the problem with the solutions is that they draw out development schedules, increase costs, require relatively strict discipline, and put harsh demand on management for rigorous controls and adherence to documented standards.  It's all way too much in this age of undisciplined developers and budgets that have been cut to the bone.

One way to document requirements is to write a set of development, code, and test standards that everyone follows.  This is a demanding product by its self and figure it will take years and  much Sturm und Drang (drama) before an end product is available. 

Securing an SDLC sounds simple and can be initiated with the best of intentions that usually quickly dissolve in contentious arguments attacking the details.  That is long before the first line of code is written and the first broken app is attacked and data looted.