Hacker News new | ask | show | jobs
by jacobevelyn 1785 days ago
Thanks for all the hard work, greysteil! Long-time Dependabot user here and a big fan (currently in the throes of updating many repos to GitHub-native Dependabot).

I've reported all this in the past, but since we're giving feedback in this thread, some big pain points for us are:

1. The lack of a way to view all Dependabot security alerts/security PRs (across repos) in one place. With Old Dependabot, we could do a GitHub Issues search like `is:open is:pr label:security org:<our-org>` and see them all, and actually built quite a lot of automation around PRs with the `security` label. But New Dependabot has no way to configure security PRs to get the `security` label, so it's easy to miss vulnerabilities when you have two dozen repos, and our automation no longer works. :/

2. Dependabot reporting `No security update is needed as <dependency> is no longer vulnerable` when in fact there are multiple versions of the dependency, including vulnerable ones, in our yarn.lock file. (Webpack has a lot of transitive dependencies!)

3. Dependabot can't update a vulnerable version of, say, rails, because rails requires the same version of activerecord, even though these are essentially the same project. (I get the sense this is being worked on as "grouped dependency updates"?)

P.S. Just wanted to clarify: feedback is love. I wouldn't be writing this if we didn't find Dependabot valuable (Old Dependabot was actually the reason we moved to GitHub years ago!).

1 comments

Thanks for the feedback Jacob, and for all the support over the years. I'm going to pass those three on to the Dependabot team, who are best placed to think through solutions.

(FWIW, I'm sure we can think of something to fix (1) which balances security and usability - it just needs some thinking. (2) sounds like a bug to me - I'm sure the team will want to look at that. And (3) is a tricky case where Dependabot's Ruby logic needs to be able to unlock a dependency's "parent" or peers in order to make security fix (e.g., rails in the case where the vulnerability is in activerecord). Entirely possible but hard!)