I think it's just the same case as what's always improved Linux security: outside contributors actually auditing the code for security issues, which apparently isn't done otherwise. Other than coccinelle (http://coccinelle.lip6.fr/impact_linux.php) which isn't exactly new (it's been used for patches since 2006) I don't know what "new static analysis tools" are being used. Dan Rosenberg, who's discovered a ridiculous number of vulnerabilities this year, has been using grep. Tavis' auditing has been manual AFAIK.
It's worse than just 80 for this year. You called 80 the "known issues", but really it's just the problems for which CVEs have been allocated. Dan Rosenberg had a huge collection of information leak vulnerabilities that still haven't received CVEs despite numerous requests. If you follow oss-sec (I know Kees follows it, but this is directed to the other readers), you'll notice Eugene often sends kernel vulnerability information to the list with a message of "I'm not requesting a CVE for this as it does not affect any Red Hat-supported kernels". Often this means the vulnerability was introduced in newer kernels. This mostly explains why there are suspiciously no CVEs for recent kernels: simply that nobody bothers to ask for CVEs for recently introduced vulnerabilities.
And again it demonstrates the problem of silent vulnerability fixing. The editor is left to gauge vulnerability risk by allocated CVEs -- a biased metric which ultimately biases any conclusions derived purely from the dataset. How different would it look if Dan Rosenberg didn't mail repeatedly to make sure the vulnerabilities he discovered were assigned CVEs? It might end up like my http://grsecurity.net/~spender/64bit_dos.c which after over 2 months now still has no CVEs or committed fixes.
The sad thing is nobody has any clue how bad it really is. The scary thing is we're finding evidence that blackhats have developed exploits for vulns months or years ahead of the reactive vuln fixing going on. Look at how Microsoft changed strategy years ago in response to these systemic problems, or how Adobe recently has been taking some defensive steps (hardening their JIT and sandboxing the next version of Reader). Linux is in dire need of a similar change, but it's unlikely to ever occur in mainline unless starts with the leadership.