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

171–180 of 195 posts

Re: Turn Dependabot off

#171

Post by missingdays »

madarcho wrote: post #147
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!

So, CodeQL found a vulnerability in your code, you avoided the warning by adding an intermediate variable (but ignored the vulnerability), and you are frustrated with CodeQL, not the person who added this variable?

Re: Turn Dependabot off

#172

Post by LawnGnome »

conradludgate wrote: post #16
samhclark wrote: post #2

This makes sense to me. I guess I'll start hunting for the equivalent of `govulncheck` for Rust/Cargo. Separately, I love the idea of the `geomys/sandboxed-step` action, but I've got such an aversion to use anyone else's actions, besides the first-party `actions/*` ones. I'll give sandboxed-step a look, sounds like it would be a nice thing to keep in my toolbox.

https://rustsec.org/

Although, unfortunately, not all RustSec advisories include function-level vulnerability metadata in practice.

Re: Turn Dependabot off

#173

Post by mwcz »

missingdays wrote: post #171
madarcho wrote: post #147

Earlier quoted context omitted.

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!

So, CodeQL found a vulnerability in your code, you avoided the warning by adding an intermediate variable (but ignored the vulnerability), and you are frustrated with CodeQL, not the person who added this variable?

If I read it correctly, the comment suggesting the intermediate variable was from CodeQL itself.

Re: Turn Dependabot off

#174

Post by LawnGnome »

samhclark wrote: post #2

This makes sense to me. I guess I'll start hunting for the equivalent of `govulncheck` for Rust/Cargo. Separately, I love the idea of the `geomys/sandboxed-step` action, but I've got such an aversion to use anyone else's actions, besides the first-party `actions/*` ones. I'll give sandboxed-step a look, sounds like it would be a nice thing to keep in my toolbox.

I was actually working on this last week, funnily enough. I've been working on a capability analysis tool for Rust, and if you're already generating a call graph via static analysis, taking that and matching it against the function-level vulnerability data that exists in RustSec isn't that hard.

Hopefully I'll have something out next week.

Re: Turn Dependabot off

#175

Post by UncleMeat »

maweki wrote: post #131
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.…

> it is inherently resistant to false positives By Rice's Theorem, I somehow doubt that.

Rice's Thm just says that you can't have a sound and complete static analysis. You can happily have one or the other.

Re: Turn Dependabot off

#176

Post by staticassertion »

1718627440 wrote: post #128
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.

If availability is a security concern, than yes DoS is a security concern, but only in so far as all other bugs that limit availability are too. It is not a security concern per se, regardless of whether availability is a security concern. We don't treat every bug as a security issue . Well, the Linux Kernel project actually does.

The linux kernel does the opposite, they do not believe in security vulnerabilities. That's why if you mention "security" in a patch, Linus will reject it.

Re: Turn Dependabot off

#177

Post by SAI_Peregrinus »

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 DoS is a vulnerability, then bad UX is also a vulnerability because it's functionally a DoS if it's bad enough. If users can't use the software it doesn't matter whether they can't because of an attacker or because of the software's inherent unusability.

Re: Turn Dependabot off

#178

Post by 3form »

This reminds me that the vulnerability scanner at my company flagged every version of pandas because it has some function in the API that allows to run some equivalent of eval. Thankfully I have the ability to issue a waiver with "does not apply".

Re: Turn Dependabot off

#179

Post by notepad0x90 »

I really think the developer community needs to learn the age-old skill of ignoring things. Don't treat things like dependabot, PRs,stars, issues,etc.. as a metric or quantifier of how good of a job you're doing with your code. Forget that social-drama nonsense.

I think the bigger problem is that Github is being treated as a quasi-social-media, and these things are being viewed as a "thumbs down" or "dislike" (and vice versa). Unless you have an SLA with someone, you don't have to meet any numbers, just do your best when you feel like it, and drive your project best way you think. Just don't be a dick to people about it, or react to these social-media metrics by lashing out against your users or supporters (not claiming that in this case!).

Re: Turn Dependabot off

#180

Post by notepad0x90 »

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

Agreed, codeql has been amazing. But it's important to not replace type checkers and linters with it. it complements them, it doesn't replace them.

Certain languages don't have enough "rules" (forgot the term) either. This is the only open/free SAST I know of, if there are others I'd be interested as well.

My hope+dream is for Linux distros to require checks like this to pass for anything they admit to their repo.

Post reply on HN