There are various secure development lifecycle models. Some of them (like the Microsoft SDL – http://www.microsoft.com/security/sdl/default.aspx) are representing the development process as a timeline, others are representing it as a circle. I personally like the circle representation better, because it symbolizes the life “cycle” very well, and makes it pretty clear that the work does not end after the code has been released, but usually goes into the next round for the next release.

The circle below shows a representation of the Secure Software Development Lifecycle (SSDLC) process similar to the one I created for various businesses in HP, and that I use when I am training teams on secure software development. It is rather generic, which allows it to tie in with existing business processes and development models.

The SSDLC process I usually use is (like many others) built around a custom security policy, security standards, and security best practices.

The security policy is commonly defined by the organization developing the product. The policy may include all kinds of assertions that the organization makes around software development. I have seen policies that are rather philosophical (“we will do our best to crate secure software and fix defects timely”), and policies that are very stringent and precise (“a medium security defect will be fixed in 5 days or less”).

From my experience, having a security policy is more important than the content of the security policy (at least while the content is somewhat useful), because it shows that an organization is committed to security. However, it is crucial that the security policy is known to everyone in the organization, and that everyone is following the policy on peril of losing their job or at least being removed from the project. The security policy must be absolutely binding for everyone, and “everyone” includes people managers, developers, architect, legal, marketing, and everyone else who is working on the project. Such a stringent policy helps to create awareness and gives the security person in charge for the project (for instance, the security architect) the instrument necessary to delay or even stop delivery of the project in case of major security flaws. This may sound very drastic, and it is by far better to rely on good arguments to convince the team members to address a major security issue instead of wielding the security policy club. However, experience shows that without such a powerful security policy, security goals may be quickly sacrificed to meet a release deadline. On a side note, HP has a very strong security policy, and everyone values it so highly that in all the years I have worked as a security architect for HP, I never had to cite it even once.