3 Reasons Why a One-size Fits all Secure SDLC Solution Won’t Work

March 2, 2015


3 Reasons Why a One-size Fits all Secure SDLC Solution Won’t Work

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.

One size doesn’t fit all… If you are a Fortune 1000 company, contact us to understand how to scale your application security program to fit your needs.

Click here to sign up for the report



Previous Article
Debunking Myths: Penetration Testing is a Waste of Time
Debunking Myths: Penetration Testing is a Waste of Time

Suppose you hire a consultancy to perform a black-box assessment of your software. After executing the test...

Next Article
DevOps & Software Security: Turning unplanned work into planned work
DevOps & Software Security: Turning unplanned work into planned work

Every IT worker I’ve met has heard me rave about The Phoenix Project. The book uses an all-too-realistic fi...

Learn how you can use SD Elements to integrate security into software development.

Watch Video