Static analysis + penetration testing = More than the sum of their parts

In the world of tech merger and acquisition (M&A) transactions, timing is everything. It’s important for prospective buyers and investors to understand as much of the target’s software assets’ security, quality, and legal posture as possible in a brief amount of time. This drives the need to conduct multiple assessments on a target’s code simultaneously. Penetration testing and static application security testing are two types of analyses that deliver time to value extremely well, and when performed together, offer a coordinated, comprehensive view with a better quality of results than either provide individually. In this case, 1+1=3.

Areas of coverage

Penetration testing (PT) analyzes application security from the outside in. It involves an authorized tester using automated and manual techniques to attack an application as a hacker would. A skilled tester will use knowledge of the application and software in general to attempt to bypass security controls, and abuse business logic and user authorization to demonstrate how bad actors could gain access and cause damage.

Static application security testing (SAST) is examination of the software asset from the inside out. This is done by combining comprehensive analysis via an automated tool with expert review of the results and source code to find critical software security vulnerabilities such as SQL injection, cross-site scripting, buffer overflows, and the rest of the OWASP top 10.

The value of Static Analysis + Pentesting in a due diligence sprint

Both PT and SAST techniques can be used in the development of a company’s own code or during M&A due diligence. At some level, the approaches are the same, but M&A due diligence brings some unique challenges, including

• SAST requires access to source code. Penetration testing requires access to systems and is most effective if guided by some proprietary information. Targets in acquisitions are reluctant to provide this kind of access to a potential acquirer. To protect all interests, a best practice is to engage an independent third party to evaluate the security posture of the target’s software but avoid any disclosure of source code or any detailed instructions on how to break-in in reports to the acquirer.
• M&A transactions move fast and there is limited time for due diligence. It’s critical that the acquirer scale the learning curve as quickly as possible in evaluating the overall AppSec posture of a target’s assets.

Combining PT and SAST to provide greater insights

“Defense in depth” means having multiple layers of security. The idea is that something that sneaks through one layer will be caught at the next. The concept holds in application security. Although there is some overlap in PT and SAST analyses, each finds different types of security flaws, so the results are complementary.

With most sorts of human analysis, there are diminishing returns; more work leads to more insights, but it gets harder and harder to dig them out. Analysis turns up low-hanging fruit early, and less and less over time. In M&A due diligence, which is inherently time-constrained, the aim is to get a clear picture of how secure the software is, not necessarily to identify every individual flaw. A great benefit of pursuing two angles of analysis in parallel is that each produces its own results quickly, providing more insight than would have been achieved by spending more time on one technique.

Two independent tests are a good idea, but even more benefit can be gained from collaboration. A great practice is conducting a PT and SAST simultaneously on a given application, with the assessors informing each other on an ongoing basis throughout the engagements to prioritize directions to explore in more depth.

The amount of effort needed to test access controls and identify complex vulnerabilities is much greater for penetration testing by itself. SAST insights can provide a “blueprint” of areas to prioritize within the PT and explore in greater depth. If a SAST assessor identifies a poorly implemented functional area, or a particular setting is not disabled explicitly, they would point their PT colleagues to attempt an exploit. In this scenario, a PT might find that what looked like a minor flow was, in fact, a path to extract the entire database. Or they might find that the code contains even more exploitable security issues beyond the original SAST identification, escalating the severity of concern.

Similarly, penetration testing can help inform the SAST assessor. The “outside-in” nature of PT means that they can only infer what is lacking in the underlying code—clues as to the underlying problem—but a SAST assessor can run those down, often finding the cause and broader issues.