You'd have to audit the source code first, though, which is not a trivial thing to do.

But you can bet there will be plenty of people looking at it, and that group of people will also likely include security professionals looking to use it. I'm not sure I can honestly think of a stupider move in this area than to include nefarious code in an open source security auditing tool aimed at the highest and most complex levels of security auditing and used by professionals whose job it is to find and announce these things.

That doesn't mean assume nothing's wrong, but I'm pretty sure this thing will have some pretty talented people looking at it fairly early just for kicks, so of things to worry about, this isn't high on my list.

Given the audience I feel like the source code will be audited by the community in record time.

I don't get the criticism here, you're right on the money. What's the one group of people absolutely guaranteed to

a) audit a tool like this and

b) have the chops to perform that audit

Reverse engineers. If you're nervous, just wait 2 months and follow Twitter.

exactly my point. When they released SELinux this was the argument and how many lines of code does an OS have?

Lines of code is not a great metric to equate to the effort of auditing the code.

Harder to meter: how understandable is the code? More verbose, but more easily understandable code will be far easier to audit.

Personally, I'd rather a million lines of code that are clear and obvious than 500k that are obtuse, terse and/or obfuscated.