How To Bake Security Into Software Development

[Excerpted from "Secure SDLC: Reducing Risk Throughout The Application Development Process," a new report posted this week on Dark Reading's Advanced Threats Tech Center.]

It’s been nearly a decade since Bill Gates sent his well-publicized memo making "trustworthy computing" particularly software security — the highest priority for all Microsoft employees. But security still gets short shrift when it comes to the application development process in most companies.

The maturity of a company’s software development life cycle (SDLC) correlates directly to the level of security applied to the development process. An organization in which security is integrated into the SDLC process early — where company stakeholders “get it” — is the exception rather than the rule. Typically, security is bolted on at the end of the development process, as an afterthought, almost assuring avoidable vulnerabilities in the final code.

Too often, it takes the finding of a serious security flaw and the release of exploit code to cause people to snap to attention and realize there is more to software development than implementing features and getting product out the door. There is also a responsibility to ensure the software being produced won’t introduce vulnerabilities into corporate networks or those of their clients.

Software development, like any other project, benefits the most from security when it is included from the start. Companies that shortchange security in their SDLC are putting themselves and their customers at risk, as most breaches stem from external attacks and penetrate at the application layer.

There are natural points in the SDLC at which integration of security efforts is optimal. The basic SDLC model encompasses five stages: analysis, design, development, testing and deployment. Depending on the development model (agile, spiral or waterfall, for example), the stages may be named differently, even combined, but the basic structure remains the same.

The SDLC analysis, or requirements gathering, stage involves documenting the business requirements for the software being developed. These include business, functional, data, user, system, interface and other requirements. This phase can be the most difficult because it entails capturing all the requirements of the application’s consumers, who may be internal employees, business partners or customers.

The analysis stage is a good time to conduct basic threat modeling, to understand the threats and vulnerabilities that may impact the stated goals of the software. The threat modeling process doesn’t need to be as detailed as it is during the design stage, but it helps participants get into a security mindset right up front, and it feeds directly into the next stage.

In the design stage, requirements gathered in the analysis stage are transformed into technical specifications. The project team puts together detailed functional specification documents that define the technology choices, supporting hardware and software architecture, and anything else necessary to meet the project’s requirements.

Security’s role during design is to continue with threat modeling for each functional component defined in this stage and prioritize mitigations to address the identified threats.

To get a full description of the five phases of the SDLC — and to find out how security should be integrated into each of them — download the full report.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.