The digital transformation that has swept across all industry sectors means that every business is now a software business. Whether you’re selling software directly to your customers or developing it to run your operations, your organization needs to protect your bottom line by building trust in your software without sacrificing the speed and agility that will keep you competitive in your market.
However, many organizations still lag behind when it comes to building security into their software development life cycle (SDLC). Too many development teams still think of security as a bottleneck—a problem that forces them to rework code they thought was finished, and that prevents them from getting cool new features to market.
But insecure software puts your business at increasing risk. Cool new features aren’t going to protect you or your customers if your product is open to exploitation by hackers. Your team needs to integrate security by developing secure software processes that enable, rather than inhibit, the delivery of high-quality, highly secure products to your market.
Ongoing reports of data breaches and supply chain attacks demonstrate that compromised software can have a devastating impact on your business. When software risk equates to business risk, it needs to be prioritized and managed proactively. To manage risk and remove friction from your organization’s digital transformation initiatives, your application security programs must “shift everywhere.” This means that security must move from being the last thing development teams address to a series of processes and tools that are integrated into every stage of the application development process. And security programs work best when development teams embrace tools and solutions that plug seamlessly into development toolchains and workflows.
The SDLC is a well-established framework for organizing application development work from inception to decommission. Over the years, multiple SDLC models have emerged—from waterfall and iterative to, more recently, agile and CI/CD. Each new model has tended to increase the speed and frequency of deployment.
In general, SDLCs include the following phases:
In the earliest SDLC systems, organizations waited until the testing stage to perform security-related activities. Worse yet, in many cases, insecure code went out the door because of time constraints. This is why teams instituted “shift left” processes to bring security activities into alignment with development. As SDLC systems have evolved even further, this process has expanded to the idea of “shift everywhere,” which integrates security concerns into all stages of development.
The later a bug is found in the SDLC, the more expensive it becomes to fix. When a bug is found late in the cycle, developers must drop the work they are doing, and go back to revisit code they may have written weeks ago. Even worse, when a bug is found in production, the code gets sent all the way back to the beginning of the SDLC. At this point, the domino effect can kick in, and fixing bugs winds up bumping back other code changes. So not only is the bug going to cost more to fix as it moves through a second round of SDLC, but a different code change could be delayed, which adds costs as well.
The better, faster, and cheaper approach is to integrate security testing across every stage of the SDLC, to help discover and reduce vulnerabilities early and build security in as you code. 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. There is also the Secure Software Development Framework from the National Institutes of Standards and Technology (NIST), 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. You can evaluate your security program against programs at other organizations. Building Security In Maturity Model (BSIMM) can help you do that. For the past decade, BSIMM has tracked the security activities performed by more than 100 organizations. Because every organization and SDLC is different, BSIMM doesn’t tell you exactly what you should do, but its observational model shows you what others in your own industry are doing—what’s working and what isn’t.
Building Security In Maturity Model (BSIMM) is a data-driven model developed through analysis of real-world software security initiatives. The BSIMM report represents the latest evolution of this detailed model for software security.