Strong disagree.

Every "generic" vulnerability scanner still needs some language specific knowledge for how to determine what is an included dependency. The better you want to suppress false positives, the more in-depth knowledge the tool will need about each language/runtime.

The end result of this is that all the existing generic scanners just use least common denominator heuristics for determining vulnerable dependencies (i.e. just look at the lock file).

For large teams, this can be a huge waste of time patching vulnerabilities that don't actually apply to your code just because the scanning tool is too stupid to know better.

I'll take Govulncheck (and similar tools for other languages) any day over the mediocre generic tools.

> The end result of this is that all the existing generic scanners just use least common denominator heuristics

Wrong. You can have specialized backends and language-agnostic everything-else.

It doesn't seem possible to implement that in a language agnostic way. How do you propose doing such a thing?

Very simple: implement language-specific static analysis backends and a general frontend and vuln management.

Just like every Linux distribution does distributes packages and manages security in a language-agnostic way. Nothing new.

Amazing how people here dismissed my point by downvoting and providing no reasoning.

> language-specific static backends

I guess it sounded like you meant a general solution that wasn’t language specific. I’m still not sure if there’s an abstraction you could use to make language aspects marked as vulnerable - the semantics between languages are just so varied.

Anyway we need the language specific ones first.

> Anyway we need the language specific ones first.

No, we have language-agnostic vuln management since decades and a good tool could use a fall back to the traditional method when a language-specific backend is not available.

I mean language agnostic vuln management that’s capable of marking a particular subset of functionality as vulnerable like this is.

Let's train a neural network to take source code in an arbitrary language as input, and produce a call graph as output. What could go wrong?

Side-note: how do you make a nn output a graph topology? I'm having a hard time imagining how to make a matrix represent that.

Graph Neural Networks! https://distill.pub/2021/gnn-intro/

In a nutshell, you perform NN operations on the nodes and edges of the graph and then send updates across the graph

And then clamp the output to generate vulnerabilities? Could be worth a shot.

Until we can figure out how to translate semantics across languages, we have to reinvent almost everything for each language. We can abstract out some things, but not others. As far as "a good use of our time", the alternative is "no vulnerability scanning" or "package level vulnerability scanning" which probably waste more time or expose more risk for most organizations.

Is it even technically possible to do (edit: useful) vulnerability analysis in a pure black box configuration?

Sure: it's called "fuzz testing".