Looking for experience with both built in and custom checks.
I do not need references to commercial source code analysers.
To have a more complete set of rules, you could use the FindBugs plugin Find Security Bugs. It include 36 new detectors. Of course, the plugin generate some false positives, but you can always disable specific detectors.
Disclaimer : I'm the author of the tool mention
checkstyle checks the code against coding standards - you can use the Sun/Oracle standard or indeed use your own. It doesn't really find vulnerabilities as such although, vulnerabilities will be harder to find if the code doesn't follow your coding standards.
Findbugs will find sql injection, hard-coded database passwords, XSS code vulnerabilities, incorrect cookie creation and that kind of thing. It is customisable so you can add in more rules of your own or from somewhere else.
HOWEVER. that's only part of the story. In my view the real benefit of using checkstyle, pmd and findbugs is that you can visually report the findings using the open source tool Sonar. This will give you an overview of the quality of code so you can pile in resources to fix the worst offending code. It allows you to visually magnify each library and then home into the worst offenders. This is particularly good on large projects or where you are relying on various development teams.
None, checkstyle is for code formatting and chechking cohesion/coupling rules on your code. I.e. no file should be longer than, no method can be longer than etc. As to findbugs is looks for common software errors, not specific to security. Common checks are unused vars, ommited conditions and so on. It's pretty hard to check software for security vulns, except from common B/O. And static analyzers are limited in their functionality.
In terms of mobile code vulnerabilities (i.e. where you are trying to ensure trusted code can safely be used by less trusted code, typically dynamically downloaded over the web), FindBugs finds some mutable static vulnerabilities. It does some over-reporting due to not understanding the
"package.access" security property. It massively under reports because it is not very good detecting when a mutable static hidden by access modifiers (or package.access) is indirectly accessible, although it has modestly improved in that area.
I think there are some attempts to detect the likes of SQL injection. IMO, if you have any injection vulnerabilities you're in a very bad place to start with.
As far as I am aware, no Java static analyser is much cop other than the aforementioned mutable static detection. That and
grep -R java.lang.reflect. ., for example). Having said that, in my experience general code quality is the foundation of secure software, and static analysers (including that done by your compilar) may well have a small part to play.