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

81–90 of 195 posts

Re: Turn Dependabot off

#81

Post by mirashii »

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

Re: Turn Dependabot off

#82

Post by technion »

Lichtso wrote: post #64
staticassertion wrote: post #31

Earlier quoted context omitted.

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…

> I Think that DoS needs to stop being considered a vulnerability Strongly disagree. While it might not matter much in some / even many domains, it absolutely can be mission critical. Examples are: Guidance and control systems in vehicles and airplanes, industrial processes which need to run uninterrupted, critical infrastructure and medicine / health care.

These redos vulnerabilities always come down to "requires a user input of unbounded length to be passed to a vulnerable regex in JavaScript ". If someone is building a hard real time air plane guidance system they are already not doing this.

I can produce a web server that prints hello world and if you send it enough traffic it will crash. If can put user input into a regex and the response time might go up by 1ms and noone will say its suddenly a valid cve.

Then someone will demonstrate that with a 1mb input string it takes 4ms to respond and claim they've learnt a cve for it. I disagree. If you simply use Web pack youve probably seen a dozen of these where the vulnerable input was inside the Web pack.config.json file. The whole category should go in the bin.

Re: Turn Dependabot off

#83

Post by keyle »

apitman wrote: post #41

I find dependabot very useful. It's drives me insane and reminds me of the importance of keeping dependencies to an absolute minimum.

I agree, I don't have a ton of projects out there though.

Re: Turn Dependabot off

#84

Post by [deleted] »

robszumski wrote: post #30
adverbly wrote: post #23

Earlier quoted context omitted.

Seriously! We also suffer from this. Although in some cases it's due to a Dev dependency. It's crazy how much noise it adds specifically from ReDoS...

Totally hear you on the noise…but we should want to auto-merge vs ignore, no? Given the right tooling of course.

[deleted]

Re: Turn Dependabot off

#85

Post by bandrami »

technion wrote: post #82
Lichtso wrote: post #64

Earlier quoted context omitted.

> I Think that DoS needs to stop being considered a vulnerability Strongly disagree. While it might not matter much in some / even many domains, it absolutely can be mission critical. Examples are: Guidance and control systems in vehicles and airplanes, industrial processes which need to run uninterrupted, critical infrastructure and medicine / health care.

These redos vulnerabilities always come down to "requires a user input of unbounded length to be passed to a vulnerable regex in JavaScript ". If someone is building a hard real time air plane guidance system they are already not doing this. I can produce a web server that prints hello world and if you send it enough traffic it will crash. If can put user input into a regex and the response time might go up by 1ms an…

> If someone is building a hard real time air plane guidance system they are already not doing this.

But if we no longer classed DOSes as vulnerabilities they might

Re: Turn Dependabot off

#86

Post by clickety_clack »

Lichtso wrote: post #64
staticassertion wrote: post #31

Earlier quoted context omitted.

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…

> I Think that DoS needs to stop being considered a vulnerability Strongly disagree. While it might not matter much in some / even many domains, it absolutely can be mission critical. Examples are: Guidance and control systems in vehicles and airplanes, industrial processes which need to run uninterrupted, critical infrastructure and medicine / health care.

I just hate being flagged for rubbish in Vanta that is going to cause us the most minor possible issue with our clients because there’s a slight risk they might not be able to access the site for a couple of hours.

Re: Turn Dependabot off

#87

Post by monkpit »

adverbly wrote: post #23
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.

Seriously! We also suffer from this. Although in some cases it's due to a Dev dependency. It's crazy how much noise it adds specifically from ReDoS...

ReDoS cves in your dev dependencies like playwright that could literally never be exploited, so annoying.

Re: Turn Dependabot off

#88

Post by bandrami »

indiestack wrote: post #32

The govulncheck approach (tracing actual code paths to verify vulnerable functions are called) should be the default for every ecosystem, not just Go. The fundamental problem with Dependabot is that it treats dependency management as a security problem when it's actually a maintenance problem. A vulnerability in a function you never call is not a security issue — it's noise. But Dependabot can't distinguish the two b…

If you never call it why is it there?

Re: Turn Dependabot off

#89

Post by amluto »

12_throw_away wrote: post #71

I'm a little hung up on this part: > These PRs were accompanied by a security alert with a nonsensical, made up CVSS v4 score and by a worrying 73% compatibility score, allegedly based on the breakage the update is causing in the ecosystem. Where did the CVSS score come from exactly? Does dependabot generate CVEs automatically?

I’m kind of curious whether anything is vulnerable to this bug at all. It seems like it depends on calling the offending function incorrectly, which seems about as likely to cause the code using it to unconditionally fail to communicate (and thus have already been fixed) as to fail in a way that’s insecure.

Re: Turn Dependabot off

#90

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]
Post reply on HN