Re: Lots of questions
* What is a "vulnerability database" and why do we need multiple ones? What's the difference between this and the list of vulnerabilities that CERT maintains?
CERT/CC maintains the CVE registry and database, and CVEs themselves are generally pretty short on technical information. The actual vulnerability database, in the US, is the NVD, maintained by NIST. Other organizations maintain their own mirrors, often with additional information.
I think most IT security professionals would agree that the CERT/CC CVE registry is not sufficient as a vulnerability database. It's useful, but it's far from the only one that I use, and the same is true of all the other IT security people I know.
* "A notification system for the actual discovery of vulnerabilities." - WTF? Isn't that CERT?
Vulnerabilities are often published well before they have a CVE assigned, or at least before it's updated with details. Many of the vulnerabilities in the NVD go for months or years without actionable information.
And because of the requirements of the CVE program (e.g. needing a CNA), some open-source projects don't use CVEs.
* "That no changes are made to critical open-source software" - who determines "critical software"?
Yeah, I don't see how this one is going to fly, for a number of reasons. Also, while I don't want to subscribe to tu quoque, the Google pot is talking some smack about the open-source kettle here.
* "an attested build system" means "a Google build system" right?
I haven't read the blog post, but no, not necessarily. There are some pretty clever proposals out there for attested build systems, such as CHAINIAC.
CHAINIAC isn't something a project could just drop into its existing build process; it's complicated even in theory (though if you're comfortable with things like general Nagle DAGs, not particularly complicated) and there are scalability problems, particularly around the code reviews (though I think that's solvable). And, of course, it's not perfect; there's no such thing as perfect security. But it's an example of how attested builds could be done, and how they'd prune a lot of the software-supply-chain attack tree.
Should this be at the top of the priority list for software-security issues we need to address? That's a separate question. Supply chain security is a big problem, but there are a lot of big problems in software security. Hell, if we could just get more of the prominent open-source projects to regularly run static and dynamic analysis I'd be a lot happier.