One Size Fits All won’t Work for your Appsec Program

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 clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.