This is a short presentation from Checkmarx research labs

This presentation was originally presented at OWASP Netherlands 2009.

This paper illustrates the problems associated with code analysis executed on binary or byte-code representations and how scan of the source itself solves the drawbacks

This is a short presentation from Checkmarx research labs

Presented at the OWASP 2009 Conference Israel

There is evidence that compilation-based code analysis tools negatively impact risk mitigation efforts. As Gartner analyst Neil MacDonald observed, “we’ve talked with a number of clients that purchased a [static analysis] tool which later becomes expensive “shelfware” or where the project was halted after delivering mixed results.”1 Mr. MacDonald correctly singles out poor security process as an obstacle—but there are serious technical factors that contribute to the “shelfware” problem. A key, overlooked bottleneck comes from the compiler based approach. Getting the code into a state where it can be compiled and linked is not an easy task. How does the need for compilation negatively impact the stakeholders who rely on code analysis?

Recently there have been fundamental changes in the static security analysis tool space that directly address the major issues that made developers shy away from the earlier tools: usability, efficiency and false positive reporting.

Checkmarx Research Labs present a novel way to protect .NET assemblies against reverse-engineering and recompilation. By injecting them with commands that are activated only at the recompilation stage, the application retroactively detects the reverse-engineering process and acts upon it.