My only feedback would be that I'm not a server-side JS developer, so I don't feel it will have that much signal to noise. It's JS only, and the only JS I do is frontend and a little tooling.

In general, I find that for JS that basically gets compiled at build time and used statically on a site, or things like linters that don't do any networking and are run only in dev/CI, the scope for vulns is pretty low. It's mostly just self-denial-of-service, because it's standard practice to not trust the client for anything anyway, so all the canonical security is server-side.

There's obviously a vector for packages that have been backdoored and taken over by an attacker, but I'm not sure having that in my editor would help because I'd have to have the file open to see it, vs getting a notification about it from GitHub security (or Snyk's service I guess?). For new packages I'm adding, I would be researching it on NPM (for JS) anyway.

I mostly write backend Python, and I'd probably use it for that. The fact that there's a more useful notion of a vuln means I want to see them more (it's more of a spectrum rather than safe vs backdoored in the frontend case).