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.

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)