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

101–110 of 195 posts

Re: Turn Dependabot off

#101

Post by vasco »

jpollock wrote: post #38
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…

The severity of the DoS depends on the system being attacked, and how it is configured to behave on failure. If the system is configured to "fail open", and it's something validating access (say anti-fraud), then the DoS becomes a fraud hole and profitable to exploit. Once discovered, this runs away _really_ quickly. Treating DoS as affecting availability converts the issue into a "do I want to spend $X from a shaked…

> Treating DoS as affecting availability converts the issue into a "do I want to spend $X from a shakedown, or $Y to avoid being shaken down in the first place?"

> Then, "what happens when people find out I pay out on shakedowns?"

What do you mean? You pay to someone else than who did the DoS. You pay your way out of a DoS by throwing more resources at the problem, both in raw capacity and in network blocking capabilities. So how is that incentivising the attacker? Or did you mean some literal blackmailing??

Re: Turn Dependabot off

#102

Post by inejge »

bandrami wrote: post #88
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?

It's in the library you're using, and you're not using all of it. I've had that exact situation: a dependency was vulnerable in a very specific set of circumstances which never occurred in my usage, but it got flagged by Dependabot and I received a couple of unnecessary issues.

Re: Turn Dependabot off

#103

Post by chii »

unshavedyak wrote: post #34
staticassertion wrote: post #33

Earlier quoted context omitted.

Part of the problem is that customers will scan your code with these tools and they won't accept "we never call that function" as an answer (and maybe that's rational if they can't verify that that's true). This is where actual security starts to really diverge from the practices we've developed in the name of security.

Would be neat if the call graph could be asserted easily.. As you could not only validate what vulnerabilities you are / aren't exposed to, but also choose to blacklist some API calls as a form of mitigation. Ensuring you don't accidentally start using something that's proven unsafe.

but then if you could assert the call graph (easily, or even provably correctly), then why not just cull the unused code that led to vulnerability in the first place?

Re: Turn Dependabot off

#104

Post by otabdeveloper4 »

staticassertion wrote: post #47
jpollock wrote: post #38

Earlier quoted context omitted.

The severity of the DoS depends on the system being attacked, and how it is configured to behave on failure. If the system is configured to "fail open", and it's something validating access (say anti-fraud), then the DoS becomes a fraud hole and profitable to exploit. Once discovered, this runs away _really_ quickly. Treating DoS as affecting availability converts the issue into a "do I want to spend $X from a shaked…

If the system "fails open" then it's not a DoS, it's a privilege escalation. What you're describing here is just a matter of threat modeling, which is up to you to perform and not a matter for CVEs. CVEs are local properties, and DoS does not deserve to be a local property that we issue CVEs for.

You're making too much sense for a computer security specialist.

Re: Turn Dependabot off

#106

Post by curtisf »

tracker1 wrote: post #24

I kind of wish Dependabot was just another tab you can see when you have contributor access for a repository. The emails are annoying and I mostly filter, but I also don't want a bunch of stale PRs sitting around either... I mean it's useful, but would prefer if it was limited to just the instances where I want to work on these kinds of issues for a couple hours across a few repositories.

Isn't it?

You can have Dependabot enabled, but turn off automatic PRs. You can then manually generate a PR for an auto-fixable issue if you want, or just do the fixes yourself and watch the issue number shrink.

Re: Turn Dependabot off

#107

Post by p1nkpineapple »

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 to chainguard/docker hardened images etc)

Re: Turn Dependabot off

#108

Post by jayanmn »

bawolff wrote: post #54
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…

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.

Our top management has zero interest in context. There is a chart , that must not have red items.

Security team cannot explain attach surface. In the end it is binary. Fix it or take the blame

Re: Turn Dependabot off

#109

Post by maciuz »

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.

Re: Turn Dependabot off

#110

Post by silverwind »

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.

ReDoS is a bug in the regex engine. Still, V8 etc. seem to refuse to provide a ReDoS-safe regex engine by default.
Post reply on HN