Browse DevX
Sign up for e-mail newsletters from DevX


Security in All Phases of the Software Development Lifecycle

When it comes to secure coding, today's typical software development lifecycle (SDLC) is setting developers up for failure. Many in the software security space believe all the phases of the SDLC—not just testing—should participate in security assurance.

etween project deadline pressure and user demand for the latest software features, security often isn't the highest priority for development teams. Many times, eliminating vulnerabilities is seen as a task that someone or, in larger organizations, a team performs in the testing phase at the tail end of the software development lifecycle (SDLC), after the developers have completed the code. But when it comes to secure coding, this typical sort of SDLC is setting developers up for failure.

The emphasis on security in the SDLC at the recent RSA security conference, as well as secure SDLC initiatives at software giants such as Microsoft, indicate that the old way may be changing. Many in the software security space believe all the phases of the SDLC—from requirements through deployment—should participate in a common activity: security assurance. Security tools vendors in particular are promoting the idea as an industry best practice, because they know their products will produce best when the organizations purchasing them have security implemented throughout their development processes.

Jack Danahy, CTO and founder of OunceLabs, makers of source code analysis technology, says a lot of people blame the developer for insecure software, seeing them as the ones who create the problem. "Our philosophy is the problem was the way these developers were asked to build the software."

The Early Bird Catches the Worm

Jeff Williams 
Jeff Williams, CEO, Aspect Security

Every software consumer ostensibly has an expectation of security, yet it often isn't part of the discussion during the requirements-gathering phase of the SDLC. The requirements should include the security expectation, because, after all, the developer programs only to those requirements. Jeff Williams, CEO of the application security services company Aspect Security, thinks software organizations today aren't doing enough at this stage. "They think through the functional requirements, but they don't think through the security requirements right upfront," he explained. "That metric falls through, so it doesn't get into the software architecture."

During a RSA session titled "Baking Security into the Development Lifecycle", Herbert Thompson, Ph.D., chief security strategist for Security Innovation, said "We're used to thinking: 'what are the functional needs of this software product?' From the requirements phase, we need to ask the customer what they expect for security."

Herbert Thompson, Ph.D. 
Herbert Thompson, Ph.D., Chief Security Strategist, Security Innovation

Thompson pointed out that for customers in government-regulated industries "security's becoming a non-negotiable expectation," but he also acknowledged that those in other industries often don't know what their security needs are. The requirements phase is a perfect time to guide the customer or user through the possible risks so they can make informed decisions about security tradeoffs.

Getting the customer's buy-in at this early stage will avoid conflicts not only when the software is less secure than expected, but also when developers proactively provide more security at the expense of a desired feature. Fortify Software CTO Roger Thornton likens this scenario to hiring an architect to design your dream house. "And when the contractor built it, you went in and saw that the fireplace in the bedroom was missing. You ask why and he says it's too dangerous. Well, [the contractor] didn't ask."

To give the user and the developer a clear assessment of the risk, threat modeling or developing abuse cases for the software in development is a widely recommended technique. "Any organization that goes through carefully building up these cases with both the users and the developers is fine from then on, because [as a developer] I'm not doing security to make some security guy happy, I'm doing security because I saw clearly a way that it could be compromised," said Thornton.

Microsoft Senior Program Manager for Security Engineering Michael Howard, who co-presented the "Security into the Development Lifecycle" session with Thompson, said once software reaches design, "threat modeling is the only way to properly implement security at this phase."

Roger Thornton 
Roger Thornton, CTO, Fortify Software

He added that Microsoft has developed some 1,099 threat models internally. The models and abuse cases can take many forms as one tries to get into the mind of an attacker and identify all the ways he may attempt to break or exploit the software. However, according to Thornton, they all need to address three essential considerations:

  • Who are the potential abusers who will compromise your system?
  • Which techniques might they use?
  • What would the impact be?

Thanks for your registration, follow us on our social networks to keep up-to-date