How to integrate security into the SDLC successfully
The world has an insecure software problem, which is why 84% of cyber attacks focus on the application layer. Two major factors have contributed to the writing of insecure code — cumbersome security analysis tools and a strong drive to reach the market quickly. For things to improve, developers need better code analysis tools make implementing security into the software development lifecycle (SDLC) much easier. Fortunately, adding AppSec to the SDLC has become simpler through innovations in static application security testing (SAST) and intelligent software composition analysis (SCA).
Understanding the SDLC
Non-developers may not understand why writing secure code is difficult for companies. A cursory overview of the SDLC should clarify why security is often neglected in favor of other concerns. The ways an SDLC is structured can vary between organizations, but the basic components are planning/requirements, design, implementation, testing/verification, and maintenance. These steps can be visually represented in the Continuous Integration (CI) framework, seen in Figure 1.
An SDLC generally divides a project into a number of sections (phases, sprints), each which must be completed before the next step begins. Breaking the project into smaller, more manageable tasks helps software companies track the progress of their project and ensure benchmarks are being met. There are many SDLC frameworks including Agile, RAD, Waterfall, and Spiral Development, but they all aim to achieve this same goal. The CI framework is drawn to emphasize delivering incremental changes to the end user repeatedly and efficiently.
Likewise, there are processes within the SDLC that aim to catch errors but may overlook insecure code. For example, developers using the continuous integration/continuous delivery (CI/CD) pipeline approach regularly commit their code to a shared location. Each new upload triggers an audit by the CI server which will notify devs if their recent changes are incompatible with existing code. By immediately informing developers that their new code breaks functionality, mistakes can be quickly rectified.
If committed changes pass the CI audit they move to the CD pipeline which delivers the updated code to QA analysts, the production stack, or elsewhere. The CI/CD loop is excellent for ensuring code changes that break an app are identified quickly and remediated. However, the process is not engineered to discover code vulnerabilities. In fact, the process may exacerbate security problems by greenlighting code based solely upon its functionality.
How Does the SDLC Deter Secure Coding?
The SDLC is not explicitly designed to be hostile towards the writing of secure code. However, the priorities that drive the SDLC are often directly opposed to those that foster the writing of robust and secure applications. For example, an SDLC may set a series of strict deadlines in order to release a working application by a certain date. A process that prioritizes releasing a secure application, however, will only be completed when no further critical or moderate vulnerabilities can be found.
The Pressure of Time
The primary concern for many software companies and developers is creating functional code. A second, but almost equal motivator, is to reach the market quickly. Accordingly, each phase of the SDLC focuses on hitting the benchmarks required to move to the next step, not on uncovering new problems. Ensuring that code is secure not only takes time, but it introduces additional delays with each newly discovered vulnerability. In fact, static code testing is traditionally a process that can take several days to complete. This considerable time requirement effectively discourages developers from testing code more frequently.
Another roadblock to code security is developer’s lack of expertise. In some cases, the job of making sure code is secure falls to a QA analyst or security engineer. This division of labor may result in core developers being apathetic towards secure coding because “it’s not their job”. Such attitudes, while accurate, represent a missed opportunity for organizations to train their devs to write more robust code in the future.
Often a project may move forward with the idea that QA testing occurs at the end, or that future updates can fix issues after release. However, this sentiment ignores the fact that the faster a vulnerability is identified and fixed, the less it will ultimately cost.
These growing costs present a problem for managers who set benchmarks in the SDLC — every time AppSec is delayed it becomes more expensive to fix. Yet every time AppSec testing is performed deadlines must be moved further out.
Limitations of Traditional Testing Tools
Traditionally there have been two ways to identify vulnerabilities in an application. The first, called static application security testing (SAST), involves performing an automated search for vulnerabilities on the source code. While this type of testing is useful, traditional SAST suffers from several limitations including:
- The analysis tools must accommodate the programming language of the original source code
- The larger the code base the longer the search times
- Tools search for vulnerabilities are limited to specific errors like insecure library functions, buffer overflows, integer overflows, or insufficient validation of input data
- No ability to check for vulnerabilities in third party or open-source code
- No ability to detect run-time vulnerabilities
The second method of testing for vulnerabilities is called dynamic application security testing (DAST). As the name implies, DAST looks for vulnerabilities in running code. However, DAST faces its own challenges including:
- Each included execution path exponentially increases testing time
- It does not access the source code, and is therefore unable to highlight where code is broken
- It may suffer from a high rate of false negatives
- It takes place after the development phase, making costs to fix vulnerabilities considerably higher
While both methods are complementary, the vulnerability hunting tools traditionally available to application developers offer limited coverage and take considerable time to execute. This makes them a difficult fit for the modern SDLC, where each phase is defined by specific goals that must be quickly achieved. For AppSec to thrive in the SDLC it must find ways to align itself with the demands and priorities of the process.
Next Generation SAST (NG-SAST) Aligns AppSec with the SDLC
The biggest hurdle AppSec faces when trying to integrate with the SDLC is time. It takes time to run testing, it takes time to train developers to avoid mistakes, and it takes time to identify and fix vulnerabilities. Given the clear nature of the problem, the solution is simple — make testing, dev training, and fixing vulnerable code faster.
This is precisely the approach ShiftLeft has taken with its introduction of ShiftLeft CORE, an application security platform for CI/CD environments. ShiftLeft CORE has a number of advantages that make it suitable for the modern SDLC and expand upon the capabilities of traditional SAST. For example, NG-SAST uses the code property graph (CPG), a data structure that combines several features of source code into a queryable database. This innovation not only reduces test times, but it more fully analyzes the ﬂow of information throughout an application. It tests from the source to the sink, and all the security transforms and sanitization steps between. This helps developers understand the root cause of each vulnerability.
ShiftLeft also offers an intelligent software composition analysis (SCA) tool, capable of identifying vulnerabilities in open-source libraries. This expands the scope of testable code, thereby increasing the number of problems that can be discovered and fixed earlier in the SDLC.
Companies using NG-SAST and Intelligent SCA for testing report:
- Code scans that are measured in minutes, not days
- 91.4% of new vulnerabilities repaired quickly (within one or two sprints using the AGILE SDLC)
- A 92% reduction in OSS vulnerability tickets
- Security testing happening with greater frequency, with many apps being scanned weekly or daily
ShiftLeft CORE makes application testing faster, more accurate, and more comprehensive, to align itself with the goals of the SDLC. Making security testing faster begins a chain-reaction of other events that also benefit developers. Faster testing leads to more frequent testing, and allows devs to catch problems earlier in the SDLC. By catching and fixing numerous problems in a short span of time, developers improve their coding skills and familiarize themselves with common errors.
Using NG-SAST and Intelligent SCA in ShiftLeft CORE helps companies implement a SDLC that catches and fixes more vulnerabilities, for less cost, than their competitors. If your organization is interested in adding strong AppSec to your SDLC while simultaneously training devs to write secure code, contact ShiftLeft today.