The Home of the Security Bloggers Network
Home » Cybersecurity »
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).
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.
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 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.
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 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:
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.
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:
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.
Add Security, Not Headaches, to the SDLC was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog – Medium authored by The ShiftLeft Team. Read the original post at: https://blog.shiftleft.io/add-security-not-headaches-to-the-sdlc-b6e36ef5d418?source=rss—-86a4f941c7da—4
The Home of the Security Bloggers Network