Oracle needs to archive what the false positives in each release of their software according to popular tools are.
Oh, wow! How could we be so stupid. All we have to do is build a false positive database of all tools, everywhere. Don't forget for all versions. Not just all versions of the tools, all versions of your code. And whenever a new tool or version comes out, rerun everything. Because inevitably some guy limping along with Oracle 8 is going to download the latest Parasoft release and he's gonna what a word with you because probably Parasoft doesn't even have an Oracle 8 instance laying around any more. No problem!
Adopting a code style that reduces false positives...
Force coders to change their style because "AppScan v6.00.01 patch 10 throws a falsy on this expression in version 11i patch 200". Sure, why not...fuck those guys. People should be slaves to the tools, not the other way around.
rigorously demanding working test cases
Forcing your 400k some odd customers to come up with test cases for your code before you pay attention to the vulnerability reports they genuinely believe are important. That sure won't alienate customers at all.
Proof once again how easy it is to wave ones hand over a complicated subject one doesn't fully understand, assign simple (and wrong) solutions based on limited information and declare others inadequate.
I doubt there is such a flood of false positive reports from customers misusing static analysis tools as the article complains about, but as far as Oracle wants to do something about them minimizing the cost of writing off a report as a false positive is the only rational solution. (Complaining about reverse engineering is not rational.)
Investigating analysis tool reports once and for all is the only way to minimize this cost. You seem to neglect various cost-mitigating factors:
- Reports from different tools are going to hit the exact same spots in code, for the same reasons, making the marginal cost of analyzing the report from yet another tool low and decreasing and making the matching between support tickets and known false positive reports very easy. Closing tickets as vague would also be easy.
- Reports for version N and version N+1 of the product are going to be very similar. Likewise for version N and N+1 of a static analysis tool.
- Only popular (and good) analysis tools deserve up-front usage before releasing products. Others can be run only after someone files reports, and for the most unlikely ones being unprepared is the best choice. There's no value in a strawman like complete coverage of all possible tools.
- Static analysis tools are useful. Using them thoroughly would provide significant value beyond the dubious niche of reverse engineering support tickets.
Oh, wow! How could we be so stupid. All we have to do is build a false positive database of all tools, everywhere. Don't forget for all versions. Not just all versions of the tools, all versions of your code. And whenever a new tool or version comes out, rerun everything. Because inevitably some guy limping along with Oracle 8 is going to download the latest Parasoft release and he's gonna what a word with you because probably Parasoft doesn't even have an Oracle 8 instance laying around any more. No problem!
Adopting a code style that reduces false positives...
Force coders to change their style because "AppScan v6.00.01 patch 10 throws a falsy on this expression in version 11i patch 200". Sure, why not...fuck those guys. People should be slaves to the tools, not the other way around.
rigorously demanding working test cases
Forcing your 400k some odd customers to come up with test cases for your code before you pay attention to the vulnerability reports they genuinely believe are important. That sure won't alienate customers at all.
Proof once again how easy it is to wave ones hand over a complicated subject one doesn't fully understand, assign simple (and wrong) solutions based on limited information and declare others inadequate.