Any kind of push for tools to end developers is “goodness” – they are the ones closest to the code, and more likely to understand the context of what it’s doing, as well has having a much more “limited” view of the entire codebase which makes managing the output of these tools (like the often explosion of results).

I’m my experience though, the best way of helping devs write more secure apps is to limit the ways they can shoot themselves in the foot. Banning “dangerous” APIs (although strcpy isn’t inherently “bad”, it’s one of those functions where there are less dangerous alternatives) is one way, as is adding “protection” measures (like NX, ASLR, anti-XSS, etc, etc) into the platform – something that Microsoft has done very successfully IMO.

I was amused by the fan comment, but certainly not offended

Agreed that (a)’s more likely than (b) — and more than we accomplished at Microsoft back in the days I was working on the tools there.

PreFast, the internal MSFT version

Actually, PREfast (along with FxCop) has been available in Visual Studio since VS2005 — it’s the /analyze compiler option. [Before that, our joke was that PREfix was difficult enough to deploy that it often required an in-person consultant, and we just couldn't figure out a way to fit him or her into the VS box.] One of the interesting business challenges in static analysis is the presence of high-quality tools like these that come with the development enviroment — and like FindBugs (for Java) that are open source. On the other hand, from the software engineering perspective this is goodness — both because the price is right, and because it pushes static analysis companies to add more powerful functionality and improve usability so that people will actually pay money.

jon