Earlier quoted context omitted.
Oracle cannot ignore annoying and low-expected-value static analysis tickets, but: 1) the answer should usually be either "fixed in this patch, install it" or "it's a false positive, try developing an actual exploit if you don't believe us". Not expensive, provided Oracle actually runs static analysis tools against their software and addresses the findings before releasing updates. 2) If Oracle actually runs static a…
Ah...you've never used one of these tools on a large code base. The problem is that when I run the tool in my QA environment, I identify the false positive and configure my tool to account for the false positive (or I create a compensating control). If you run the same tool, you'll see everything I tuned out, and I then have to go back and trace where the finding was tuned out, why it was tuned out and make sure that…
To deal with false positive reports from customers, Oracle needs to archive what the false positives in each release of their software according to popular tools are. Not the tools they use to find bugs: all tools customers use. It's not like they cannot afford tool licenses or large databases.
Adopting a code style that reduces false positives (along with bugs) and fixing actual problems before release so that no customer sees them would also be good policies.
Even without improving their software development process, educating users about which static analysis tools are discredited and rigorously demanding working test cases in support tickets to weed out false positives are two things Oracle could do without alienating their customers.