[Owasp-o2-platform] Why doesn't SAST have better Framework support (for example Spring MVC)?
jsteven at cigital.com
Mon Oct 24 19:18:35 EDT 2011
When Gary McGraw and I first sat down to seek a path to commercialization for our various SAST research prototypes (2000 era), it won't shock Dennis that the first folk we discussed it with were Microsoft (Visual Studio team), Borland, and Sun. At that time, they saw some value to the technology but two things prevented forward progress:
* "State of art" SAST remained dependent on a fair amount of Security SME to shepherd both set up and results triage
* Development teams had a voracious appetite for optimization (performance) but security had yet failed to achieve critical (awareness) mass (*1)
Even as late as our subsequent sale of technology to Kleiner Perkins ('03), we saw a market still unsure of exactly how much 1) initial 'application on-boarding' should be necessary for a "high fidelity scan" and 2) how much a tool should focus on quality, security, or attempt to do well in both focuses. At the time, a rich field of tools existed: Klokwork, Parasoft's [XXX]Test suite and (later entry) Coverity focused more on quality, while Fortify and Ounce's tooling focused more on Security. However, the last two tools definitely fell down on different sides of the "how much time should you take on-boarding applications and helping the tool understand the effects of constructs like MVC frameworks.
Seven years on, it's easy to lament the lack of framework understanding progress; sure. But, the reason remains clear:
1) Developers, themselves, often don't understand the effect & flow of the frameworks they use and thusly can't articulate a demand for better fidelity;
2) No mandate for "building software securely" blankets the industry's development shops yet--security remains principally a reactive and regulatory-driven concern;
3) We, the world's scanning SMEs, have not done an effective job educating the market and (more importantly) influential SAST customers on what to demand.
For about 6 mo. I've been writing, "Expect the coming versions of industry-leading tools to continue to improve framework support." Do.
Remember, however, that supporting a framework requires a variety of things. Cigital puts a simple and fine point on this concept of support, including but not limited to:
* A framework's entry points
* The framework's exit points (framework-specific & common taint)
* The effect of framework-specific taint on common exit points
* Comprehensive "mark up" for pass-through and similar data flow constructs
Understand that as of the writing of this email NO COMMERCIAL LEADING tool [GT1] has been verified to, as per the above outline, "support" the Java MVC frameworks [BM1] commonly used by Fortune 100 enterprises. However, it's my understanding that persons within every commercial leading tool's staff claim that their tool does support [at least some of] these frameworks. If you're not sure who to believe, conduct your own tests.
Dinis and I might extend this simplistic definition of support to include things like paring down taint using cleanse functions where framework security controls are in play, and so forth.
To me, whether or not our experimentation or vendor claims are correct (after 10 years of practice on this topic, I ask the reader to grant at least an email's worth of license here eh?), the fact remains that -->EVERY<-- client I work with has crafted their own MVC frameworks for production deployment. With absolute certainty, I can assert that no commercial leading SAST supports frameworks high fidelity data flow through schemes they haven't seen, without consulting support, fancy scaffolding (like Dinis' O2, Cigital's ESP), or things just over the commercial horizon.
This, to me, is the real Achilles heel of the commercial tools... ...and to the whole scheme of compiler integration. At present, I have no evidence that vendor engagements successfully include this kind of customization support. And, if we push these tools' functionality wholly within the IDE and demand developers wield them without a helping hand, I have no faith that we can expect that developers who (again) are 1) not incentivized to care about security and 2) who don't fully understand the frameworks, are going to be able to cross the chasm of tuning a tool for the kind of support that Cigital demands as "high fidelity".
I'm not the only one that thinks this way. In circles I travel, I've begun to see some really interesting solutions to this shepherding problem. In about 9 mo. I expect to have more definitive (and statistically significant) conclusions on these alternatives.
Internal Chief Technology Officer, Cigital
Fingerprint: 4772 F7F3 1019 4668 62AD
94B0 AE7F EEF4 62D5 F908
* (*1) - Remember, the Gates memo was sent in '02.
* [GT1] - http://www.veracode.com/analyst-reports/index.html
* [BM1] - http://www.thebuzzmedia.com/which-is-the-hottest-java-web-framework-or-maybe-not-java/
On Oct 23, 2011, at 1:32 PM, Dennis Groves wrote:
> It is in my humble opinion that there are many, many tools required at different places and times in the IT security lifecycle. And that nothing provides 100% coverage. However, each of the tools does have a place and incrementally help to reduce risk to acceptable levels.
> In my humble opinion SAST has the most promise as a compiler integrated function - that provides analysis at compile time when static trees are already built and should happen right along side syntactical and lexical analysis. I believe such compile-time integration would slightly raise the bar; and drive back some problems to the place where they are known to be most inexpensive to address, like - data input validation - why doesn't it happen?
More information about the Owasp-o2-platform