Microsoft has there simplified SDL:

"The Security Development Lifecycle (SDL) is a security assurance process that is focused on software development."

"The process outlined in this paper sets a minimum threshold for SDL compliance. That said, organizations aren’t uniform – development teams should apply the SDL in a way that is suitable to the human talent and resources available, but doesn’t compromise organizational security goals."

For shops interested in adopting a secure SDL but without one in place or frightened by what it entails, what do you consider the simplest secure SDL to try out?

up vote 7 down vote accepted

Great question.
First, the "minimum" you quoted refers to Microsoft's minimum requirements policy, not necessarily the "industry best practices" minimum. Not that I'm saying its wrong, but the MS-SDL itself does go on to say that their SDL is not necesarily fitting for any organization outside of Microsoft... In fact the MS-SDL architects, such as Michael Howard is oft-quoted saying:

Don't do what we do, do what we did.

Which is to say, its not so much the prescribed requirements as they specifically appear in the document (though they might be mostly very good), but they repeatedly performed studies, including risk-based analysis, historical metrics comparisons, trend analysis, root-cause analysis, trials in different teams to see what "takes", etc.

There is not a well-defined, simple SDL you can just download install and go be secure. That point from MS is spot-on - you really need to tailor your SDL according to your specific organization, your teams, their proficiency, the types of products they're building, the current development process, the risk profile, etc etc. And that's really the best solution to "try out"...

Moreover, SDL is not a one-time thing, or even a question of defining and implementing the correct policy. Building an SDL is itself an ongoing process, which admittedly can take several years to implement completely. Microsoft did quite a few iterations till their SDL reached something exemplary... And it took another couple years to get it really ingrained in (most of) their developers. You can't really "try out" an SDL, because the benefit will typically not show within the first month or two - it really is a long term investment.

So, for orgs just starting out, and looking to define their SDL - I would suggest taking it slow, have someone with experience guide them in the process:

  • Start by mapping out the current situation, process, teams, experience, flexibility, etc.
  • If the teams + management are not 100% convinced of the need for SDL, and security in general, consider doing an initial security review just to drive home the problems... A pentest is often most useful here, simply because it can be quite visual (NOT because its needed for the SDL itself at this point).
  • Ensure at this point you have buy-in - both from an executive sponsor, and from the teams themselves. Without either, the SDL is doomed to failure.
  • Training! Developers like to do things right, if they know how.
  • Slowly add minimal additional security activities, according to the benefits you will receive for them, as compared to the effort invested - and the disruption to the dev teams. Remember, the point of the exercise is to get EVERYBODY involved in security, and not turn them off right away.
  • Set up security expertise, either in your team (as a security champion) or in a central team that everyone can talk to - and get them talking. Better yet, is a hybrid model of both (as in the MS model).
  • According to your capacity for additional security investment, in each cycle add minimal additional activities, on top of the previous ones. The point is to get them so used to doing one-two small li'l things, that it becomes second nature (almost) and it no longer "takes so very long to do this security stuff". Then you'll have bandwidth for more...
  • Gather metrics along the way, so you can tell what is working and what is not, and also to show the benefit from the SDL investment to management.
  • More training!

Now, the real problem is that list above, looks like a lot.
But it really isnt, since most of those bullets are "meta-activities". Some of them should probably be done by an experienced security guy/gal/consultant, with experience in implementing SDL in a similar type of environment as yours. Admittedly, still not so simple, but when I do this I put the emphasis on minimal disruption and ongoing investment. It can be done lightweight.

  • Not part of my answer, but I will point out one SDL that is not lightweight - OWASP's CLASP. Surprisingly, that stands for "Comprehensive Lightweight Application Security Process" - but it really is quite heavy (but it IS comprehensive, and quite good - just a bit... cumbersome). – AviD Nov 21 '10 at 10:17
  • Nicely summarized, still I think you need to invest in defining proper security requirements and make some mandatory or a product won't be shipped. Furthermore, I am pretty sure that it is impossible to have a product delivered vulnerability-free, therefore you need to describe and document a response process when vulnerabilities are found. A lightone is ok, for instance always have corrections checked with the security champions mentioned by AviD. The major challenge, though, is in case you would go for some Agile approach and then you need to a proper SDL! – Phoenician-Eagle Nov 22 '10 at 5:18
  • @Paul, I agree with your points, but those are included in the activities I mentioned. Of course those are some of them, as are threat modeling, coding guidelines, etc and more. Agile SDL is a challenge, but I do have some good solutions for that specifically. – AviD Nov 22 '10 at 5:48
  • 1
    you have your chance now:… – Phoenician-Eagle Nov 22 '10 at 8:24

I wrote a really good one once called the Continuous-Prevention Security Lifecycle (CPSL) and did a follow up retrospective. I think they are somewhat dated now, but they are what you asked for.

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.