In the past, teams incorporated security testing far after the development stage of the Software Development Lifecycle (SDLC). Security testing would influence whether the application would to proceed to production, or get passed back to the developers for remediation.
This process caused delays while teams worked on remediation or, worse yet, it increased security risks when teams released software without applying the necessary security measures. As software development became more agile, teams began to create more collaborative workflows that shifted quality and security to the left. In a fully automated continuous delivery pipeline, shifting left is no longer a luxury – it is a must.
Shifting security left means that security moves closer to the beginning of the linear development timeline. It enables teams to apply security measures across the entire SDLC. The goal is to build security into software from the beginning, allowing for potential security problems to be detected and corrected early in the development cycle. Early detection facilitates faster, easier, and more affordable security remediation.
Shifting left requires automated tools. Three of the most common tools categories used for security automation are SAST, DAST, and SCA. How can an organization use each of these tools to ease their “shift left” approach?
Shifting Left with SAST
Static Application Security Testing (SAST) is a technique that involves using tools to analyze source code at rest to find security vulnerabilities and weaknesses. SAST tools analyze applications from the inside, examining source code, byte code, and binaries. Teams can use SAST to find flaws in their source code early in the SDLC and fix detected issues before deploying the final application into production.
Teams can apply SAST scans early in the SDLC because these tools analyze inactive applications. This process provides developers with feedback while they code the application. Using SAST scans consistently on a monthly or daily basis can help catch issues as they arise.
How to Implement SAST
Correctly implementing a SAST tool is critical to ensure its effectiveness.
Configuring and integrating SAST into the SDLC
This step involves determining how and when the team should scan and analyze the code. Some options for integration into your process include:
- Analyzing code when it is compiled.
- Scanning code when it is merged into the code base.
- Incorporating SAST into the CI/CD pipeline.
Running SAST within the Integrated Development Environments (IDE) enables developers to identify and remediate vulnerabilities while they code.
Customizing SAST to suit the project’s requirements
Each project has unique needs. For example, one project may require a special emphasis on reducing false positives, creating dashboards to analyze scans, or building custom reports.
Another might require revising old rules or creating new rules to identify new security issues.
Some best practices for this include:
- Prioritization – prioritize results according to the metrics relevant to the project. Teams might want to consider compliance issues, Common Weakness Enumerations (CWEs), the severity of the threat, risk level, the vulnerability’s status, and responsibilities.
- Analysis – consistently track progress, analyze results, and evaluate urgency. It involves examining scan results to remove false positives, setting up automated alerts to the responsible personnel, and assigning issues to be addressed.
- Reporting and governance – teams can use built-in reporting tools, like the OWASP Top 10, or push the relevant data to existing tools. The goal is to ensure that the team is using all scanning tools properly.
Shifting Left with DAST
Dynamic Application Security Testing (DAST) is a technique that enables teams to shift security left by scanning a running application during and after development to identify flaws. A DAST tool examines a running application, trying to attack it like a threat actor. DAST tools do not have inside access to the source code. Rather, they analyze an application in runtime to identify security weaknesses and vulnerabilities.
This testing technique provides insights into the application’s behavior and identifies likely attack entry points so that teams can eliminate these threats. Teams implement DAST testing once an application moves past early phases and enters into runtime or production.
How DAST works
A DAST tool scans applications continuously during and after development, usually passively examining the app before scanning it. The tool tries to find all exposed inputs on pages within the application, and then tests each one. The output of this test includes a list of the vulnerabilities external actors are likely to exploit.
DAST tools usually test only a web-enabled application’s exposed HTML and HTTP interfaces. However, some tools can test non-web protocols and data malformation, such as Remote Procedure Calls (RPC) and Session Initiation Protocols (SIP). A DAST tool can use a fault injection technique, like malware injection, to detect threats such as Cross-Site Scripting (XSS) attacks and SQL injections (SQLi).
How to Implement DAST
Improperly implemented DAST solutions can be complex and costly. Here are notable best practices to help cost-effectively implement DAST:
- Implement DAST in early SDLC phases – early vulnerability detection can reduce the overall costs of development. It enables teams to address issues before the application is fully developed, when it is more affordable to make changes.
- Combine DAST with SAST – each technique covers different vulnerabilities. SAST provides insights into the inner workings of the source code, and DAST provides insights into possible entry points that external attackers might exploit. Using both enables teams to achieve comprehensive coverage.
- Enforce open communication – teams need to remediate the vulnerabilities identified by the SAST and DAST tools. It requires setting up an efficient process to pass this information to developers and relevant personnel. Common options include configuring notifications for a DAST solution, and using bug-tracking tools.
Shifting Left with SCA
Software Composition Analysis (SCA) tools automatically identify open source components in a codebase to help evaluate license compliance, code quality, and security. SCA tools help teams shift security left by eliminating the need to manually track open source code. Instead, this task is performed automatically, speeding up this process and achieving more accurate results.
Manually tracking open source code is inefficient in a modern SDLC that utilizes a massive amount of open source. The increasing prevalence of cloud-native and complex applications further complicates this task, making SCA tools a necessity rather than a suggestion.
The following aspects must be considered when implementing SCA:
- Implement proactive and continuous monitoring – automated scans provide teams with actionable alerts, informing them on the location of a vulnerability and how to fix it. However, teams must assess these suggestions and decide on a fix.
- Integrate SCA scans into the CI/CD pipeline – this integration enables teams to include vulnerability identification and remediation as an integral component of the development and build process.
- Provide a Software Bill of Materials (SBoM) report – SCA tools can generate an SBoM that teams can provide to customers that purchase the software. Providing the SBoM with the product demonstrates that the team understands the value of tracking all components inside the application.
Conclusion
The ability to shift left can be realized with three types of security tools:
- SAST – implement a SAST tool so it analyzes code whenever it is compiled by developers or merged into a codebase to capture security issues early in the development process.
- DAST – run DAST scans as soon as an application is deployed to testing or staging environments, and ensure that any discovered vulnerabilities are immediately communicated to and addressed by development teams.
- SCA – ensure that SCA scans software artifacts as an integral part of the build process and generates an SBoM for each artifact to identify third-party components that represent a risk.
Using these tools and techniques will take your organization one step further to a full DevSecOps implementation.
About the Author: Gilad David Maayan is a technology writer who has worked with over 150 technology companies including SAP, Imperva, Samsung NEXT, NetApp, and Ixia, producing technical and thought leadership content that elucidates technical solutions for developers and IT leadership. Today, he heads Agile SEO, the leading marketing agency in the technology industry.
LinkedIn: Gilad David Maayan
Twitter: @gilad_maayan
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
