Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Looking for experience with both built in and custom checks.

I do not need references to commercial source code analysers.

share|improve this question
2  
As fatfredyy pointed out, these tools aren't designed to check for vulnerabilities. If it's a commercial project, I recommend checking out Veracode. They do some really nice work with black-box static analysis, and offer white-box source reviews too. (disclaimer: no affiliation with the company at all, your mileage may vary, I just like their work) –  Polynomial Jan 8 '13 at 7:18
    
it's worth mentioning that one of the key advantages of code analysers (like findbugs etc)n is that they can detect issues as the code is being entered by the developer and at "build". Veracode (etc) are really only good for analysing code on release - which is often quite far down the development path. –  Callum Wilson Jan 8 '13 at 9:23

4 Answers 4

up vote 3 down vote accepted

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

share|improve this answer
    
Thanks, looks interesting. We'll check it out. What was the motivation behind writing these checks? –  Vitaly Osipov Apr 23 '13 at 0:30
    
Initially, I was just playing with FindBugs api. But after I found a need for my own security code review. –  h3xStream Apr 23 '13 at 0:46
    
Any idea how to use the plugin via the findbugs ant task? h3xstream.github.io/find-sec-bugs/tutorials.htm doesn't have such section. –  cherouvim Jul 18 at 12:28
    
@cherouvim findbugs.sourceforge.net/manual/anttask.html –  h3xStream Jul 18 at 15:21
    
@h3xStream: thanks, I've seen this. Doesn't mention anything about using findbugs plugins though. –  cherouvim Jul 18 at 20:36

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.

share|improve this answer

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.

share|improve this answer
    
Static analyzers are quite effective to assist code review. In code review, tons of checks needs to be redone. Many specialized tools focus only on security : samate.nist.gov/index.php/Source_Code_Security_Analyzers.html –  h3xStream Apr 21 '13 at 20:32

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 (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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.