Both Semgrep Supply Chain and govulncheck (AFAIK) are doing this work manually, for now. It would indeed be nice if the vulnerability reporting process had a way to provide metadata, but there's no real consensus on what format that data would take. We take advantage of the fact that Semgrep makes it much easier than other commercial tools (or even most linters) to write a rule quickly.
The good news is there's a natural statistical power distribution: most alerts come from few vulnerabilities in the most popular (and often large) libraries, so you get significant lift just by writing rules starting with libraries.
(Disclaimer: I work at Phylum, which has a very similar capability)
Not all of it has to be manual. Some vulnerabilities come with enough information to deduce vulnerability reachability with a high degree of confidence with some slightly clever automation.
Not all vulns come with this information, but as time goes on the percentage that do is increasing. I'm very optimistic that automation + a bit of human curation can drastically improve the S/N for open source library vulns.
A nice property of this is: you only have to solve it once per vuln. If you look at the total set of vulns (and temporarily ignore super old C stuff) it's not insurmountable at all.
Since security vulnerability alerts are already created and processed manually (e.g., every Dependabot alert is triggered by some Github employee who imported the right data into their system and clicked "send" on it), adding an extra step to create the right rules doesn't seem impossibly resource intensive. Certainly much more time is spent "manually" processing even easier-to-automate things in other parts of the economy, like payments reconciliation (https://keshikomisimulator.com/)
From https://go.dev/security/vuln/: "A vulnerability database is populated with reports using information from the data pipeline. All reports in the database are reviewed and curated by the Go Security team."
I would imagine that's what Semgrep is doing as well. You're paying for the analysis; the code is the easy part.