What are the challenges with SAST that don't need a better engine

Earlier today I commented on twitter "I've been trying to tell the Commercial SAST vendors for ages that current problems is not the engine" and was asked 'What do you see the problem being?'.

So here is my very quick list of problems I see with SAST engines, which have nothing to do with the core engine

• Context (the scanner's need to understand the context of the code being scanner)
• Frameworks (its customisations and the Frameworks used by those Frameworks)
• Customisation and the packing/distribution of that customisation
• Community (we need to solve the SAST problem together)
• Trace Glueing
• Trace Visualization and Filtering (namely when we have 100x thousands or millions of traces)
• Rules management (mass/automatic creation, customisation, distribution, rating/voting, connection with remediation guidance)
• Workflow
• Consumability and Data Exchange (both created by the tool and created by other tools)
• Intermediate representation exports and imports (in a nutshell ALL data created by an SAST engine must be saved/serialised to disk, where it can be consumed/manipulated, and if required,  loaded/deserialised into memory)
• Interoperability (not only with other security tools like DAST, but also with tools used by developers, software architects, managers, testers, buyers, etc...) 
• Scan and Rules Store (we need an ecosystem of 'rules buyers and sellers')
• 'Code Blocks' Rating (with a U-Form tag system to keep track of it)
• Collaboration across the multiple players (from devs to security consultants to architects to buyers) 
• Targeted Code Advise
• Targeted Code Remediation
• Auto-Code Fixing
• Behinds-the-scene Code Fixing

There are two other items which I left out of the list, which are 'Scalability' and 'Modularity'. 

Although these are some of the key areas that the SAST teams use to justify their efforts on the engine (and not on the items above), I have a different view on how they needs to be done. Using the Trillions video analogy of the two mountains, at the moment the SAST vendors are still trying to build extensions into the smaller mountain, where I'm asking them to work with the ones that are trying to climb the bigger mountain.

Meanwhile, since it will still a while before the SAST vendors start playing with us, we can move on and start solving the problems ourselves.

As you can by the list in What am I doing with Cat.NET? that is exactly what I'm doing :)

For reference, here are some related blog posts that cover this topic (in chronological order):

• In SAST the issue is 'Trace Connection', not 'Scan Size' 
• We need Security-focused SAST/Static-Analysis rules 
• Secure coding (and Application Security) must be invisible to developers 
• Integrating Security into the User's Gui - In this case Rational AppScan Source in AppScan 
• Using O2 to help an AppScan Source (and Standard) user 
• First Answer to: Why doesn't SAST have better Framework support (for example Spring MVC)? 
• What does SAST mean? And where does it come from? 
• Why doesn't SAST have better Framework support (for example Spring MVC)?
• On Comments on Static Tools thread and Frameworks 
• The Need for Standards to evaluate Static Analysis tools 
• Part II - Why IBM will ‘solve the problem’ 
• Part I - IBM Application Security related tools & "AppScan 2011" 

And from Some proposed Visions for next OWASP Summit there is the idea of doing an OWASP Summit on Web Frameworks or an OWASP Summit on Static Analysis (we know the industry is serious when these are finally happening)