Recommended Application Security Testing (AST) Techniques
There are some very interesting takeaways from Gartner’s recent report “How to Deploy and Perform Application Security Testing” (published March 20, 2020, Gartner subscription required). Primarily, “application security testing (AST) is a critical practice within the software development life cycle (SDLC) and covers multiple techniques, from early development stages through to, and including, production.” Clearly, static analysis tools or static application security testing tools (SAST) play an important part in developing secure software. This post looks at some of the findings from the report and how we believe advanced SAST tools like GrammaTech CodeSonar can help with the challenges and implement the recommendations.
Challenges
Gartner reports that:
“Organizations are challenged with vetting and prioritizing high volumes of vulnerabilities, as well as providing meaningful technical guidance to application teams to aid in remediation.“
This is not unusual as we see this same challenge with new customers adopting SAST for the first time. However, it is important that organizations stick with it and learn to overcome these challenges and adopt these tools into their early stages of development. Further, Gartner noted that:
“Running application security testing (AST) tools manually or only in the final stages of the software development life cycle (SDLC) is expensive and disruptive. Software build pipelines have accelerated with the adoption of continuous integration/continuous delivery (CI/CD), necessitating integration and/or automation of AST.”
Again, this is also a point we make here in our blog and with new customers. It’s very difficult to “add” security to a product that is nearly complete.
Recommendations
The Gartner report provides recommendations that we believe align with ours. It is important to integrate AST in all stages of development both early during design and development but it is also critical in deployment, production and post-release. Firstly, Gartner recommends:
“Integrate AST in development, prerelease and production stages. Ensure you test all critical and/or exposed applications early and continually as code changes or AST tools improve.”
A recommendation that we make is the fact that SAST is only part of a comprehensive set of tools. We think static analysis is important but it in the context of a quality and security improvement program that uses a combination of best practices. Secondly, Gartner recommends:
“Utilize a combination of SCA, static, dynamic and interactive application security testing for greatest coverage. Prefer a SaaS suite to reduce integration complexity and scale testing capacity to support software release schedules.“
It is also critical that AST tools integrated work seamlessly with existing tools. To increase adoption and streamline new tool usage, AST (included SAST) must be as minimally disruptive as possible. Although the software as a service (SaaS) approach is efficient and cost effective, it’s less desirable for many device manufacturers due to security, safety and intellectual property reasons. On-premise SAST is still preferable for many of our customers.
Gartner goes on to recommend:
“Select AST tooling that integrates with your nonsecurity tooling such as integrated development environments (IDEs), version control systems and test automation. This should come in the form of native integration, plugins or web APIs that support customization”
CodeSonar as Part of a Comprehensive AST Toolset
SAST tools like CodeSonar provide critical support in the coding and integration phases of development and are well suited for easier and early adoption and use throughout the software lifecycle. For example:
Vulnerability priority with filtering: CodeSonar provides a warning score to prioritize its findings that is a combination of several factors including the confidence that the tool has in the correctness of the warning, the severity of the warning and the complexity of the warning path, with more-complex warning paths generally receiving lower score values than less-complex warnings paths.
Build by build assessment history: Any assessments performed on vulnerabilities are persistent from analysis run to analysis run. Once a vulnerability is marked as real defect, there is no need to redo the assessments in the future and this work is not lost (unlike compiler-like warnings that change from build-to-build.) There are multiple different attributes stored with a warning such as the State of a warning indicates its place in the assessment process. The next is assignment to a developer to be fixed and marked as “assigned.” It’s also possible to defer vulnerabilities for later. The engineer typically uses the priority of a warning to indicate the urgency of a warning, or to suppress it in most searches.
Flexible approach to vulnerability backlog: The number of warnings can overwhelm a team and be a deterrent to adoption early in the project when it benefits the most. There are three key approaches to facilitate adoption: Filter and Focus: Filtering the viewed data from CodeSonar’s web interface, focussing on what is most important for the project and assigning developers to fix critical issues in priority order. Mark and Defer: Lower the priority, or change the state to “later”, for example, on all or a subset of the warnings based on some set of conditions that are less crucial to the project. “Stop the Bleeding:” Using the above techniques, to temporarily defer existing warnings with the emphasis on fixing new defects introduced as code changes or new code is added.
IDE integration: The key to integrating static analysis into any IDE is to follow the conventions for error and warning reporting of the platform. In this case, CodeSonar reports static analysis warnings in the same manner as the compiler does within the IDE (e.g. Eclipse or Visual Studio) but marked with a small GrammaTech logo in order to help differentiate the type of warning issued. Among other key features is the ability to evaluate and set the status of the warnings and access other warning info and as well as link to the warning in CodeSonar itself for the complete details.
Workflow integration: Continuous integration and deployment processes rely on automation to realize the benefits thereof. Without efficient progress through the cycle, the continuous nature of the processes amplifies inefficiencies. For example, introducing bugs that are inevitable whenever code changes and new features are implemented, the detection, diagnosis and remediation of these bugs can slow the entire process down. Introducing static analysis in to the process ensures better quality code introduced into the continuous process and detects new bugs introduced before unit testing (and often after!) is performed.
The added benefit of Binary Code Analysis: GrammaTech CodeConar has the unique ability to perform advanced static analysis on binary code. This provides added benefits to the continuous integration process, especially when incorporating third party binaries or legacy libraries. If source code is not readily available, this does not preclude the ability to detect bugs and security vulnerabilities. In addition, security teams use binary analysis to perform “black box” analysis of product deliverables.
Detecting complex security vulnerabilities that other testing techniques can miss: Analysis of the data flows from sources (i.e. interfaces) to syncs (where data gets used in a program) is critical in detecting potential vulnerabilities from tainted data. Any input, whether from a user interface or network connection, if used unchecked, is a potential security vulnerability. Many attacks are mounted by feeding specially-crafted data into inputs, designed to subvert the behavior of the target system. Unless data is verified to be acceptable both in length and content, it can be used to trigger error conditions or worse. Code injection and data leakage are possible outcomes of these attacks, which can have serious consequences.
Secure coding standard enforcement: Static analysis tools analyze source syntax and can be used to enforce coding standards. Various code security guidelines are available such as SEI CERT C and Microsoft’s Secure Coding Guidelines. Coding standards are good practice because they prevent risky code from becoming future vulnerabilities. As mentioned above, integrating these checks into the build and configuration management system improves the quality and security of code in the product.
Summary
In our opinion, the Gartner report makes some interesting and timely recommendations. Many of the challenges we have observed in our experience matches those found in the marketplace, particularly with software teams becoming overwhelmed when first adopting AST tools, including static analysis.
The adoption of static analysis may seem daunting at first. However, CodeSonar provides capabilities that help ease the adoption and get teams using the tools as part of their everyday workflow. Integrating static analysis into an existing process should not be a large hurdle for software development teams.
References:
Gartner, “How to Deploy and Perform Application Security Testing,” Frank Catucci, Michael Isbitski, 20 March 2020.
*** This is a Security Bloggers Network syndicated blog from Blog authored by Vince Arneja. Read the original post at: https://blogs.grammatech.com/recommended-application-security-testing-ast-techniques
