Learn about the phases of a software development life cycle, plus how to build security in or take an existing SDLC to the next level: the secure SDLC.
When it comes to creating, releasing, and maintaining functional software, most organizations have a well-oiled machine in place.
However, when it comes to securing that software, not so much. Many development teams still perceive security as interference—something that throws up hurdles and forces them to do rework, keeping them from getting cool new features to market.
But insecure software puts businesses at increasing risk. Cool new features aren’t going to protect you or your customers if your product offers exploitable vulnerabilities to hackers. Instead, your team needs to integrate security into the entire software development life cycle (SDLC) so that it enables, rather than inhibits, the delivery of high-quality, highly secure products to the market.
A software development life cycle (SDLC) is a framework for the process of building an application from inception to decommission. Over the years, multiple SDLC models have emerged—from waterfall and iterative to, more recently, agile and CI/CD, which increase the speed and frequency of deployment.
In general, SDLCs include the following phases:
In the past, organizations usually performed security-related activities only as part of testing—at the end of the SDLC. As a result of this late-in-the-game technique, they wouldn’t find bugs, flaws, and other vulnerabilities until they were far more expensive and time-consuming to fix. Worse yet, they wouldn’t find any security vulnerabilities at all.
The Systems Sciences Institute at IBM reported that it cost six times more to fix a bug found during implementation than one identified during design. Furthermore, according to IBM, the cost to fix bugs found during the testing phase could be 15 times more than the cost of fixing those found during design.
So it’s far better, not to mention faster and cheaper, to integrate security testing across the SDLC, not just at the end, to help discover and reduce vulnerabilities early, effectively building security in. Security assurance activities include architecture analysis during design, code review during coding and build, and penetration testing before release. Here are some of the primary advantages of a secure SDLC approach:
Generally speaking, a secure SDLC involves integrating security testing and other activities into an existing development process. Examples include writing security requirements alongside functional requirements and performing an architecture risk analysis during the design phase of the SDLC.
Many secure SDLC models are in use, but one of the best known is the Microsoft Security Development Lifecycle (MS SDL), which outlines 12 practices organizations can adopt to increase the security of their software. And earlier this year, NIST published the final version of its Secure Software Development Framework, which focuses on security-related processes that organizations can integrate into their existing SDLC.
If you’re a developer or tester, here are some things you can do to move toward a secure SDLC and improve the security of your organization:
Beyond those basics, management must develop a strategic approach for a more significant impact. If you’re a decision-maker interested in implementing a complete secure SDLC from scratch, here’s how to get started:
Does your organization already follow a secure SDLC? Fantastic, well done! But there’s always room for improvement. One way to determine your standing is by evaluating your security program against real-life programs at other organizations. The Building Security In Maturity Model (BSIMM) can help you do that. For the past decade, the BSIMM has tracked the security activities performed by more than 100 organizations. Because every organization and SDLC is different, the BSIMM doesn’t tell you exactly what you should do. But its observational model shows you what others in your own industry vertical are doing—what’s working and what isn’t.
This post was originally published Jan. 21, 2016, and refreshed September 28, 2021.