This sounds like a new name (and possibly more executive support) for what those guys have been doing for years now.
The guys in that article have been working on finding bugs in non-Google products for a little over two years and you can see their past results through the advisory credits they've received at Microsoft and Adobe as well as from open source projects like FFmpeg.
My read of the announcement is that they are now hiring vulnerability researchers to work on arbitrary targets, the way security product companies do to staff their research labs.
Starting back in the 1990s, companies like ISS and McAfee staffed teams of bugfinders to comb through high-profile software for vulnerabilities, and kept score with advisories (and with IDS/IPS signatures and scanner checks for those bugs, which they'd have a semi-proprietary interest in, since they found them). They'd use this to market their expensive products. The researchers generally had a long leash so long as they were (a) looking at software that customers might care about and (b) were actually finding things.
What Google seems to be doing is starting a lab like that, but without the hooks into products and marketing; instead: Google has cash, wants to retain security researchers, and so will throw money at a vulnerability lab run for the common good, partially for the PR win, partially for the knock-on benefits to Google of having lots of good security people, and yes, partially for the good of humanity.
(FWIW: I worked at what I think was the industry's first vulnerability lab, at SNI, which eventually became McAfee's vulnerability team).
... where we discovered (or were at least first to publish) two whole new attack classes, tracked down something like 6 different super expensive security products and got them up in a lab, designed and implemented a new programming language, and succeeded in giving a giant middle finger to surveillance software.
It's the most fun I've had in my whole career.
Not for nothing, but working at a software security consultancy is a close second; you lose the freedom to choose your targets (at least 80% of the time), but the work is the same.
That's fascinating! I'm curious what sort of education and experience you had to land a job like that, do you mind sharing? I'd love to work in a lab like that one day, but I'm not sure what is considered "good enough" to get a career in security rather than just a hobby.
Thank you for doing the crypto challenge by the way. Was a lot of fun, and I'm looking forward to the next set :). Has anyone else finished it in c# yet?
slightly off topic but, like your appsec reading list above, are there any crypto resources you value for someone taking the self learning route into real world crypto?
I've looking into buying Grey Hat Python as more of my job starts to require scripting, but I'm put off by that first review (and overall, the reviews aren't glowing). Interesting that it comes recommended from you, someone whose opinion I respect.
I don't know how long ago your list was made; would you still recommend Grey Hat Python?
I didn't think Grey Hat Python was a great book, but it serves a valuable purpose that I'm not aware of another book supplanting; which is that it shows you that you can use underlying programming to do security-related tasks, instead of being limited to just using tools.
The widest chasm that separates security professionals is the one between those that can only use tools other people provide and those that can write their own tools. And more than just being able to write them, but being able to write them quickly enough to be of use during an engagement (which usually only lasts between 1-3 weeks).
A lot of security testing at the non-entry level is putting together specific tools to accomplish an engagement-specific task. You don't generally spend a lot of time building giant edifices, it's usually lots of small things that you mostly throw away between gigs (minus whatever underlying libraries you favor using as construction components).
In that regard, I think Grey Hat Python is still a good book to introduce you to the idea of using real programming to do hacking, even if you never write a line of Python on an engagement.
I don't think it's an especially great programming book, but it is a great cross-section of the programming tasks you actually do when working in a vulnerability research lab (or software security consultancy, for that matter).
After lightly reading through both books, I think Gray Hat Python is a great book for more advanced security concepts, especially on the reverse engineering and exploit dev side of things, but isn't a very good book for learning Python or programming.
Violent Python on the other hand is a great book for beginners to Python and programming, and it teaches both pretty well, but it only goes into surface level security concepts for the most part.
Gray Hat Python is closer to a Windows API/x86 assembly book than a Python one. Violent Python is a real Python book and mostly covers general information security and network security concepts.
Gray Hat Python is also purely application security. Debugging, reversing, hooking, writing shellcode, exploiting... Violent Python is almost entirely network security, with one chapter on forensics. Exploit dev vs. exploit user.
It depends on your experience level and what you want to actually learn. If someone was brand new to Python, application security, and even programming, I'd recommend reading Violent Python first and then Gray Hat. If someone has more advanced security knowledge and has some decent programming skills already, I'd probably tell them to skip Violent Python.
Or if they wanted to focus on appsec vs. netsec, I'd direct them to one or the other based on that. If you want both, you should definitely read both.
The list author says:
"I had a CISSP book here as a joke, but then realized that someone who clicked "buy whole list" would end up accidentally owning a CISSP book. Far better that they accidentally end up owning David Foster Wallace's most accessible book. The state fair essay in particular, worth the price of admission."
It could also be that their semi-formal third party security team is now a formal team. Previously it was less than a full time project but more than a 20% project for many of Google's vulnerability researchers.
I guess that'd have the same net result though since it's much more feasible to hire for if it's been formalized.
The guys in that article have been working on finding bugs in non-Google products for a little over two years and you can see their past results through the advisory credits they've received at Microsoft and Adobe as well as from open source projects like FFmpeg.
For example see Ben Hawkes on this list of Google CVEs in other companies' products: https://www.google.com/about/appsecurity/research/