Bringing supply chain security features to the Go community (opens in new tab)

This affects group (team) permissions as well - having to add a new team to multiple repos with specific permissions is a manual slog and hard to audit. Even the expanded permission categories are frequently inadequate - there's no CI focused "Let these users write to the repo and change hooks" permission level - all CI systems that self-manage hooks need full Admin rights.

The other code hosting I actively use is Gerrit, and the ability to hierarchically control what groups have specific permissions on multiple repos is far simpler and easier to use, from an admin perspective.

Please, please, _please_, add organisation scope to github action tokens (GITHUB_TOKEN in actions). It is painful that we have to create a PAT to access packages from within an organisation.

https://github.community/t/github-token-cannot-access-privat...

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

While I empathize with your team regarding their apparent workload, that's only because they (probably) don't control hiring. GitHub isn't a struggling startup; it's not a non-profit; it's a mature, sizeable organization whose owner has over a trillion dollars in assets. If the team is too small to do a job, it's not because you lack personnel, it's GitHub's choice not to do it. You're GitHub, owned by Microsoft; GitHub doesn't care about these issues enough to staff them.

EDIT: Removed something provocative.

They thus also need to be updated together, but I wish one PR was opened to update the dependencies in all projects at once, instead of multiple PRs I to merge.

PS: I think you should highlight dependabot updates on the Security tab in GitHub repo, I thought it was on before (but was actually just the security notices) because dependabot itself is hidden away in Insights -> Dependency graph -> Dependabot which was a bit surprising.

Right now, I have a monorepo with multiple Dockerfiles in subdirectories.

I end up having to add an entire docker block scoped to each directory that has a Dockerfile which is painful. Ideally, I would have a way to specify using */Dockerfile as a way to scan for Docker dependencies.

Also, multi-stage Dockerfile configs seem to confuse Dependabot where it'll submit a pull request to update the "AS build" but not the image to be used for packaging...

I really like the promise/premise of Dependabot, just want it to be easier to use (and edit across multiple repos).

[1] https://github.com/dependabot/feedback/issues/954#issuecomme... and the original issue: https://github.com/dependabot/dependabot-core/issues/1973

And why it doesn't fly: https://github.com/dependabot/dependabot-core/issues/1973#is...

https://news.ycombinator.com/item?id=27761334

Totally agree. The good news is that I think GitHub is in a position to fix this - expect progress in the next 12 months.

One change that's needed here is data for each vulnerability on whether it's ever relevant in development. The advisory database that powers GitHub's security alerts (and npm audit, and NuGet audit) now has a dedicated curation team and is ready to curate more ecosystems and more information.

That data then needs to be hooked up with GitHub's security alerting logic. That shouldn't be too difficult - we already detect whether a dependency is used in development or production, and the team here is growing.

Finally, for this to work we'd need a new UI concept for vulnerabilities you aren't affected by. We're already working on functionality with a very similar requirement (one that tells you whether you're using the vulnerable function within a dependency).

I can't make promises, but I can say that GitHub has an increasing amount of energy. Expect progress :-)

/s (but also, for realsies)

Update: https://github.com/dependabot/dependabot-core/pull/4077

If typing --perl-regexp gets old, you can always alias it or add a repo/global config option via grep.patternType [1]. Or you can create an alias for adding the less-powerful --invert-grep [2].

[0] https://git-scm.com/docs/git-log/2.32.0#Documentation/git-lo...

[1] https://git-scm.com/docs/git-config/2.32.0#Documentation/git...

[2] https://git-scm.com/docs/git-log/2.32.0#Documentation/git-lo...

Can you.... not?