Organizations apply several methodologies to identifying potentially exploitable vulnerabilities within their software. For example, static code analysis is a form of white-box testing that can help identify security issues in source code. On the other hand, dynamic code analysis is a form of black-box vulnerability scanning that allows software teams to scan running applications and identify vulnerabilities.
When properly implemented, dynamic code analysis can reduce mean time to identification (MTTI) for production incidents, improve visibility to application issues, and increase a project’s overall security posture. Here, we’ll take a closer look at dynamic code analysis.
Dynamic code analysis – also called Dynamic Application Security Testing (DAST) – is designed to test a running application for potentially exploitable vulnerabilities. DAST tools to identify both compile time and runtime vulnerabilities, such as configuration errors that only appear within a realistic execution environment.
A DAST tool uses a dictionary of known vulnerabilities and malicious inputs to “fuzz” an application. Examples of these potentially malicious inputs include:
As the application runs, it is bombarded by these potentially malicious inputs, and the DAST tool analyzes the responses from the application. If the application has a negative response to an input (such as crashing, returning an invalid response, etc.), then the DAST tool records the identified vulnerability.
Since DAST tools are executed on a running application they can detect a wide range of potential vulnerabilities. This includes vulnerabilities that are difficult or impossible to detect in source code, such as memory allocation issues.
The Software Development Lifecycle (SDLC) maps out the stages of the software development process. This includes everything from the initial planning and requirements identification for an application to long-term maintenance and its eventual end of life.
DAST usually comes into play in the testing phase of the SDLC. This is because DAST requires the ability to run the application and test it using simulated malicious input. As a result, once the application’s code is able to build and deploy to a test or staging environment, you can use DAST. With continuous Integration/ continuous delivery (CI/CD) workflows, that can mean that DAST scans run multiple times a day as iterative builds occur.
In many enterprise software security programs, DAST occurs after penetration tests that do not require internal security expertise. For example, after a pen test to meet PCI DSS (Payment Card Industry Data Security Standard) requirements, a security team may use a DAST tool to run automated security scans.
Static and dynamic code analysis are two of the most common forms of application security testing. They take different approaches to identifying vulnerabilities and are often complementary.
Unlike dynamic code analysis, static code analysis – also called Static Application Security Testing (SAST) – does not require access to a complete executable. Instead, it takes a white-box approach and inspects the source code of the application for vulnerabilities. By building a model of the execution flow of the application and applying rules to this model, SAST can detect injection, buffer overflows, and similar vulnerabilities.
Since DAST and SAST apply different testing methods and are applied to different types of files (compiled executables vs. source code), they detect different types of vulnerabilities and are applied at different stages within the development process. SAST can be applied earlier in the SDLC (during the development phase) than DAST because it does not require the application to be completed to identify vulnerabilities.
Dynamic code analysis is applied once an application is largely complete and able to be executed. It uses malicious inputs to simulate realistic attacks against the application and observe its responses.
One of the main advantages of DAST testing is that it can simulate an application’s behavior in a realistic deployment environment. This allows the tester to identify configuration issues and other vulnerabilities that may be only visible when the code is active. Additionally, the use of simulated real-world attacks makes it possible to see the impact of a potential exploit on the state of the application. The DAST tool can also detect vulnerabilities within third-party dependencies and libraries, which affect the application’s security but may be missed by SAST and similar source code-focused tools.
Check Point CloudGuard offers vulnerability scanning for cloud-based serverless and containerized applications. This includes support for both DAST and SAST vulnerability scanning to help with identification and remediation of vulnerabilities during the development process. To see the capabilities of CloudGuard Solutions for Serverless Applications in action, schedule a demo. You’re also welcome to request a free trial to see how it can integrate into your organization’s development workflow.
反映意見