[erlang-questions] Security scanning tools for Erlang?

[Richard A. O'Keefe]

It may be worth mentioning that some static analysers are "deep"
while other static analysers are "shallow".  For example, there
was a product I evaluated for C that just did crude pattern matching,
no data flow at all.  There's another one I actually use from time
to time called "ITS4" (It's the Software, Stupid! (Security Scanner))".
Basically, it just looks for calls to dangerous functions.
Here's the kind of report you get:

y.tab.c:157:(Risky) fopen
Can lead to process/file interaction race conditions (TOCTOU category B)
Manipulate file descriptors, not symbolic names, when possible.
----------------
pop2lex.c:203:(Some risk) getc
Be careful not to introduce a buffer overflow when using in a loop.
Make sure to check your buffer boundries.
----------------
unv7.c:20:(Some risk) getchar
Be careful not to introduce a buffer overflow when using in a loop.
Make sure to check your buffer boundries.
----------------

fopen:  There is no alternative to using it here.
The program needs to take a list of file names on the command line.

getc: The mere *mention* of getc() triggered the warning.
As it happens, the warning is justified: many of the characters
are stored into a buffer without checks.

getchar: Again, the mere mention of the function triggers a warning.
In this case, no characters are stored anywhere, so the warning looks
a bit stupid.


What I'm getting at is that the requirement for a static checker
could be *usefully* met by a checker that (a) walks over ASTs and
(b) isn't very smart.

Oh yeah, there's a project that looked rather interesting where
they were building static checkers that don't even *parse* the
source code thoroughly, so that you can quickly build static
checkers for unusual languages or to cope with widely varying
dialects (C++?).  I've corresponded with them, and they said they
were interested in making their sources available, but that was a
couple of months ago.  Their argument was that building full-scale
"deep" analysers is *hard* and that such programs *themselves* tend
to be buggy, so that "partial" checkers may be just as useful, and
I think their results support their claim.