Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Turn Dependabot off

words.filippo.io

Post reply on HN
Print view View original

91–100 of 195 posts

Re: Turn Dependabot off

#91

Post by caned »

woodruffw wrote: post #50
mirashii wrote: post #25

Earlier quoted context omitted.

> Is there an equivalent to govulncheck for say NPM or Python? There never could be, these languages are simply too dynamic.

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) i…

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.

Re: Turn Dependabot off

#92

Post by KPGv2 »

This is a symptom of JS culture, where people believe you must at all times and in all places have THE latest version of every library, and you MUST NOT wait more than a day to update your entire codebase accordingly.

Re: Turn Dependabot off

#93

Post by lazyasciiart »

jpollock wrote: post #52
michaelt wrote: post #48

Earlier quoted context omitted.

> If the system is configured to "fail open", and it's something validating access (say anti-fraud), The problem here isn't the DoS, it's the fail open design.

If the majority of your customers are good, failing closed will cost more than the fraud during the anti-fraud system's downtime.

Until any bad customer learns about the fail-open.

Re: Turn Dependabot off

#94

Post by lazyasciiart »

KPGv2 wrote: post #92

This is a symptom of JS culture, where people believe you must at all times and in all places have THE latest version of every library, and you MUST NOT wait more than a day to update your entire codebase accordingly.

This blog post is entirely about Go, and doesn’t mention JS at all.

Re: Turn Dependabot off

#95

Post by [deleted] »

robszumski wrote: post #22

We’ve built a modern dependabot (or works with it) agent: fossabot analyzes your app code to know how you use your dependencies then delivers a custom safe/needs review verdict per upgrade or packages groups of safe upgrades together to make more strategic jumps. We can also fix breaking changes because the agents context is so complete. https://fossa.com/products/fossabot/ We have some of the best JS/TS analysis out…

[deleted]

Re: Turn Dependabot off

#96

Post by bigfatkitten »

staticassertion wrote: post #60
bawolff wrote: post #54

Earlier quoted context omitted.

The real problem is that we treat vulnerabilities as binary without nuance. Whether a security vulnerability is an issue depends on context. This comes up a lot for DoS (and especially ReDoS) as it is comparatively rare for it to be real, but it can happen for any vulnerability type.

I don't really agree. Maybe I do, but I probably have mixed feelings about that at least. DoS is distinct because it's only considered a "security" issue due to arbitrary conversations that happened decades ago. There's simply not a good justification today for it. If you care about DoS, you care about almost every bug, and this is something for your team to consider for availability. That is distinct from, say, remo…

There are good reasons for that history which are still relevant today.

We have decades of history of memory corruption bugs that were initially thought to only result in a DoS, that with a little bit of work on the part of exploit developers have turned into reliable RCE.

Re: Turn Dependabot off

#97

Post by woodruffw »

caned wrote: post #91
woodruffw wrote: post #50

Earlier quoted context omitted.

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) i…

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.

Re: Turn Dependabot off

#98

Post by woodruffw »

mirashii wrote: post #81
woodruffw wrote: post #50

Earlier quoted context omitted.

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) i…

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.

Re: Turn Dependabot off

#99

Post by kortilla »

staticassertion wrote: post #31
nfm wrote: post #17

The number of ReDoS vulnerabilities we see in Dependabot alerts for NPM packages we’re only using in client code is absurd. I’d love a fix for this that was aware of whether the package is running on our backend or not. Client side ReDoS is not relevant to us at all.

TBH I Think that DoS needs to stop being considered a vulnerability. It's an availability concern, and availability, despite being a part of CIA, is really more of a principle for security rather than the domain of security. In practice, availability is far better categorized as an operational or engineering concern than a security concern and it does far, far more harm to categorize DoS as a security conern than it…

If I can cause a server to not serve requests to anyone else in the world by sending a well crafted set of bytes, that’s absolutely a vulnerability because it can completely disable critical systems.

If availability isn’t part of CIA then a literal brick fulfills the requirements of security and the entire practice of secure systems is pointless.

Re: Turn Dependabot off

#100

Post by insin »

NewJazz wrote: post #75
MattIPv4 wrote: post #42

Earlier quoted context omitted.

Are y'all aware your agent's name clashes with an established and rather popular streaming bot/tool, https://fossabot.com ?

Spitballing some alt names Fossadep Fossacheck Fossasafe

Fossamatta

Fossahappenin

Fossagoinon

Post reply on HN