Application security is an ongoing challenge throughout the entire software development life cycle (SDLC). Today, more and more development teams are shifting to Agile and DevOps SDLCs to rapidly build application to meet the rising demands from the business and consumers with little or no attention to security. In addition, open-source components are used to speed up product development and lower costs.
As a result of speeding up the build process, an application is most likely at the risk of having vulnerabilities in itself or deeply nestled inside its acquired open-source components. Also important is the issue of compliance with numerous open-source licenses that, if unresolved, can impose limitations or liabilities on developers.
Application security testing (AST) tools helps detect these vulnerabilities at different stages of the SDLC. Here, we briefly discuss each AST category, along with related features and capabilities.
Static AST (SAST)
SAST is a white-box approach that shares its roots with linting. Unlike linting that mainly looks for grammatical/syntax errors in a source code, SAST focuses deeper on identifying errors and vulnerabilities within an application’s source code.
Using methods such as taint analysis and code/data/call flow analysis, a SAST tool examines an application at function, file/class, and application levels, and the depth of its analysis directly affects the accuracy of the results. By adding SAST to the IDE, code can be scanned as early as possible. Moreover, SAST can be added as a gate to secure pull requests and attempts by developers to merge to a master branch of a repository.
Software Composition Analysis (SCA)
SCA involves analysis of open source, third party components, and software licenses. SCA tools analyze the application and produce a bill of materials (BOM) which is an inventory of all assets of the application including open source, licenses, versions, and patch status. These tools can check the BOM against the National Vulnerability Database, maintained by the U.S. government, and other sources to identify vulnerabilities. This allows teams to quickly identify and fix all detected security and compliance issues introduced by components used to build the application. This allows teams to quickly identify and fix all detected security and compliance issues introduced by components used to build the application.
Dynamic AST (DAST)
DAST examines an application from the outside in a black box approach. DAST tools can perform active or passive scanning of the application through the front-end or API, and search for vulnerabilities such as cross-site-scripting, file manipulation, and injection, to name a few. DAST is considered a post-development testing method and is implemented in late stages of SDLC. DAST tools examine the running application and investigate HTTP query strings, headers, fragments, verbs, etc. as opposed to SAST tools that examine the source code.
Interactive AST (IAST)
IAST is widely viewed as an instrumentation approach to AST that incorporates agents and sensors in a running application. Using these instruments, IAST tool performs a real-time, continuous search for vulnerabilities by examining interactions of the application with manual or automated tests, or a combination of both.
Generally, IAST is a combination of SAST and DAST that examines a running application from the inside. Having access to a wider range of information produced by and/or contained within an application, IAST works more broadly and produces more accurate results than SAST or DAST alone. Some IAST tools also incorporate SCA to expand the tool’s analysis capabilities to open-source components and frameworks.
Runtime Application Self-protection (RASP)
Common security schemes such as AST and network perimeter controls usually lack adequate knowledge of real time data and event flows. Such information gap can lead to vulnerabilities going unnoticed during review process. It can also render those schemes unable to block threats unforeseen during development. The intent of RASP is to close this gap and protect the application in real-time.
RASP agents, like IAST tools, use runtime instrumentation aimed at protecting against attacks. They monitor the application’s inputs, block harmful data, and protect an application from tampering or unauthorized changes. A RASP agent can be used either as a monitor to detect and report a harmful entry, or as a protection tool to block such entry automatically.
Following is a summary of pros and cons of each category of AST, as well as where it is applicable in the Agile or DevOps SDLC.
| AST Type | Pros | Cons | SDLC Phase | |
| DevOps | Agile | |||
| SAST | – Does not require a running application. – 100% coverage of the source code. – Can be extended to quality and architecture – Promotes secure coding habits in developers | – Can produce excessive false positives. – Not easily scalable – Does not test libraries or frameworks – Not a real-time test method | Code, Build (CI) | Construction (CI) |
| SCA | – Comprehensive analysis of all software assets | – Not a real-time process – Success rate depends on how up to date the NVD or other sources are in terms of latest vulnerabilities. – Does not analyze source code | Build (CI) | Construction (CI) |
| DAST | – Identifies vulnerabilities in the outer layer of application that can allow entry of malicious attacks. – Language-independent – Much fewer false positives than SAST | – Must run in a test environment to ensure the original application and its data are protected from mock attacks. – Not easily scalable – Difficult to implement – A slow test -may take several days – Not a real-time process. Delayed results can lead to serious security issues. | Test, Release (CD) | Release (CD) |
| IAST | – Tests the entire application including libraries and frameworks – Self-learning, inside view – Much fewer false positives than SAST or DAST – Real time analysis | – Slows the application performance – Limited/specific language scope – Depending on the vendor, an IAST tool may become an extended version of SAST or DAST | Test, Release (CD) | Release (CD) |
| RASP | – Real time protection – Less reliance on peripheral devices like firewalls etc. – Inside view and context | – Slows the application performance – Limited/specific language scope | Deploy, Operate (CD) | Production (CD) |
An End-to-End DevSecOps Platform
Development teams need to use many tools such as SAST, SCA, DAST and more to scan their applications for security issues during development and operation. Each tool produces its own report, often with many false positives. Teams also conduct manual activities such as threat modeling to identify security issues.
These present challenges such as additional effort and difficulty with managing multiple tools, and aggregating and correlating results from automated and manual sources to get a better view of actual threats to the application. In addition, there is a missed opportunity to better identify false positives, get more value from the investment in security, and reduce business risk.
The Eureka DevSecOps Platform allows you to centrally orchestrate your scanners, correlate the results, and manage your application security threats and risks* to get the most value from your tools and better identify real security issues.
With Eureka, you can:
- Bring Your Own Scanner (BYOS) (commercial or open source)
- Centrally configure and orchestrate your scanners
- Easily integrate your scanners with CI/CD pipelines
- Run the scanning agents inside your own environment
- Keep the scan data in your own environment for maximum privacy
- Correlate security issues to reduce false positives
- Filter and push issues to your issue tracking system
- Join security issues to create threat scenarios and assign risk
- Get better view of risks based on data from manual and automated processes
