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

111–120 of 195 posts

Re: Turn Dependabot off

#111

Post by silverwind »

ImJasonH wrote: post #10

Govulncheck is one of the Go ecosystem's best features, and that's saying something! I made a GitHub action that alerts if a PR adds a vulnerable call, which I think pairs nicely with the advice to only actually fix vulnerable calls. https://github.com/imjasonh/govulncheck-action You can also just run the stock tool in your GHA, but I liked being able to get annotations and comments in the PR. Incidentally, the repo…

Govulncheck is good, but not without false-positives. Sometimes it raises "unfixable" vulnerabilities and there's still no way to exclude vulnerabilties by CVE number.

Re: Turn Dependabot off

#112

Post by silverwind »

mirashii wrote: post #25
SamuelAdams wrote: post #14

What’s nice about Dependabot is that it works across multiple languages and platforms. Is there an equivalent to govulncheck for say NPM or Python?

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

It's definitely possible. Author publishes a list of vulnerable symbols, and if these symbols have no use, your module is not vulnerable. Test coverage analysis tools have been doing such analysis for ages.

Re: Turn Dependabot off

#113

Post by Chris_Newton »

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.

Unlike those naïve tools, CodeQL seems to perform a real tracing analysis through the code, so its report doesn’t just say you have user-provided data being used dangerously, it shows you a complete, step-by-step path through the code that connects the input to the dangerous usage. This provides useful, actionable information to assess and fix real vulnerabilities, and it is inherently resistant to false positives.

Presumably there is still a possibility of false negatives with this approach, particularly with more dynamic languages like Python where you could surely write code that is obfuscated enough to avoid detection by the tracing analysis. However, most of us don’t intentionally do that, and it’s still useful to find the rest of the issues even if the results aren’t perfect and 100% complete.

Re: Turn Dependabot off

#114

Post by Gigachad »

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.

It’s easier to just update the package and not have to worry.

Re: Turn Dependabot off

#115

Post by mseepgood »

chii wrote: post #103
unshavedyak wrote: post #34

Earlier quoted context omitted.

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?

With a statically compiled language it is usually culled through dead-code elimination (DCE), and with static linking you don’t ship entire libraries.

Re: Turn Dependabot off

#116

Post by chii »

mseepgood wrote: post #115
chii wrote: post #103

Earlier quoted context omitted.

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?

With a statically compiled language it is usually culled through dead-code elimination (DCE), and with static linking you don’t ship entire libraries.

The technology to cull code can work for dynamic languages too, even tho it does get difficult sometimes (google closure compiler[1] does dead code elimination for js, for example). It's just that most dynamic language users don't make the attempt (and you end up with this dependabot giving you thousands of false positives due to the deep dependency tree).

[1]https://github.com/google/closure-compiler

Re: Turn Dependabot off

#117

Post by jpollock »

vasco wrote: post #101
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…

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

Literal blackmailing, same as ransomware.

Re: Turn Dependabot off

#118

Post by varispeed »

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

Re: Turn Dependabot off

#119

Post by fweimer »

staticassertion wrote: post #33
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…

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.

There is the VEX justification Vulnerable_code_not_in_execute_path. But it's an application-level assertion. I don't think there's a standardized mechanism that can describe this at the component level, from which the application-level assertion could be synthesized. Standardized vulnerability metadata is per component, not per component-to-component relationship. So it's just easier to fix vulnerability.

But I don't quite understand what Dependabot is doing for Go specifically. The vulnerability goes away without source code changes if the dependency is updated from version 1.1.0 to 1.1.1. So anyone building the software (producing an application binary) could just do that, and the intermediate packages would not have to change at all. But it doesn't seem like the standard Go toolchain automates this.

Re: Turn Dependabot off

#120

Post by ImJasonH »

silverwind wrote: post #111
ImJasonH wrote: post #10

Govulncheck is one of the Go ecosystem's best features, and that's saying something! I made a GitHub action that alerts if a PR adds a vulnerable call, which I think pairs nicely with the advice to only actually fix vulnerable calls. https://github.com/imjasonh/govulncheck-action You can also just run the stock tool in your GHA, but I liked being able to get annotations and comments in the PR. Incidentally, the repo…

Govulncheck is good, but not without false-positives. Sometimes it raises "unfixable" vulnerabilities and there's still no way to exclude vulnerabilties by CVE number.

I haven't experienced that (that I know of), do you have an example handy?
Post reply on HN