| ▲ | mirashii 8 hours ago | |||||||||||||||||||||||||||||||
> Is there an equivalent to govulncheck for say NPM or Python? There never could be, these languages are simply too dynamic. | ||||||||||||||||||||||||||||||||
| ▲ | woodruffw 7 hours ago | parent | next [-] | |||||||||||||||||||||||||||||||
In practice this isn’t as big of a hurdle as you might expect: Python is fundamentally dynamic, but most non-obfuscated Python is essentially static in terms of callgraph/reachability. That means that “this specific API is vulnerable” is something you can almost always pinpoint usage for in real Python codebases. The bigger problem is actually encoding vulnerable API information (not just vulnerable package ranges) in a way that’s useful and efficient to query. (Source: I maintain pip-audit, where this has been a long-standing feature request. We’re still mostly in a place of lacking good metadata from vulnerability feeds to enable it.) | ||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||
| ▲ | danudey 7 hours ago | parent | prev | next [-] | |||||||||||||||||||||||||||||||
With type hints it's possible for code to assert down the possibilities from "who knows what's what" to "assuming these type hints are correct, this function is never called"; not perfect (until we can statically assert that type hints are correct, which maybe we can idk) but still a pretty good step. | ||||||||||||||||||||||||||||||||
| ▲ | robszumski 8 hours ago | parent | prev [-] | |||||||||||||||||||||||||||||||
I commented elsewhere but our team built a custom static analysis engine for JS/TS specifically for the dep update use-case. It was hard, had to do synthetic execution, understands all the crazy remapping and reexporting you can do, etc. Even then it’s hard to penetrate a complex Express app due to how the tree is built up. | ||||||||||||||||||||||||||||||||