Google released a new version (13.0.782.215) of its Chrome browser Monday that includes patches for 11 vulnerabilities. Nine of the vulnerabilities are rated as being of "high" severity, while one is "medium." The other, meanwhile, is "critical," which is Google's ranking for the most severe vulnerabilities found.

That bug is the sixth critical vulnerability in Chrome discovered in 2011 and relates to "memory corruption in vertex handing"--code that handles three-dimensional rendering--in the Windows version of Chrome. Credit for discovering the bug was given to Michael Braithwaite, a senior engineer at Turbulenz, and it earned him $1,337 from Google.

According to the Google Chromium blog, Michel Aubizziere (aka "miaubiz"), a regular Google bug bounty winner, found two new bugs, both rated high severity, earning him $2,000 in total. He also independently verified a third bug of high severity that had been found by Google.

Other bugs, meanwhile, involved "integer overflow in uniform arrays," buggy PDF memory handling in Chrome (Linux only), and various use after free errors.

All told, $8,000 in related bug bounties were paid out for nine bugs; two had been discovered by Google's own researchers. The current payout is less than the previous record of $17,000, which was paid out earlier this month for a prior release of Chrome.

Do bug bounties work? Google seems to think so. Based on the success of its cash-for-Chrome-flaws rewards program, Google last year extended the bug bounty program to cover any of its Web applications that handle sensitive user data.

Arguably, bug bounties socialize coordinated disclosure policies (previously known as "responsible disclosure") by giving security researchers incentives--cash, recognition--to help vendors patch bugs in their products.

Interestingly, Google's public disclosure of bugs discovered by its own employees isn't an industry standard practice. Notably, many vendors forego assigning a CVE identifier--referring to the widely used list of common vulnerabilities and exposures maintained by MITRE. According to the CVE website, the list "aims to provide common names for publicly known problems," in part to make it easier to share information about any given vulnerability.

In a blog post, Carsten Eiram, chief security specialist at vulnerability information provider Secunia, said that companies should always disclose bugs they've found, rather than performing a "silent fix," or in Microsoft-speak, treating it as a "variant," that gets patched but not detailed publicly.

"A software vendor should never silently fix vulnerabilities regardless of these being internally discovered or not; it is unethical and a disservice to customers," he said. "Vulnerability fixes should be clearly listed and, as such, become public and should be assigned a CVE identifier. Any public vulnerability should be assigned a CVE and all vulnerabilities should be made public."

He said that whenever MITRE becomes aware of a bug, it will assign it a CVE, regardless of whether or not the vendor has acknowledged the flaw. "This fact debunks the statement that there is no need for a software vendor to assign a CVE for an internally discovered vulnerability or similar," he said.

Eiram's comments came in response to a recent blog post from Brad Arkin, senior director of product security and privacy at Adobe. Arkin was responding to criticism that Adobe was undercounting the number of vulnerabilities discovered in its products. According to Arkin, "any bug identified by Adobe engineers and resolved as part of the Adobe Secure Product Lifecycle (SPLC) is not assigned a CVE."

At a full-day virtual event, InformationWeek and Dark Reading editors will talk with security experts about the causes and mistakes that lead to security breaches, both from the technology perspective and from the people perspective. It happens Aug. 25. Register now.