Comprehensive Static Analysis: Accuracy, Speed, or Completeness
TL;DR / Summary at the end of the post.
Full Disclosure up-front: I am employed as a Code Scanning Architect at GitHub at the time I published this article.
As in my previous posts on Static Code Analysis and Binary Static Analysis, , I will reference points made in Part 1 of this series where I discussed the technological differences between Static Code Analysis (SCA), Binary Static Analysis (BSA), and Comprehensive Static Analysis (CSA). In this post I will dive further into why Comprehensive Static Analysis produces higher quality results from other scanning methods; I will likewise discuss what implementation looks like for CSA, and what that means for your AppSec / DevSecOps program.
Comprehensive Static Analysis (CSA) is the newest technology to enter the space, and is changing the model for how Security and Development teams work together to implement secure development practices. While traditional application security teams operate much like ambulance drivers that show up at the hospital when an emergency has taken place, Comprehensive Static Analysis turns the security team into another specialist - operating within the hospital alongside other practitioners. The main difference between CSA and other forms of analysis starts with how it integrates into the development process; and like building a new wing in a hospital - this process will take time, but has an immensely positive impact in the long run.
Unlike Static Code Analysis (which reads the code and performs shallow data flow mapping) or Binary Static Analysis (which performs imperfect data flow mapping - without access to source code - before analyzing the binary), Comprehensive Static Analysis requires access to the source code and plugs into the build process. Likewise, while CSA follows builds for compiled languages, it also performs an approximate “compilation” for interpreted languages in order to accurately map how data flows through such applications.
For CSA, plugging into the build process means that it is able determine how remote sources will sink within the application - and what (if any) sanitization steps take place throughout that process. This allows for analysis to accurately distinguish between sources that can be remotely exploited, as opposed to locally sourced exploits for which the underlying system would need to be compromised first (or a malicious developer would need to introduce attacks in properties files / environment variables et cetera).
The detailed mapping of an application’s data flows - and distinguishing between local vs. remote sources - is ultimately what differentiates Comprehensive Static Analysis from other solutions in this space. By having an accurate data flow map, it is far easier to identify how remotely exploitable vulnerabilities can be executed against your application.
How to support this content: If you find this post useful, enjoyable, or influential (and have the coin to spare) - you can support the content I create via Patreon.️ Thank you to those who already support this blog! 😊 And now, back to that content you were enjoying! 🎉
Moreover, by plugging into the build process for compiled applications, CSA can determine what optimizations are taking place - including when code is removed from the final binary due to an absence of linkers to other parts of the application. What this means for application security teams is that they are able to reduce false positive findings by a large order of magnitude, and that they are likewise able to show developers the full path of exploitation in the code - both of which leads to greatly reduced friction between the teams.
That being said, there are a handful of challenges worth mentioning when it comes to implementing Comprehensive Static Analysis. First and foremost, security teams will feel uneasy about how dramatic the difference is in the volume of findings produced by CSA tools. Over the last twenty years we have been drowning in hundreds (or thousands) of static analysis findings from our tools - getting past this uneasiness is something many security teams will need to overcome if they want to reduce friction with developers and make a dent when it comes to driving remediation of findings.
Secondly, as stated earlier the implementation phase will feel more involved than other static analysis solutions. Some teams will have unconventional build processes that need to be reconfigured, and that takes time. The good news is that this investment isn’t always necessary - and at worst only happens once per application. In my experience most security teams will find common patterns in their organization that will become easier to implement when onboarding new teams into the security program.
Likewise, scan times will often be brought up as a concern when using CSA tools. While not as slow as Binary Static Analysis, CSA tools will be slower than traditional Static Code Analysis. Security teams rightly perceive this as adding friction to the development process, but often lose sight of the fact that producing more accurate findings far outweighs the small amount of additional time it takes to complete a security scan. I mean really - if a development team needs to do a code review for a pull request before they merge their code, how many teams actually do their reviews within fifteen to twenty minutes of the PR being opened?
In any case, it is also worth noting that security findings will generally live where developers work. Getting used to working alongside developers will take time, and any good CSA tool will provide security teams methods for exporting data to SIEM or other analytics platforms for tracking and alerting.
Finally, applications built as a microservice are likely to require some customization for vulnerability checks in order to track local sources - as this kind of application architecture often passes data in ways that aren’t considered “remote” from the application perspective. Using CSA tools that make it easy to customize vulnerability checks will be key to resolving this challenge.
So how does Comprehensive Static Analysis (CSA) stack up to the competition?
- Accuracy: High [ + ]
- Speed: Medium [ = ]
- Completeness: High [ + ]
- Impl. Complexity: Medium [ = ]
- Developer Friction: Low [ + ]
TL;DR / Summary
Comprehensive Static Analysis differs from other solutions in that it needs access to the source code and plugs into the build process for compiled languages (or performs an approximate “compilation” for interpreted languages). This process leads to accurate data flow mapping, and the ability to distinguish between remote and local sources - which in turn means fewer (but highly accurate and exploitable) findings. While implementation will sometimes require more up-front investment from security and development teams to start making use of the solution, the long-term benefits of highly accurate findings with decent scanning speed means that Comprehensive Static Analysis generates faster and easier remediation of vulnerabilities.
That being said, adding some customizations for vulnerability checks in microservices applications may be necessary to fully benefit from CSA. Finally, Comprehensive Static Analysis helps transform security teams from “ambulance drivers” into “specialists” in the hospital, working alongside their peers in development to improve the health of the company’s applications.
And that concludes Part 2 of this series on Static Analysis! Thank you for your time, and stay tuned for Part 3 where I’ll discuss the important differences between Local vs. Remote Sources, and what sort of vulnerabilities they generate! Thank you again - and in the interim remember to git commit && stay classy!
Cheers,
Keith // securingdev
If you found this post useful or interesting, I invite you to support my content through Patreon 😊 and thanks once again to those who already support this content!😊