dependabot / dependabot/dependabot-core
Support Dependency Graph Discovery for Internal Registries
- 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
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