Hacker News Reader

Comment by SamuelAdams | Hacker News Reader

What’s nice about Dependabot is that it works across multiple languages and platforms. Is there an equivalent to govulncheck for say NPM or Python?

View on HN

> Is there an equivalent to govulncheck for say NPM or Python?

There never could be, these languages are simply too dynamic.

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.

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.)

The thing is that almost always isn't good enough. If it can't prove it, then a human has to be put back in the loop to verify and assert, and on sensitive timelines when you have regulatory requirements on time to acknowledge and resolve CVEs in dependencies.

Sure, but I think the useful question is whether it’s good enough for the median Python codebase. I see the story as similar to that of static typing in Python; Python’s actual types are dynamic and impossible to represent statically with perfect fidelity, but empirically static typing for Python has been very successful. This is because the actual exercised space is much smaller than the set of all valid Python programs.

The imports themselves may be dynamic. I once did a little review of dependencies in a venv that had everything to run pytorch llama. The number of imports gated by control flow or having a non-constant dependency was nontrivial.

Imports gated by control flow aren’t a huge obstacle, since they’re still statically observable. But yeah, imports that are fully dynamic i.e. use importlib or other import machinery blow a hole in this.

Idiomatic Python often branches on getattr to implement the interface and that is really hard to analyze from the outside.

I wouldn’t say that’s particularly idiomatic in modern Python. But even when it occurs, it’s not the end of the world: if it’s a computed getattr, you consider the parent object tainted for the purpose of reachability. This is less precise, but it’s equivalent to what the programmer has expressed (and is still more precise than flagging the entire codebase as vulnerable because it uses a dependency.)

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.

It's definitely possible. Author publishes a list of vulnerable symbols, and if these symbols have no use, your module is not vulnerable. Test coverage analysis tools have been doing such analysis for ages.

For python maybe pip-audit, and perhaps bandit for a little extra?

It doesn't have the code tracing ability that my sibling is referring to, but it's better than nothing.

Reply on news.ycombinator.com