Secure Software Development Lifecycle (SSDLC)

Security is an important part of any application that encompasses critical functionality. This can be as simple as securing your database from attacks by nefarious actors or as complex as applying fraud processing to a qualified lead before importing them into your platform.

Security applies at every phase of the software development life cycle (SDLC) and needs to be at the forefront of your developers’ minds as they implement your software’s requirements. In this article, we’ll explore ways to create a secure SDLC, helping you catch issues in requirements before they manifest as security problems in production.

With dedicated effort and the right security solutions, security issues can be addressed in the SDLC pipeline well before deployment to production. This reduces the risk of finding security vulnerabilities in your app and works to minimize the impact when they are found.

Secure SDLC’s aim is not to completely eliminate traditional security checks, such as penetration tests, but rather to include security in the scope of developer responsibilities and empower them to build secure applications from the outset.

Why Is Secure SDLC Important?

Secure SDLC is important because application security is important. The days of releasing a product into the wild and addressing bugs in subsequent patches are gone. Developers now need to be cognizant of potential security concerns at each step of the process. This requires integrating security into your SDLC in ways that were not needed before. As anyone can potentially gain access to your source code, you need to ensure that you are coding with potential vulnerabilities in mind. As such, having a robust and secure SDLC process is critical to ensuring your application is not subject to attacks by hackers and other nefarious users. New tools such as application security posture management can help to provide a holistic view of the components of your application security setup, as well as provide context about vulnerabilities.

A Brief History of SDLC Practices

Software Development Lifecycle (SDLC) describes how software applications are built. It usually contains the following phases:

• Requirements gathering

• Analysis of the requirements to guide design

• Design of new features based on the requirements

• Development of new capabilities (writing code to meet requirements)

• Testing and verification of new capabilities—confirming that they do indeed meet the requirements

• Deployment of the new project

• Maintenance and evolution of these capabilities once the release goes out the door

7 Phases of SDLC

The Waterfall model is one of the earliest and best-known SDLC methodologies, which laid the groundwork for these SDLC phases. Developed in 1970, these phases largely remain the same today, but there have been tremendous changes in software engineering practices that have redefined how software is created.

Traditionally, software was written for highly specialized applications, and software programs developed using the Waterfall methodology often took years to release. Modern-day practices now focus on increasing the pace of innovation while continuing to build well-functioning software applications. Companies have moved on from Waterfall, with most using some form of the agile SDLC, first published in 2001.

Agile development advocates for splitting up large monolithic releases into multiple mini-releases, each done in two- or three-week-long sprints, and uses automation to build and verify applications. This allows companies to iterate much more quickly. Instead of the infrequent, monolithic deployments characteristic of Waterfall-driven applications, agile development often focuses on releasing new functionality multiple times a day, building software incrementally instead of all at once.

SDLC and Application Security

But what about the security of these applications? Back in 1970, most attacks required physical access to a terminal on the machine running the application. The world was also a lot less interconnected, reducing the risk of external actors impacting application security. As new software development methodologies were put into practice over the years, security was rarely put in the spotlight within the SDLC.

Instead, application security became the responsibility of IT security teams dedicated to application support. At first, applications were tested after their release only. This testing occurred in production environments, often on a yearly basis. Unfortunately, this meant that any potential vulnerabilities would be “out in the wild” for attackers to exploit for a number of weeks or even months before they could be noticed and addressed. As a result, most companies have since chosen to supplement production testing with pre-release security testing as well. This supplemental testing was placed on the critical path of the release, and applications needed to pass the security check prior to deploying the code to production.

This security testing step often takes several weeks to complete, lengthening the release cycle. What’s worse, its outcome is completely impossible to plan for: A security test may find just a few vulnerabilities that can be fixed in a few days or could find dozens or even hundreds of vulnerabilities. Fixing the vulnerabilities found could require significant code changes that replace entire underlying components, all of which will then need to be reverified against both the application requirements as well as another security test.

This can—and often does—set application developers back by weeks as they continue to try to meet now-impossible release deadlines. This creates a lot of friction within organizations and has companies choosing between two bad options: “signing off” on risk and releasing an application with vulnerabilities or missing expectations on delivery targets (or both). What’s worse, it can cost up to 100 times more to fix an issue discovered this late in the SDLC than to simply fix it early on in the process (more on this later).

As the speed of innovation and frequency of software releases has accelerated over time, it has only made all of these problems worse. This has led to the reimagining of the role of application security in the software development process and creation of a secure SDLC.

What are the Secure Software Development Life Cycle Processes?

Implementing SDLC security affects every phase of the software development process. It requires a mindset that is focused on secure delivery, raising issues in the requirements and development phases as they are discovered. This is far more efficient—and much cheaper—than waiting for these security issues to manifest in the deployed application. Secure software development life cycle processes incorporate security as a component of every phase of the SDLC.

While building security into every phase of the SDLC is first and foremost a mindset that everyone needs to bring to the table, security considerations and associated tasks will actually vary significantly by SDLC phase.

5 phases of Secure Software Development Life Cycle

Each phase of the SDLC must contribute to the security of the overall application. This is done in different ways for each phase of the SDLC, with one critical note: Software development life cycle security needs to be at the forefront of the entire team’s minds. Let’s look at an example of a secure software development life cycle for a team creating a membership renewal portal:

Phase 1: Requirements

In this early phase, requirements for new features are collected from various stakeholders. It’s important to identify any security considerations for functional requirements being gathered for the new release.

• Sample functional requirement: user needs the ability to verify their contact information before they are able to renew their membership.

• Sample security consideration: users should be able to see only their own contact information and no one else’s.

Phase 2: Design

This phase translates in-scope requirements into a plan of what this should look like in the actual application. Here, functional requirements typically describe what should happen, while security requirements usually focus on what shouldn’t.

• Sample functional design: page should retrieve the user’s name, email, phone, and address from CUSTOMER_INFO table in the database and display it on screen.

• Sample security concern: we must verify that the user has a valid session token before retrieving information from the database. If absent, the user should be redirected to the login page.

Phase 3: Development

When it’s time to actually implement the design and make it a reality, concerns usually shift to making sure the code well-written from the security perspective. There are usually established secure coding guidelines as well as code reviews that double-check that these guidelines have been followed correctly. These code reviews can be either manual or automated using technologies such as static application security testing (SAST).

That said, modern application developers can’t be concerned only with the code they write, because the vast majority of modern applications aren’t written from scratch. Instead, developers rely on existing functionality, usually provided by free open source components to deliver new features and therefore value to the organization as quickly as possible. In fact, 90%+ of modern deployed applications are made of these open-source components. These open-source components are usually checked using Software Composition Analysis (SCA) tools.

Secure coding guidelines, in this case, may include:

• Using parameterized, read-only SQL queries to read data from the database and minimize chances that anyone can ever commandeer these queries for nefarious purposes

• Validating user inputs before processing data contained in them

• Sanitizing any data that’s being sent back out to the user from the database

• Checking open source libraries for vulnerabilities before using them

Phase 4: Verification

The Verification phase is where applications go through a thorough testing cycle to ensure they meet the original design & requirements. This is also a great place to introduce automated security testing using various technologies. The application is not deployed unless these tests pass. This phase often includes automated tools like CI/CD pipelines to control verification and release.

Verification at this phase may include:

• Automated tests that express the critical paths of your application

• Automated execution of application unit tests that verify the correctness of the underlying application

• Automated deployment tools that dynamically swap in application secrets to be used in a production environment

Phase 5: Maintenance and Evolution

The story doesn’t end once the application is released. In fact, vulnerabilities that slipped through the cracks may be found in the application long after it’s been released. These vulnerabilities may be in the code developers wrote, but are increasingly found in the underlying open-source components that comprise an application. This leads to an increase in the number of “zero-days”—previously unknown vulnerabilities that are discovered in production by the application’s maintainers.

These vulnerabilities then need to be patched by the development team, a process that may in some cases require significant rewrites of application functionality. Vulnerabilities at this stage may also come from other sources, such as external penetration tests conducted by ethical hackers or submissions from the public through what’s known as “bug bounty” programs. Addressing these types of production issues must be planned for and accommodated in future releases.

The Benefits of SSDLC

Secure SDLC is the ultimate example of what’s known as a “shift-left” initiative, which refers to integrating security checks as early in the SDLC as possible.

Doing so helps development teams properly plan releases, making it easier to catch and address issues that arise that could affect the release timeline. This is most certainly preferable to receiving an unpleasant surprise once the application deploys to production. SSDLC, therefore, helps keep releases on track.

What’s more, SSDLC at its core has the security efforts being led by the development team itself. This allows the issues to be fixed by the domain experts who wrote the software rather than having a different team fix the bugs as an afterthought. This empowers developers to take ownership of the overall quality of their applications, which leads to more secure applications being deployed to production.

While all the extra effort of security testing within the SDLC process may sound like a lot of work and expensive to build, today, the vast majority of it is being automated. This is particularly true for development operations or DevOps (more on this as follows). The secure SDLC environment requires frequent collaboration between DevOps and the engineers implementing the application’s functionality, and this collaboration needs to be incorporated into the SDLC itself.

By fixing these issues early in the process, development teams can reduce the total cost of ownership of their applications. Discovering issues late in the SDLC can result in a 100-fold increase in the development cost needed to fix those issues, as seen in the chart below.

IBM System Science Institute: Relative Cost of Fixing Defects, 2010

As demonstrated in Figure 2 above, transitioning to secure SDLC empowers development teams to build secure applications more quickly and may therefore be a worthwhile investment for organizations.

How to Ensure SSDLC?

Ensuring a secure SDLC requires a focus on both how the application operates and how the developers transform requirements into application code. Security must be at the forefront of the team’s mind as the application is developed. This may require a cultural change within your teams as well as automated processes and checks at each stage of software development.

Ensuring SSDLC for an application is highly dependent on the strengths and weaknesses of the software development team that is working on SDLC security, and as such, it is challenging to pin down a single secure SDLC process.

Since secure SDLC involves changing existing processes, implementing new tools and more importantly, driving a cultural change within a number of teams, a path to well-functioning secure SDLC is usually unique for each organization and can even differ amongst various business units.

5 Secure SDLC Best Practices

1. Educate Your Developers

Secure SDLC goes hand in hand with multiple related initiatives, including:

• Creating secure coding guidelines

• Providing developers with security awareness and secure coding training

• Setting clear expectations around how quickly issues discovered in production need to be addressed (also known as remediation SLAs).

Not all of these need to happen for an effective SSDLC implementation, but much like a jigsaw puzzle, you’ll need to put enough pieces together before you can see the big picture.

2. Have Clear Requirements

Whatever you create, it should be easy to understand. Development teams need clear requirements that are easy to act upon. This applies to all security advice, recommendations, and guidelines. Any vulnerabilities discovered in tests need to be easy to act on. It’s key that all people, processes, and tools involved bring solutions to the table instead of just pointing out problems

3. Maintain a Growth Mindset

Since SSDLC will change how multiple teams work and interact, it’s important for everyone to go into this experience with an open mind, and for the security team to have the mindset of empowering developers to secure their own applications

4. Tie Implementation to Other Initiatives

For well-established applications and teams, it may often be easier to implement SSDLC changes when it’s tied to another modernization effort, such as a cloud transformation, a DevOps initiative, or its more security-conscious variation, DevSecOps.

5. Tackle the Big Problems First

Focus on the most important issues and actionable fixes rather than addressing every vulnerability found. While it may be possible for newer or smaller applications to fix every security issue that exists, this won’t necessarily work in older and larger applications. A triage approach can also be helpful. This focuses on not only preventing security issues from making it into production, but also ensuring existing vulnerabilities are triaged and addressed over time.

For more best practice tips for securing your SDLC, check out our full list of SDLC best practices.

SSDLC and DevSecOps

It’s important to discuss the relationship between SSDLC and DevSecOps. They are sometimes used interchangeably, which can lead to confusion. While SSDLC and DevSecOps are closely linked, they are actually complementary practices. Both SSDLC and DevSecOps focus on empowering developers to have more ownership of their application, ensuring they are doing more than just writing and testing their code to meet functional specifications.

Secure SDLC is focused on how the application is designed and built; DevSecOps seeks to shift ownership of the production environment for each application away from traditional IT teams and into the hands of the developers. This lets developers focus on automating build, test, and release processes as much as possible.

DevOps and DevSecOps have started a revolution in redefining the role of software developers. This has of course been aided by other major changes, such as cloud transformations. But while empowering developers and accelerating security testing is key to success for most modern organizations, it would be a mistake to view application security as just an automation challenge. Instead, it’s important to drive cultural and process changes that help raise security awareness and considerations early in the development process. This must permeate all parts of the software development life cycle, regardless of whether one calls it SSDLC or DevSecOps.

Moving to a More Secure Future

Traditional practices of testing for vulnerabilities in production are no longer sufficient for securing your applications. As the software industry has evolved, the types of attacks have evolved as well. Deploying and maintaining a secure application requires securing every step of the application development process. This means asking questions about security behaviors at the requirement gathering stage, adjusting team culture and practices to account for a security-oriented mindset, implementing automated verification into your deploy process, and many other practices that together create a secure SDLC process.

SSDLC allows you to shift security risks left, addressing the origin of security issues at the requirements phase instead of having to backtrack from the maintenance phase. By focusing on security at every stage of development, you can rest assured your application will be far more secure as a result.