4 ms·

If only it was language-independent I would consider it. Reinventing supply chain and vulnerability management for each language... not a good use of our time.

klysm 4y ago
It doesn't seem possible to implement that in a language agnostic way. How do you propose doing such a thing?
- teraflop 4y ago
  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?
  - tgv 4y ago
    And then clamp the output to generate vulnerabilities? Could be worth a shot.
  - klysm 4y ago
    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.
    - haneefmubarak 4y ago
      Graph Neural Networks! https://distill.pub/2021/gnn-intro/ 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
- goodpoint 4y ago
  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.
  - klysm 4y ago
    > 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.
    - goodpoint 4y ago
      > 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.
      - klysm 4y ago
        I mean language agnostic vuln management that’s capable of marking a particular subset of functionality as vulnerable like this is.
politician 4y ago
Is it even technically possible to do (edit: useful) vulnerability analysis in a pure black box configuration?
- a1369209993 4y ago
  Sure: it's called "fuzz testing".
psanford 4y ago
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.
- goodpoint 4y ago
  > 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.
throwaway894345 4y ago
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.

klysm 4y ago

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

teraflop 4y ago
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?
- tgv 4y ago
  And then clamp the output to generate vulnerabilities? Could be worth a shot.
- klysm 4y ago
  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.
  - haneefmubarak 4y ago
    Graph Neural Networks! https://distill.pub/2021/gnn-intro/ 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
goodpoint 4y ago
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.
- klysm 4y ago
  > 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.
  - goodpoint 4y ago
    > 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.
    - klysm 4y ago
      I mean language agnostic vuln management that’s capable of marking a particular subset of functionality as vulnerable like this is.

politician 4y ago

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

a1369209993 4y ago
Sure: it's called "fuzz testing".

psanford 4y ago

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.

goodpoint 4y ago
> 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.

throwaway894345 4y ago

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.