"I am honestly shocked that they only fixed two database vulnerabilities," said Alex Rothacker, manager of Application Security's research arm, TeamSHATTER.
According to Rothacker, his firm currently has nine vulnerabilities reported in Oracle's queue of discovered vulnerabilities. While that might not seem like a lot on its face, he said, one of them dates back to 2009 and five of them can result in privilege escalation. In addition, that's only the vulnerabilities discovered by AppSec researchers. Based on his conversations with those in the community, Oracle has been notified by other vendors and independent researchers about many other vulnerabilities, as well.
"There's definitely more stuff out there than just those nine," Rothacker said.
Rothacker said that because many Oracle customers are loathe to make fixes in their databases anyhow, this lack of pressure is what allows the firm to "get away with taking its time on these CPUs."
Wolfgang Kandek, CTO of Qualys, tends to agree that the slow speed at which database patches are generally applied could contribute to Oracle slowing down its pace with these updates.
"Database patching is definitely slower than other areas, such as servers or workstations," he said. "You can find vulnerabilities and Oracle can fix them, but if customers do not install them or come back to Oracle and say, 'this is important for me,' it makes sense that Oracle could maintain that flow of patch schedule. The rollout schedule is a reflection of how much users actually pay attention to those things."
However, Amichai Shulman, CTO of Imperva, believes there is a bottleneck in the Oracle patching process that needs fixing.
Database access controls keep information out of the wrong hands. Limit who sees what to stop leaks--accidental and otherwise. Also in the new, all-digital Dark Reading supplement: Why user provisioning isn't as simple as it sounds. Download the supplement now. (Free registration required.)