Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Why existing secure SDLC methodologies are failing

public://webform/writeforus/profile-pictures/sherif_high_rez.jpg
Sherif Koussa CEO, Software Secured
Un-aligned lock
 

Increasingly, scale, automation, and growing costs are pushing organizations to adopt secure software development lifecycle (SDLC) methodologies. Although tools such as static code analysis and vulnerability scanning have been successful in improving application security, organizations have begun to recognize the value of the early integration of security reviews within the SDLC—most notably for its ability to drive down the cost of managing and fixing security-related bugs.

However, many of the methodologies used to do this, such as OpenSAMM, BSIMM, and Microsoft's SDL, take approaches that resemble inefficient, top-down waterfall methodologies. These approaches to secure SDLC are failing many in the industry, and new approaches need to be adopted.

Popular secure SDLC methodologies

As many experts recommend, software organizations often adopt a top-down approach to implementing secure SDLC methodologies. Although this approach has the benefit of ensuring the presence of components necessary to secure software development processes, it does not guarantee secure products.

The following is a short list of popular methodologies that are currently helping organizations integrate security within their SDLC.

  1. OpenSAMM: The Software Assurance Maturity Model (SAMM) is an OWASP project that guides the integration of security within the SDLC. The 12 activities described are grouped in four categories: governance, construction, verification, and deployment.
  2. BSIMM: The Building Security in Maturity Model (BSIMM), developed by Cigital, consists of 12 practices divided into 4 domains: governance, intelligence, secure software development lifecycle (S-SDLC) touchpoints, and deployments.
  3. SDL: The Microsoft Secure Development Lifecycle aims to enable the creation of secure software that is compliant with regulatory standards while reducing development costs. Microsoft started promoting this methodology that emphasizes the importance of secure coding practices following the CodeRed and Nimda worms, in 2001 and 2002, respectively.

Secure SDLC methodologies have made a number of promises to software developers, in particular the cost savings brought about by the early integration of security within the SDLC, which could help avoid costly design flaws and increase the long-term viability of software projects.

However, these methodologies are not without faults.

Waterfall SDLC methodologies rain on agile environments

Popular methodologies often divide organizations into business units or business functions and rely on starting certain activities only after other activities are finished. This organizational structure assumes that business activities occur in a specific linear order, a proposition that agile frameworks have difficulty reconciling.

For example, Microsoft SDL defines a practice called “establish security and privacy requirements,” which proposes developing security and privacy objectives early in order to minimize scheduling conflicts, but this also has the effect of creating a rigid timeline not generally found in agile environments.

Under agile frameworks, with their emphasis on continuous integration and continuous deployment, few software development teams have created documents that detail a long-term schedule. That makes the implementation of such waterfall-centric secure SDLCs difficult for agile teams. 

Implementation costs are high

The costs associated with the implementation of SDLCs can be prohibitive. By OpenSAMM’s own estimates, implementing each of its 12 activities would cost roughly $90,000 when using the estimated hourly costs depicted in the second column of the table below.

Although $90,000 to secure the entirety of an organization's development process may seem like a good deal, three caveats should be mentioned.

  1. The $90,000 estimate only includes the cost of implementing OpenSAMM’s first maturity level and does not include the costs of the second or third levels, which would undoubtedly drive up the final cost considerably.
  2. A $90,000 estimate is conservative. OpenSAMM allocates five to nine days per year for the code-review activities required of the first maturity level. Consequently, this is either a very small organization, or the estimate is incomplete, perhaps considering only setup costs and not ongoing operational expenses. Having organized and participated in countless code reviews, I can attest that they are a time-intensive activity and in the majority of cases would easily exceed the $90,000 estimate.
  3. Lastly, the value of implementing activities recommended by the methodologies is often lost in the process, and the activities are implemented solely because they exist as requirements on a checklist that must be fulfilled to move forward. Implementing vulnerability scanning, for example, does not guarantee that scans will even be looked at, much less acted upon. The context of activities and the interplay of their related metrics must be understood if a value is to be derived from their implementation. 

Bottom-up secure SDLC

Perhaps SDLC methodologies should be approached and implemented not from the top down, but from the bottom up. Instead of implementing activities to satisfy a checklist requirement, you could start by first defining your objectives and then identifying and employing activities that would most effectively help you reach those objectives.

For this approach, it’s necessary to start by identifying the metrics key to your organization’s success. In my opinion, there are two metrics that matter: the total number of vulnerabilities, and their average remediation time.

  1. Total number of vulnerabilities: The sole purpose of any methodology is to help an organization systematically and consistently produce code that is more secure. Finding and reducing the number of vulnerabilities in your code means you’ve produced a more secure final project.
  2. Average remediation time: Fixing bugs in post-production is exponentially more expensive than fixing them in pre-production, for two important reasons. First, the longer bugs exist, the more time attackers have to take advantage of them. Second, as developers move on to different projects or, in some cases, other companies, the ability of an organization to fix security issues decreases, which then increases the costs associated with fixing those issues.

Once key metrics have been identified, start by implementing activities that can help you reach your metric targets as soon as possible. The selected metrics will guide you in identifying and implementing activities that can help you reach your targets. Secure user stories, security code review, penetration testing, and environment hardening are just some activities that could prove useful.

Post-analysis action items

After the initial implementation of activities, your focus should shift toward their continued investment and improvement. For example, if the implementation of security code reviews reveals an excessive number of bugs, investing in training to improve secure coding techniques could prove advantageous. Alternatively, if time to remediation is a concern, investing in a vulnerability management system could help developers better manage vulnerabilities and cut down remediation time.

Agile, metric-driven methodologies

The present technological landscape requires companies to take software security seriously in order to be successful, and a growing number have done just that, shifting left and adopting secure SDLC methodologies.

While most organizations rely on agile software development frameworks such as Scrum, many secure SDLC methodologies are designed for the waterfall approach. Unfortunately, the focus on speed and automation demanded by DevOps means these methodologies are lagging behind and require a great deal of manual effort for them to keep up with a rapidly evolving development landscape.

The need for lighter, agile, and metric-driven methodologies in today’s agile, development-driven world has become a necessity if developers are to stay ahead of the ever-growing number of security challenges they face on a daily basis.

Keep learning

Read more articles about: SecurityApplication Security