Our firm integrate FindSecBugs in sonarQube and enable a bunch of security rules.
Thus sonarLint cannot report those issues in IDE even in connected mode. We have to integrate FindSecBugs separately in IDE in order to expose those security issues.
Not sure whether there is plan for sonarLint to integrate FindSecBugs as well?
Hi CMM,
Thanks for your question. Let me take a moment to emphasize that SonarLint is focused on helping individual developers write quality code in the many languages we support. It’s all about fixing issues as timely as possible and by the person that created them.
That said, we happen to think our Java web analyzers have excellent coverage and are surely capable of helping you write clean code. 
If you feel that you’d like additional coverage from another tool, you can certainly check to see if FindSecBugs also makes a plugin for your particular IDE(s) of choice. We feel that SonarLint best serves the development community by being a sharp and focused code quality tool and not by straying from its roots and becoming an issue aggregator.
Clint
Cmm,
As an addendum to Clint’s answer, you might be interested in this report that shows how FindSecBugs rules map to rules native to the SonarQube Java Analyzer (and as such are available in SonarLint).
Colin
Wow, this is great. Thank you Colin!
Hi Clint,
Thank you very much for your reply.
I agree with your point. And since Colin says Sonar native analyzer will cover findsecbugs rules, that totally suits my need.
Cao,
To be clear, that report I linked shows the rules that have been implemented and the ones yet to be implemented (if they will be implemented at all).
There might still be the use for both, but at least you know your options (and which FindSecBugs rules can be used with SonarLint because they have a SonarJava equivilant).
Colin
Colin,
Sure, I see there are almost 40% findsecbugs rules have sonarJava equivalant now. So currently we are using both, but at the end, hopefully we can switch to rely on sonarJava only. I am glad to know the activity you shared and we can deal with the gap while the activity is ongoing.
Min
Hi Colin,
The report link you post earlier seems no longer reachable. Is it moved to another place?
Regards,
Min
Min,
As I found out after I originally posted that link (prior to being hired at SonarSource) these reports were intended mostly for internal consumption and stopped being updated quite some time ago, so they were pulled.
Colin
Hi Colin,
if i may, i would like to chime in with my current train of thought as a (yet) nonpaying consumer of the community-edition.
We are trying to get a clear vision about the risks of switching
- from our rulesets defined in external plugins
- to the rulesets defined in sonarJava
We would like to get a more easy upgradepath but we would not like to lose checks we might have enabled.
This means that we weigh the possibility of external-plugin incompatibilites agains the possibility of ruleset-gaps / -inequalites / -inconsistencies
To get a better vision concerning the “alignment” of rulesets, these Reports you mention might be a very real boon! I am currently thumbing my nose at the possibility to use that kind of report to match e.g. the equivalencies of Findbugs-Ruleset vs sonar-java ruleset.
It would probably be even more instilling trust in a decision to use sonarjava if one might find explanations concerning the reasons why a rule was or was not matched in sonar-java.
Please be so kind as to, if that is in your possibilites, forward this kind of thinking to someone who might be able to decide if these reports could be made available again.
cheers
Daniel
P.S.: I hope that pinging someone from afar is not considered impolite. If that might be the case, please tell me so. Because i would like to mention @ganncamp here 
Hey Daniel,
I also see value in helping users understand the gaps between an external analyser and SonarSource analysers. To be entirely honest, in my past as a SonarQube admin I also found these reports helpful (specifically with FXCop).
There are some interesting challenges with creating these reports – one is that SonarJava is not necessarily trying to be FindBugs, PMD, etc. SonarSource might disagree with a rule implementation, or find a different one that has more value. How does SonarSource provide a mapping then, if the issues raised on code could be different? I think it’s very real to imagine users who won’t think of SonarJava’s implementations as equivalent unless there is an exact match.
Perhaps SonarSource decides a rule isn’t relevant or that implementation is too costly to have a real benefit (too much noise, too many false negatives, etc.) Maintaining comprehensive information about why we did/did not include a rule from another analyser is not necessarily a priority because… SonarQube is not meant to just be a substitute for other analysers.
Finally, as other analysers grow and change, and as SonarSource’s grow and change, it becomes non-trivial to keep these reports up to date.
These are not blockers to helping users transition to our code analysers from others (and in fact, we are only strengthening the ability to import rules from external analysers) but they are some of the challenges.
Colin
Colin, first of all thank you for a thoughtful, insightful and interesting reply!
I also see ann typing (and am a bit time constrained) so i will take some time to reply with some more sentences.
Thanks
Daniel