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

141–150 of 195 posts

Re: Turn Dependabot off

#141

Post by SahAssar »

maciuz wrote: post #109
p1nkpineapple wrote: post #107

we struggle with a similar problem at my workplace - vuln alerts from GCP container image scans put a ton of noise into Vanta which screams bloody murder at CVEs in base images which we A) can't fix, and B) aren't relevant as they're not on the hot path (often some random dependency that we don't use in our app). Are there any tools for handling these kind of CVEs contextually? (Besides migrating all our base images…

I'm working at a medium sized SaaS vendor. We've been using Aikido Code which tries to filter vulnerability impact using AI. Results are generally positive, though we are still struggling with keeping the amount of CVEs down, due to the size of our code bases and the amount of dependencies.

I'd be weary to trust AI with something like that, especially if I had to assert to a third party that we absolutely do not have a vulnerability.

Re: Turn Dependabot off

#142

Post by Chris_Newton »

varispeed wrote: post #118
Chris_Newton wrote: post #113

Dependabot has some value IME, but all naïve tools that only check software and version numbers against a vulnerability database tend to be noisy if they don’t then do something else to determine whether your code is actually exposed to a matching vulnerability. One security checking tool that has genuinely impressed me recently is CodeQL. If you’re using GitHub, you can run this as part of GitHub Advanced Security.…

Bumping version of dependencies doesn't guarantee any improved safety as new versions can introduce security issues (otherwise we wouldn't have a need of patching old versions that used to be new).

If you replace a dependency that has a known vulnerability with a different dependency that does not, surely that is objectively an improvement in at least that specific respect? Of course we can’t guarantee that it didn’t introduce some other problem as well, but not fixing known problems because of hypothetical unknown problems that might or might not exist doesn’t seem like a great strategy.

Re: Turn Dependabot off

#143

Post by bregma »

bandrami wrote: post #85
technion wrote: post #82

Earlier quoted context omitted.

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

These are functional safety problems, not security vulnerabilities.

For a product that requires functional safety, CVEs are almost entirely a marketing tool and irrelevant to the technology. Go ahead and classify them as CVEs, it means the sales people can schmooze with their customer purchasing department folks more but it's not going to affect making your airplane fly or you car drive or your cancer treatment treat any more safely.

Re: Turn Dependabot off

#144

Post by staticassertion »

bigfatkitten wrote: post #96
staticassertion wrote: post #60

Earlier quoted context omitted.

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.

I don't believe that's the history here but I could be wrong. The history is that CIA encompasses availability, which it shouldn't.

Regardless, I don't think it matters. If you truly believe your DoS may be a likely privesc etc, label it as those. The system accounts for this. The insanely vast majority of DoS are blatantly not primitives for other exploits.

Re: Turn Dependabot off

#145

Post by TZubiri »

1718627440 wrote: post #127
TZubiri wrote: post #29

Coming from someone with an almost ascetic dependency discipline, I look at some meta-dependencies as an outsider (dependabot, pnpm/yarn, poetry/venv/pipenv, snap/flatpak), a solution to too many dependencies that is yet another dependency, it feels like trying to get out of a hole by digging. I think that for FOSS the F as in Gratis is always going to be the root cause of security conflicts, if developers are not pa…

> for FOSS the F as in Gratis Isn't FOSS a combination of the diverging ideas of "Open Source" and "Free Software"? The "Free" in "Free Software" very much does not mean "Gratis".

Yes, it's a joke. The Free in Free Software is sold as being Free as in Freedom to devs by recruiters of the cause, however the bulk of actual consumers see Free Software as equivalent to Open Source and the defining characteristic for them is Free as in Gratis.

Re: Turn Dependabot off

#146

Post by duskdozer »

FiloSottile wrote: post #19
esafak wrote: post #12

I automate updates with a cooldown, security scanning, and the usual tests. If it passes all that I don't worry about merging it. When something breaks, it is usually because the tests were not good enough, so I fix them. The next step up would be to deploy the update into a canary cluster and observe it for a while. Better that than accrue tech debt. When you update on "your schedule" you still should do all the abo…

For regular updates, because you can minimize but not eliminate risk. As I say in the article that might or might not work for your requirements and practices. For libraries, you also cause compounding churn for your dependents. For security vulnerabilities, I argue that updating might not be enough ! What if your users’ data was compromised? What if your keys should be considered exposed? But the only way to have th…

>For libraries, you also cause compounding churn for your dependents.

This is the thing that I don't really understand but that seems really popular and gaining. The article's section "Test against latest instead of updating" seems like the obvious thing to do, as in, keep a range of compatible versions of dependencies, and only restrict this when necessary, in contrast to deployment- or lockfile-as-requirement which is restricted liberally. Maybe it's just a bigger deal for me because of how disruptive UI changes are.

Re: Turn Dependabot off

#147

Post by madarcho »

Chris_Newton wrote: post #113

Dependabot has some value IME, but all naïve tools that only check software and version numbers against a vulnerability database tend to be noisy if they don’t then do something else to determine whether your code is actually exposed to a matching vulnerability. One security checking tool that has genuinely impressed me recently is CodeQL. If you’re using GitHub, you can run this as part of GitHub Advanced Security.…

CodeQL was a good help on some projects, but more recently, our team has been increasingly frustrated by the thing to the point of turning it off.

The latest drop in the bucket was a comment adding a useless intermediate variable, with the justification being “if you do this, you’ll avoid CodeQL flagging you for the problem”.

Sounds like slight overfitting to the data!

Re: Turn Dependabot off

#148

Post by 1718627440 »

TZubiri wrote: post #145
1718627440 wrote: post #127

Earlier quoted context omitted.

> for FOSS the F as in Gratis Isn't FOSS a combination of the diverging ideas of "Open Source" and "Free Software"? The "Free" in "Free Software" very much does not mean "Gratis".

Yes, it's a joke. The Free in Free Software is sold as being Free as in Freedom to devs by recruiters of the cause, however the bulk of actual consumers see Free Software as equivalent to Open Source and the defining characteristic for them is Free as in Gratis.

Honestly, that whole "free as in X" problem to me seems like an English only problem. As an ESL I perceive "free" to be the adjective to "freedom" by default and the other meaning to be a contraction of "free of charge".

Re: Turn Dependabot off

#149

Post by pornel »

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?

CVSS has some formula, but it's a fundamentally flawed concept. It's a score for the worst possible case, not for a typical case. It's for ass-covering, not for being informative about the real risk.

For every boring API you can imagine someone using it for protecting nuclear launch codes, while having it exposed to arbitrary inputs from the internet. If it's technically possible, even if unrealistically stupid, CVSS treats it the same as being a fact, and we get spam about the sky falling due to ReDoS.

This is made worse by GitHub's vulnerability database being quantity-over-quality dumping ground and absolutely zero intelligence in Dependabot (ironic for a company aggressively inserting AI everywhere else)

Re: Turn Dependabot off

#150

Post by hokkos »

Most CVE now are pure spam without value, all I get is dev dependencies affected by regex that could take too long, scanner should do a better job to differentiate between dependencies and dev dependencies.
Post reply on HN