The real problem with "extending" a static analysis tool is "static analysis" is such a broad topic that that you need lots of machinery to do it in general: parsing, tree building, control flow graph extraction, data flow extraction, points-to analysis, interprocedural analysis, range analysis, the list goes on and on, see the tons of compiler literature on analyzing programs.
You might use pattern matching of surface syntax to focus the tool's attention on some program code, but you'll still have
to explain to the tool what you want it to "statically analyze" at that point
(and some analyses [such as points-to] require you do the analysis everywhere
first, and then just pick out the part you want).
Moral: don't expect extending a tool to do arbitrary analysis to be easy.
You should basically decide what kinds of analysis you care about in advance
(tainted inputs? subscript range checks? API abuse?) and find a tool that
already supports that kind of thing. At least then your "extensions" have
a chance of being simple by virtue of being similar to what the tool already does.
Our DMS Software Reengineering Toolkit is an attempt to amortize the cost of building all kinds of analysis machinery across many applications and langauges.
It provides the parsing, control/dataflow analysis and points-to analysis
to varying degrees for C, C++, Java and COBOL. And it has surface-syntax
pattern matching to help you "point".
See http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html