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

 

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
Cyber-Flood Friday
Cyber-Flood Friday

Welcome back to Cyber-Flood Friday! This week I discuss the evolution of DDoS through 5 methods of growth, ...

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...

×

Schedule a live demo

First Name
Last Name
Company Name
!
Thank you!
Error - something went wrong!