Absolutely! That's currently roadmapped as the next major project to focus on, after this quarter's ship of custom configurability at the repository level.

Will enabling this feature at the repo level be available via the REST API? (at least until we can enable org-wide)

@jeremie0 would you still make use of enablement via API if we had better UI-based enablement (across org-levels)?

If we could enable org-wide via the UI that would replace the need for API.

Thank you!

Noted! We're investigating this now. ❤️

@erinhav I was curious to know if there were any updates on the support for yarn?

Hi @erinhav any further update on this? Currently I am able to work around this limitation by running: npm ls <pkg-name> --prod in a Github Action that fetches Dependabot alerts for the yarn ecosystem via Graphql, but the problem with this approach is there is no way to update the dependencyScope for the alert metadata via any API if it turns out the scope is indeed DEVELOPMENT instead of RUNTIME

Fix going out now. Thanks for letting us know! ❤️

+1 All 3 are in scope. For organization defaults, would those be always on, or would you want some available to all repositories (but off by default, so not enforced initially)?

Great to hear! Any idea about an ETA? (I'm about to write a custom action to dismiss low-severity alerts and I'd gladly save myself that effort...)

Regarding settings: Ideally there would be an organizational default (off by default as you propose) that can then be overridden per repository.

Oh dear! That's not right. Have you opened a support ticket? You can also email me details at erinhav@github.com, so we can take a look.

Thanks, I'll get in touch by email for details as this concerns a private org repo.

The bugs of all open alerts having been auto-dismissed seems to be fixed.
As of today, there is only a single auto-dismissed alert in the repo in question, which is correctly classified (CWE-1333).
I haven't yet checked if there are other alerts that should have been auto-dismissed...

Good

✋ I'd like to join the private beta.

@erinhav while not having seen anything out there thus far, how about the API support in that regard ?
The org level enablement for auto triage will not work in the scenario of:

• having a rule that dismisses e.g. golang alert b/c of gofiles being part of the build tooling but not the final output
• however, there may be still repositories in the org that deviate from the above in that also production grade gocode is there

On top of that, administering the GH Org via IaC would also have the desperate need for REST API Support.
This for me raises the general question of any sort of API-First strategy is employed here ?

Thanks a ton for your comments

@steinheber thanks for following up! We don't have API support for this feature at this time.

@carogalvin thanks a ton for your response,

Anything on the roadmap in that regard ?
And if not, where can i file a feature request ?

I do see legitimate scenarios for the topic at hand - especially in the case of having organizations w/ a diverse tech stack that need to treat dependabot alerts with varying urgency depending on the repository at hand.

Best regards,
Thomas

@steinheber we don't currently have anything on our roadmap for this; it's something that we have in our backlog as something we'd like to get to sometime. I totally agree that this is a big gap for this area, we're just pretty tightly constrained right now and can't get to all the gaps and feature improvements we'd like to do.

That's great feedback. We're 🤏 this close to completing a major rearchitecture of our dependency graph, which will enable us to surface transitive dependency info in places like alert details and our rules engine.

While this dependency graph work is in flight, unfortunately I see the next step of exposing this data as still being months out (our supply chain team is small).

On the bright side, org-level custom rules and APIs are planned to ship this quarter. Any additional requests regarding those ships?

OK, so to make sure I understand: you have a folder in your repository that represents a backup, and not the code that is being actively maintained used, so you would like to be able to tell Dependabot to ignore that folder for alerts and PRs, is that correct?

@carogalvin , yes that is correct.

It would be more convenient if dependabot made this distinction on it's own. If it cannot then a manual directory exclusion is the next best option.

What would you expect Dependabot to use to tell the difference between a directory that it should and should not update, in this case?

@carogalvin , it is certainly possible to recognize a VS repo and Migration Backup as an automatic exclusion as a user convenience. I think that methodology would help the most users seamlessly and prevent dependabot abandonment for the extra hassle from false positives it will inherently cause as-is.

Otherwise a manual user programable directory exclusion is the next best option.

Thanks for the feedback! If you have custom auto-triage rules available for your repository, you can automatically dismiss alerts for those manifests. We also have improvements to configuration for Dependabot updates on our roadmap for later this year, where we will be addressing things like telling Dependabot to ignore particular directories for updates.

@bordenit could you clarify what you mean by "it doesn't seem to catch much" - are you saying the auto-triage rules aren't dismissing when you expect it to, or that you are not receiving alerts that you are expecting?

@filips123 thanks for your feedback! This is a limitation in our support for Yarn today, unfortunately

Thanks for the notice. Are there any plans to improve support for Yarn, and if so, are there any details approximately when it will be available? Also, is there any detailed explanation about which package managers (for JS and also other languages) are supported with which Dependentbot features?

We're investigating the level of effort required here but don't have a target date yet. You can see a list of supported package managers across Dependabot alerts here: https://docs.github.com/en/code-security/dependabot/dependabot-alerts/viewing-and-updating-dependabot-alerts

Got it, thank you for that feedback!

Thank you for that feedback!

@carogalvin any chance a feature like this might be added soon?

This is not currently on our planned roadmap

I was actually looking at something similar today where I was looking for CWE #'s + whether it was exploitable as a devdependency. Alot of CWE's do not matter when testing locally and can only be exploited in runtime. Would make for great filter if only there werent 1000's of these CWE numbers to sort through.