Three Reasons Why a One-Size-Fits-All Secure SDLC Solution Won’t Work

Wednesday, May 08, 2013

Rohit Sethi


When we ask security contacts at our enterprise clients “What software development methodology does your company use?” - they usually pause for a moment and answer “everything.”

Individual development teams tend to adopt processes that work best for them. Heterogeneous development processes wreak havoc on plans for adopting enterprise-wide secure SDLC efforts.  There are at least three reasons why development teams within the same company have different development styles, including:  

  • Business needs: Large companies are often composed of units in different kinds of business. For example, a large media conglomerate could have Internet providers, movie studios, and a retail store division. The customers, employees and supply chain of each business unit also differ, often impacting the way software is developed or procured. Developers at the brokerage department of a bank might work at warp speed to get incremental improvements on trading times, whereas the retail group might be very careful about the pace of change.
  • Growth through acquisition: Many corporate acquisitions include the acquired company’s software and development teams. Each company likely had a different corporate culture that impacted the way their respective teams worked. For example, a small start-up software shop may value developer autonomy and lack of process while a larger software vendor may value risk management and accountability. The former may lean towards a self-organized team without formal project management while the latter may have a central Project Management Office (PMO).
  • Software type: Teams that ship software on embedded devices are often very careful about requirements analysis because the cost of shipping an update is sky-high. On the other hand, teams that build ecommerce web portals may deploy hundreds of changes every day and spend very little time in requirements planning.

Security practitioners should keep this in mind when designing a secure SDLC effort. Forcing a security process on development teams that doesn’t take into account the way they develop software is a recipe for disaster. A good goal to have for secure SDLC is to minimize the impact on the team’s existing software development practice, which may mean investing more time up front to give development teams options on how to bake security in a way that works for them.  

Cross-posted from the SD Elements blog.     

Possibly Related Articles:
Enterprise Security Policy Webappsec->General
Software SDLC Development Code
Post Rating I Like this!
John Roberts Software developer need to be more careful while designing software and applying security levels to the website.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.