Thursday, 21 June 2012

This is how we have to show security vulnerabilities to developers (in real time as they are created)

I posted a PoC today that represents my vision for O2 and what I have been trying to do for the past 5 years.

You can see the video at Real-time Vulnerability Creation Feedback inside VisualStudio (with Greens and Reds) where every time the user makes a change to the code there is an auto-compilation (using Roslyn's C# compiler) and a SAST scan (using Cat.NET)

What I like the most about this, is that I now get to think about 'the best workflow to present developers the security guidance they need'.

Although this PoC is quite agressive (I do a compilation and scan on every keystoke which is a bit OTT), here is another video that shows a bigger compilation+scan on save: Real-Time C# Solution Compilation and Security Scanning (using Roslyn and Cat.NET) 

What do you think?


Joshbw said...

The cost to fix a problem goes down the closer we get to the introduction of the problem (the fresher it is in the dev's mind, the less overhead to access and compile the source, etc). You really can't beat real time in that regard. By the same vein, we should not be trying to interfere with the devs' development processes - trying to introduce a new step into the mix doesn't go over well, but if you can introduce it into a step the dev already does (in this case, writing code) you very likely have a winner.

I have long wished that instead of the SAST providers continuing to expand the vulnerabilities that they do a crap job detecting, they focus on vulnerabilities that are very parsable, and build the parsing into the IDE in the same way spell check is built into word.

Dinis Cruz said...

Absolutely, that is why I think this PoC is so important since it will allow us to think about the next set of problems (which are a lot)

One of the things I kept saying to commercial vendors of SAST is that their engine is 'currently good enough', and the next set of major improvements will not come from better or faster 'detection' jobs (or by being able to scan the whole code).

The reason is simple, once you have the capability to follow taint data, the issue becomes how to better teach the engine what is going on with the application and how to create a workable loop between: the tools, the code the developers and the security guys.

Now that we have the opportunity to work on this (with this O2+Cat.NET poc), and figure out how to get this workflow working.