A crucial element in most of Quandary Peak Research’s technical due diligence engagements involves identifying cybersecurity risks related to a given target organization. The importance of attending to cybersecurity risks is paramount. To provide some insight we share the following 2022 findings:
- An estimated 53.35 million US citizens have been affected by cyber attacks in the first half of 2022. Between July 2020 and June 2021, the US was the most targeted country for cyber attacks, accounting for 46 percent of attacks globally.[1]
- Cyberattacks in the first half of 2022 rose by 42 percent compared to 2021.[2]
- A new global study of 1,000 CIOs finds that 82 percent say their organizations are vulnerable to cyberattacks targeting software supply chains.[3]
- Cybersecurity statistics show that the total damage caused by cybercriminals is expected to reach $6 trillion in 2022.[4]
Moreover, 60 percent of small companies that suffer a cyber attack are out of business within six months.[5] This indicates that cybersecurity is often not prioritized in startup companies.
Quandary Peak undertakes an extensive assessment of the target’s processes, people, and applications. One element of this risk includes assessing the target’s applications for vulnerabilities. These include vulnerabilities within an application’s use of open-source libraries, often identified with the help of Software Composition Analysis (SCA) scanning tools, as well as vulnerabilities within the target’s application proprietary code which are found by way of using Static Application Security Testing (SAST) tools. In this article, we cover the later type of risk and share my thoughts on what SAST tools cover, how software development organizations use SAST tools within their SDLC process, how Quandary Peak uses SAST tools as part of its tech due diligence Lighthouse framework, and how to select a SAST tool for your organization.
SAST tools assess and discover application vulnerabilities, not only in web application code, but in any type of code from the lowest OSI layers up to the application layer. These tools discover security vulnerabilities by scanning the source code directly. They discover issues such as Buffer Overflows, SQL-Injection, Cross Site Scripting, Cross Site Request Forgery, and many other vulnerability classes. They do not discover known vulnerabilities in open-source libraries (as mentioned above, this is covered by SCA tools), nor do they discover software misconfigurations (covered by Dynamic Application Security Testing tools). The tools cover the most common languages such as C/C++, C#, Java, Python, JavaScript, and many more as well as many prevalent development frameworks. There are two methods that organizations can use to launch source code scans. Source code is either loaded into the vendor’s cloud and scans are launched directly from there, or the vendor’s SAST tool is loaded onto the organization’s premise and the source code is scanned directly on that local premise.[6] SAST tools also integrate with many repositories and integrated development environments (IDE).
SAST Tools Save Money
Software vulnerabilities are not to be taken lightly. More and more organizations, including security vendors, are experiencing compromises and data breaches. Earlier this year, security vendor Okta experienced a data breach. Okta develops and sells single sign-on technology and as a result of the compromise, 366 of its customers were directly impacted, such that hackers were able to access their internal networks. Software vulnerabilities are not declining. Per a report from Skybox Security, there were 20,175 new vulnerabilities published in 2021, up from 18,341 in 2020. Software vulnerabilities give rise to compromises. According to a study conducted by the Ponemon Institute, the total cost of a single data breach in 2022 was 4.35 million USD, of which 13 percent is attributable to vulnerabilities within software code. SAST tools help discover these vulnerabilities early (before the testing by developers) and help avoid compromises and data breaches. Ultimately, the goal of SAST tools is to gauge and help manage security risk related to vulnerabilities within the organization’s proprietary written source code, as well as to help train developers on secure coding.
An organization that delivers a product and/or service and which designs and implements their own proprietary application code, should include within their SDLC process a way to identify security vulnerabilities within their code, as well as policies and procedures related to remediation of these discovered vulnerabilities. To help identify application code vulnerabilities, the organization should use a SAST tool. In general, SAST tools provide a web interface and integrate into an organization’s DevOps environment such that a user may launch a scan on a set of code quite easily. In addition, many SAST tools integrate with IDEs allowing a developer to launch a scan right from the IDE while writing their code. A typical process flow would include scans at different stages of the SDLC process. For example, developers would launch scans just after checking in their code to the repository. When the code has been cleared and is ready for testing, the Test team would also run assessment scans on the completed work. Finally, when a release has been built but not yet deployed, an additional SAST scan may be run and evaluated. Depending on the severity of the issues found by the scans and the organization’s policies, tickets may be created, resulting in additional work required to remediate the findings. Once security is introduced into the DevOps SDLC process, it then becomes what is called DevSecOps. SAST tools play a big part in the DevSecOps process.
When Quandary Peak Research is assessing a target as part of a tech due diligence engagement, we interview the organization’s team to learn as to whether their process includes the detection and remediation of application security vulnerabilities and, if so, how they are used within the target’s SDLC process. Regardless of what the organization does and does not do as it relates to SAST, QPR runs a SAST assessment using our own licensed SAST tool on the target’s application source code in order to assess it for security vulnerabilities. Although this assessment is a point-in-time assessment, there is great value in obtaining this knowledge from an independent party. For example, for many M&A engagements, the acquiring company often wants an independent assessment of the cybersecurity risks related to the application. QPR performs the assessment by launching a scan on the application source code and reviews the findings within the SAST interface as well as within generated reports. We then perform an analysis to understand whether specific findings are false positives and if so, we remove them from the findings. Finally, we summarize the findings as part of our final tech due diligence report, and we offer detailed recommendations as well as remediation guidance resources. The SAST analysis and findings are detailed in a section regarding cybersecurity risk related to the application source code within the Tech Due Diligence final report.
The ultimate outcome is Quandary Peak’s opinion on the level of cybersecurity risk present within the target’s proprietary application source code. The acquiring company, who is the direct QPR client, finds this information useful, and it highly influences the direction and outcome of the M&A transaction. Often, the results are shared with the target organization so that they may in turn follow any remediation recommendations documented within the report related to the findings.
An organization that is planning to start using a SAST tool as part of their SDLC would first need to evaluate a set of vendor tools to ensure that the tool fits their requirements. Several good resources can help with this research. For example, large think tanks such as Gartner (Magic Quadrant for Application Security Testing) and Forrester (The Forrester Wave for Static Application Security Testing) perform yearly evaluations on the market as well as on selected SAST vendors. These reports outline the various features of SAST tools and evaluate vendors on many different evaluation vectors. Quandary Peak has recently evaluated a set of SAST vendors to select the best one for our requirements. Although each organization would choose which vendors they want to include as part of their evaluation, QPR evaluated the following vendors:
To select the right vendor for us we consulted the above two reports to understand each vendor’s features, strengths, and weaknesses. We then followed an evaluation process where we evaluated the given vendors against the following criteria:
- Licensing terms – do they allow Quandary Peak to scan different company’s source code
- Languages supported
- Accuracy
- Breadth of coverage
- Dashboard view
- Quality and extent of reports
- Remediation guidance
- Ease of use
- Ease of installation
- Integration with IDEs
- Support
- Training
- Gartner peer reviews
Because Quandary Peak would need to use a SAST tool on many different targets’ source codes, we needed special licensing terms. Most vendors accommodated this, but not all. Another significant criterion to Quandary Peak was a tool that would allow us to scan the target’s source code either on the target site or at QPR’s site. We did not entertain cloud-based offerings because we did not want to require permission from the target to upload their source code to yet another third-party cloud. This eliminated some solid vendors. We placed importance on the accuracy of findings in order to spend as little time as possible determining and weeding out false positive results. False positive results are those where the tool declares a vulnerability, where in fact, it is not actually a vulnerability. Further, we also want to make sure we have limited false negatives where the tool does not find a vulnerability which is present. This eliminated some vendors from our original vendor set. Note that there is information in the Forrester Wave report which gives insight into the accuracy of the results.
We also looked at languages supported. Some vendors seem to focus on a set of languages and are very good at detecting issues for those languages. Yet they lack coverage for other languages. Quandary Peak needed to select a tool that covers a wide variety of languages since we are constantly assessing new targets during our tech due diligence engagements. We looked at the remainder of the above criteria, including price, and ultimately narrowed the vendors down to a short list of four. We then proceeded to try these four vendors.
In order to perform these trials we used the SAST tools to scan three different open-source projects, one of which was WebGoat. This open-source project teaches security professionals how to hack into web applications and how to protect from such attacks by writing more secure code. WebGoat has a set of lessons that deal with different web application security flaws such as SQL-Injection, Cross-Site Scripting, and many others. The code within these lessons is intentionally seeded with vulnerabilities. This allowed us to know upfront which vulnerabilities were present in the code and allowed us to benchmark the various tools we were trialing. Additionally, this let us know when a tool experienced a false negative and when a tool experienced a false positive (detecting an issue that really was not present).
After trialing the short list of vendors we huddled as a team and ultimately selected a winner. Once again, you may evaluate a different vendor list and use a different set of criteria, still, the process outlined above can be used as a guide to proceed with your SAST selection evaluation.
Although SAST tools do not cover all application security risks they do assess vulnerabilities within an organization’s proprietary developed code. They identify vulnerabilities at all layers of the OSI model – not just the application layer. Organizations that develop and produce application code should employ SAST tools to manage their security risk. Quandary Peak Research uses SAST tools to assess targets during many of our tech due diligence engagements to provide an independent analysis of the target’s application security risk and to help provide recommendations on the identified risk.
In this article we provided some thoughts and resources on how to select a good SAST tool for your organization’s requirements. Lastly, we covered how Quandary Peak picks a SAST tool that satisfies our given requirements and criteria.
Quandary Peak Research has experience with hundreds of technology transactions and software litigation matters. Our experts advise world class organizations and top VC firms in intellectual property matters and technical evaluations of target companies in technology transactions. Contact us for a confidential consultation.
