What is the Software Development Lifecycle and Why is It Central to Software Security?

Last Updated on January 15, 2024

If “software is eating the world,” where does the lifecycle process of creating a piece of software begin and end? And where/how within that process can we reduce the cybersecurity risk associated with using that software?

To explain the intent and ramifications of new secure software mandates within the US federal government supply chain, especially the role of the new NIST Secure Software Development Framework (SSDF), Pivot Point Security’s Director of Cyber Security Solutions & Practices, Elzar Camper, joined a recent episode of The Virtual CISO Podcast. John Verry, Pivot Point Security CISO and Managing Partner, is the podcast host.

Maintaining software integrity

Understanding the software development lifecycle (SDLC) is a first step in securing software.

“I think sometimes people see ‘SDLC,’ and depending on where you fall in the IT world, it could be ‘systems’ or ‘software,’” Elzar notes. “We’re talking about software, not systems, and they are different processes.”

Whether it is formal or informal, an SDLC is basically a methodology for designing, creating, and maintaining software. How that methodology maintains the integrity of a piece of software is its most important reason for existing.

Collectively shifting left

An overarching way to improve software integrity across the SDLC is to “shift security left” to earlier in the SDLC. The massive time and cost savings associated with preventing security vulnerabilities versus identifying and fixing them in production is well documented.

So, why the longstanding resistance to introducing security best practices into SDLCs?

“I think the demand for people to get their products out to the market, the demand of being first to market, just makes this such a difficult process sometimes because people, historically, have seen security in the SDLC as slowing everything down,” Elzar explains. “So, the whole goal is how do we automate this and how do we really show security as a business enabler—a business driver versus a hindrance.”

As John points out, there’s a need to balance risk management effectiveness with operational efficiency.

“You’re not going to have a control without it having some level of impact,” John observes. “And I think as we’ve gone to a more DevOps oriented world, the way we can find that balance is by automating some of that security.”

Taking a risk-based approach

Elzar and John agree that a risk-based approach is the way to plan and implement security within your SDLC.

“Not every application needs the same scrutiny,” highlights Elzar. “The high-level task of how you go about implementing security into the SDLC is important and can be consistent per organization. But you’ve got to be careful to make sure that you’re not taking the same approach for every application you develop because every application has different data and interacts with different kinds of users. Take that risk-based approach to make sure that what you’re doing makes sense for the organization.”

More often, risk management starts with the security framework itself, e.g., what “level” of the standard you decide to implement. Tailoring the SDLC to the specific application risk involves doing some threat modeling. It’s also a check to make sure what you’re asking from your development team is realistic given time, skills, and resources.

What’s next?

To listen to the podcast episode on the NIST SSDF with Elzar Camper, click here.

Why is the SSDF such a big deal now for US government software suppliers? This blog post provides the details: The New NIST Secure Software Development Framework: Why It’s So Important for the USG Supply Chain