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 prioritised and managed proactively. To manage risk and remove friction from your organisation’s digital transformation initiatives, your application security programmes 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 programmes work best when development teams embrace tools and solutions that plug seamlessly into development toolchains and workflows.
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.
In general, SDLCs include the following phases:
- ✓ Planning and requirements
- ✓ Architecture and design
- ✓ Test planning
- ✓ Coding
- ✓ Testing and results
- ✓ Release and maintenance
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 as you code. Security assurance activities include architecture analysis during design, code review during coding and build, and penetration testing before release.
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 the functional requirements being gathered for the new release.
• Sample functional requirement: the 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: the page should retrieve the user’s name, email, phone, and address from the 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 is well-written from a 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 organisation 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 minimising the chances that anyone can ever commandeer these queries for nefarious purposes
• Validating user inputs before processing the data contained in them
• Sanitising 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 and requirements. This is also a great place to introduce automated security testing using a variety of 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 the developers wrote, but they 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's core security efforts are 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.
Benefits:
• Your software is more secure.
• All stakeholders are aware of security considerations.
• You detect design flaws early, before they’re coded into existence.
• You reduce your costs thanks to the early detection and resolution of defects.
• You reduce overall intrinsic business risks for your organisation.