In last week’s post, we discussed the first four elements in a Secure Software Development Lifecycle (SSDLC) model. As indicated before, the content of the “activity boxes” generally depends on the development model and the type of project, and the definitions below can only serve as a starting point for a customized model:

5. Coding

Writing quality code does include several aspects, of which two educational aspects are particularly relevant for secure software development: using proven patterns, and following best practices that apply to the task at hand. The usage of proven patterns will help to create code that is easier to understand, easier to review, and easier to maintain – all of which will ultimately contribute to a more secure codebase. Following best practices prevents the developer from having to reinvent the wheel, and then probably miss some important spokes when doing so. A third aspect around secure coding includes static code analysis, which helps developers better understand their code before it is deployed. Depending on the static analysis tool used, the code to be analyzed need not even yet compile! Static code analysis can be a very helpful tool for the security architect running an SSDLC program, and there are several free and commercial tools available for this task.

6. Integration and Testing

Once the code is in a stage that compiles cleanly and produces executable artifacts, it is possible to begin runtime integration of the various components. This should start as early as possible, following the “release early, release often” paradigm, even if the “release” is just for the internal quality assurance (QA) teams. Besides the non-security related QA activities, the verification process should include security specific activities such as fuzz testing, manual black box security penetration testing, and automated black box security testing. There are several tools available for automated security testing, with a focus on automated web application security testing. A major motivating factor for this is the high cost of manual security testing. There are, however, strategies for QA that allow reducing costs while still providing in-depth manual pen testing services. A second important security activity during the integration phase is for the security architect to re-review the results from the requirements and design analysis with the team, and make sure that the requirements have been correctly implemented, and the attack surface meets the results from the threat analysis step.

7. Release and Deployment

Once the final security review has been completed and the product is being deployed, the product team should already have a solid plan about how to respond to security incidents, create fixes for security issues discovered in production, quickly deliver them to the affected customers, and communicate the solution. Depending on the development model of the specific product, the team may also need to create an asset archiving strategy to make sure the required artifacts are available for maintenance later on. The team should also lay the foundations for a deployment security strategy, which includes documentation and best practices that are crucial to securely configuring the product.

8. Operations and Maintenance

The team operating the solution is responsible for deployment security, building on the foundations led earlier during the final development stages. While the operations team, which can be an internal team or a customer’s team, is responsible for securely operating the solution, the development team still has maintenance responsibilities. There are some development models that delegate maintenance tasks to a dedicated team (e.g. a “Current Product Engineering” / CPE teams), while other models (in particular agile models) only have one team that is responsible for the entire lifecycle of a product which includes operations and maintenance. In either case, the team responsible for maintenance must execute the incident response plan created earlier, and make sure that any fix that addresses security vulnerabilities or privacy violations is ported to all supported versions of the product.

There are many resources available to help an organization build their own SSDLC process, and also support them in creating metrics on how successful their program actually is. Examples include BSIMM and OpenSAMM, which provide excellent metrics on process definition and execution. There are other approaches which include processes implemented by major software vendors (e.g. Microsoft’s SDL) and consulting companies, as well as processes that may be mandatory when working with specific customers (such as the currently under-discussion NIST process which will be helpful when working with US government agencies). While all of these processes differ slightly in how and when specific steps are performed, good processes should be customizable to individual organizations – and they should actually be customized! Trying to employ a heavy-weight process that has been designed for a very policy-driven organization on a small startup will most certainly fail, while a process that works for a small startup will usually not work without modifications for a big corporation. Yet despite any customizations, the SSDLC process chosen should remain easily translatable to address new market segments and also give customers the opportunity to compare the program with other models.