dependabot / dependabot/dependabot-core

Support Dependency Graph Discovery for Internal Registries

Open
#12,845 17 comments 6 reactions 0 assignees View on GitHub
L: dart:pub L: python T: feature-request
Dominant language
Ruby
Stars
5.8k
Forks
1.5k
Avg merge
2d 18h
Merged PRs (30d)
149

Description

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Feature description

Dependabot supports access to internal registries when performing automated version updates, but not when building a dependency graph. As a result, automated security updates are also not supported when using an internal registry. This renders most of Dependabot's features useless when using an internal registry as a pull-through cache (which is a pretty common use-case).

Specifically, I'm trying to use Dependabot to maintain security updates across multiple python repositories that use Poetry or UV as their package manager. These repositories also use an internal registry as a pull-through cache to pypi. When GitHub ["scan(s) [my] repository for manifest files"](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/dependency-graph-supported-package-ecosystems#supported-package-ecosystems), none of them are found, since they all list my internal registry as the package's source.

[Automatic Dependency Submission](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/dependency-graph-supported-package-ecosystems#supported-package-ecosystems) might be a viable solution (I could run the workflow on a self-hosted runner w/ access to my internal repo), but it's not supported for Poetry or UV. At least I think that's the case. The documentation for all of this stuff is a bit difficult to follow.

This leaves me with only one option: [Using the dependency submission API](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api). I don't want to have to create SBOMs for common python packages just b/c I'm using an internal registry as a pull-through cache. At the moment, I'm just also generating a `requirements.txt` file alongside my `poetry.lock` file, which kind-of works for dependency discovery, but makes any automated security updates fail to actually update the correct file.

My request would be that public dependencies on internal registries could easily be added to the dependency graph. I can think of a few ways this might be doable:
- Allow configuration of how GitHub scans manifest files. I could then configure the static scan to attempt to find the package on a public repo, even if it has a package source listed in it's manifest file.
- Register dependencies when running a Dependabot version update (since this already supports accessing internal registries)
- Support automatic dependency submission for Poetry and UV.

If there's another way to configure my repositories to enable dependency graph discovery that I'm unaware of, please let me know!

Contributor guide

Open the contributing guide

Research direction

Start with the linked documentation for dependency graph discovery, Automatic Dependency Submission, and the dependency submission API, then compare those paths with Dependabot version updates, which already access internal registries. Done requires a concrete, agreed approach for discovering Python dependencies from internal registries, including Poetry or UV, rather than choosing among the several proposals in the issue.

Written by the indexing model from the issue text.

Assessment

Tech stack
github, python
Domain
security, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.