Adobe last week acknowledged that as many as 80 bugs in Flash Player were reported by a Google security engineer as it defended its decision not to spell out details of the vulnerabilities.
In a pair of blog posts, Adobe and Google -- the former in more detail -- spelled out how the number "400" that Ormandy had cited ended up being cut by 80%.
"The initial run of the ongoing [Google] effort resulted in about 400 unique crash signatures, which were logged as 106 individual security bugs following the initial triage," said Brad Arkin , Adobe's senior director of product security and privacy, in a blog post last week. "As these bugs were resolved, many were identified as duplicates that weren't caught during the initial triage. In the final analysis, the Flash Player update we shipped earlier this week contains about 80 code changes to fix these bugs."
Google's blog post , which was attributed to Chris Evans, Matt Moore and Ormandy -- all members of the company's security team -- used almost-identical language to describe the bug count culling. In the post, Google also said it had devoted 2,000 CPU cores over a four-week period to the massive "fuzzing" project directed at Flash.
Last week, Ormandy had questioned not only the bug total, but Adobe's decision not to list each of the vulnerabilities in the security bulletin that accompanied the update.
"To us, the joint projects we do with partners, including Google, are extensions of our internal security review and code hardening," said Arkin in an interview last Friday, echoing a statement the company made at the time.
Because it does not consider those flaws publicly known, Adobe does not assign them a CVE (Common Vulnerabilities and Exposures) designation, Arkin said. When it issued the Flash Player update and security bulletin , it listed just 13 CVEs; on Friday it added one more to account for those reported by Ormandy and Google.
"This update resolves multiple memory corruption vulnerabilities that could lead to code execution," Adobe stated in the new entry for CVE-2011-2424.
Normally, Adobe doesn't reveal a number associated with vulnerabilities it or its partners have found, and that have been patched. But Arkin acknowledged that it needed to do exactly that this time.
"With every release [of Flash Player] we do a lot of code hardening, but because there's been public discussion, this internal topic has become external," Arkin said.
Andrew Storms, director of security operations at nCircle Security, put that into plainer words. "They were forced to," said Storms.
CVEs are used by security researchers to correlate and coordinate publicly-disclosed vulnerabilities, said Storms, and by others, including analysts, the media and security professionals within organizations, to gauge how often a product is patched and how the vendor deals with bugs.
"If a product has a large number of CVEs, there's more concern about those managing the development lifecycle of the product," said Storms.
But since CVEs are assigned differently by different vendors, it's tricky to use them to compare several products' security prowess simply by looking at the numbers, Arkin argued.
Google and Mozilla, for instance, assign CVEs for vulnerabilities discovered by internal developers, as does Apple on occasion. Microsoft, like Adobe, does not.
In fact, Arkin credited the Chrome team's different approach to CVE assignments for last week's squabble. "We didn't allocate any CVEs because we viewed this testing as part of the [Secure Product Lifecycle] that spans the joint engineering efforts with the Google Chrome team," Arkin said in the blog. "This led to some confusion since the Google security team has a different approach to CVE allocation."
Another reason why Adobe didn't list each bug -- or more specifically each code change that resulted from its analysis of Google's fuzzing work -- is that it simply didn't have the time or resources.
"It's incredibly expensive to do that," said Arkin. "We'd rather drive those resources into making [Flash Player] better."
Storms understood Adobe's reluctance to list scores of CVEs.
"There's little value for them to do that because of the negative connotation around a high CVE count," said Storms.