I find dependabot very useful. It's drives me insane and reminds me of the importance of keeping dependencies to an absolute minimum.
Turn Dependabot off
41–50 of 195 posts
Re: Turn Dependabot off
#42We’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…
Are y'all aware your agent's name clashes with an established and rather popular streaming bot/tool, https://fossabot.com ?
Re: Turn Dependabot off
#43govulncheck is the much better answer and we use it.
We also let renovate[bot] (similar to dependabot) merge non-major dep updates if tests pass. I hardly notice when deps have small updates.
https://github.com/search?q=org%3Amoov-io+is%3Apr+is%3Amerge...
Re: Turn Dependabot off
#44Is there an equivalent for the JS ecosystem? If not, having Dependabot update dependencies automatically after a cooldown still seems like a better alernative, since you are likely to never update dependencies at all if it's not automatic.
Too bad dependabot cooldowns are brain-dead. If you set a cooldown for one week, and your dependency can't get their act together and makes a release daily, it'll start making PRs for the first (oldest) release in the series after a week even though there's nothing cool about the release cadence.
The cooldown is to allow vulnerabilities to be discovered. So auto update on passing tests, which should include an npm audit check.
Re: Turn Dependabot off
#45What’s nice about Dependabot is that it works across multiple languages and platforms. Is there an equivalent to govulncheck for say NPM or Python?
For python maybe pip-audit, and perhaps bandit for a little extra?
It doesn't have the code tracing ability that my sibling is referring to, but it's better than nothing.
Re: Turn Dependabot off
#46What’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.
I commented elsewhere but our team built a custom static analysis engine for JS/TS specifically for the dep update use-case. It was hard, had to do synthetic execution, understands all the crazy remapping and reexporting you can do, etc. Even then it’s hard to penetrate a complex Express app due to how the tree is built up.
Re: Turn Dependabot off
#47Earlier 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…
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.
Re: Turn Dependabot off
#48Earlier 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…
> If the system is configured to "fail open", and it's something validating access (say anti-fraud),
The problem here isn't the DoS, it's the fail open design.
Re: Turn Dependabot off
#49I think this is pretty good advice. I find Dependabot useful for managing scheduled dependency bumps (which in turn is useful for sussing out API changes, including unintended semver breakages from upstreams), but Dependabot’s built-in vulnerability scanning is strictly worse than just about every ecosystem’s own built-in solution.
Re: Turn Dependabot off
#50What’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.
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) in a way that’s useful and efficient to query.
(Source: I maintain pip-audit, where this has been a long-standing feature request. We’re still mostly in a place of lacking good metadata from vulnerability feeds to enable it.)