The essay is about SDLC, but on everything other than what SDLC is, why and how to implement it; topics that are already covered by tons of other writeups (including a few posts by yours truly.) Instead, this essay describes tips for properly deploying SDLC, again, not in terms of what it should consist of, but in terms of what to expect, and what to keep in mind so your SDLC actually works and perhaps even makes a difference.

If you are dealing with SDLC, or with security engineering in general, I recommend you just read this essay in its entirety. To spark your curiosity, here are some of the anecdotes I found to be worth rehashing:

• Watch out for the survivorship bias paradigm, which prevents the security practitioner from correctly assessing the success of his countermeasures.


• When you cannot measure outcomes, you revert to measuring compliance. It does not tell you how well you’re doing, but at least it makes sure you’re doing as much as others do.


• Unfortunately, there is very little scientifically-proven relationship between the best practices one deploys and the level to which security is strengthened as a result. (This reminds me of a post I once wrote: On the Purpose of Security Standards, claiming that some such standards do not inherently improve security but they are still useful for shifting liability.)


• Whenever a minimum bar is specified, this bar often becomes the maximum instead, because no one is ever incentivized to exceed it.


• You can never train people to do something which is not in line with their job function and incentive structure. Also in my opinion, most failed SDLC deployments can be traced back to someone not aligning the roles and responsibilities prescribed by the SDLC with those that were prescribed by the established business processes. Since the latter are well aligned with business outcomes and employee reward, the SDLC process is the one that gets starved, and rightly so.


• When deploying SDLC, you must be sure you are very well verse with the engineering processes you are integrating with. My favorite quotes in this regard:



In the same way that fixing a software vulnerability requires deep technical understanding of how computers work below multiple layers of abstraction, fixing a software development process requires a similarly thorough understanding of the development and release flow.

Done carelessly, new processes can trigger a strong auto-immune response from the organization.



• Finally, be patient. (Sounds easy, but I wish I remembered that on multiple occasions.)