dependabot-core icon indicating copy to clipboard operation
dependabot-core copied to clipboard

Support scanning `uv.lock` for dependencies

Open isbldr opened this issue 9 months ago • 5 comments

Is there an existing issue for this?

  • [x] I have searched the existing issues

Feature description

Now that dependabot somewhat supports updating uv.lock, it'd be great if it could detect vulnerable dependencies by scanning this file.

Related:

  • https://github.com/dependabot/dependabot-core/issues/10478

isbldr avatar Mar 28 '25 09:03 isbldr

does this issue mean, that the uv support of dependabot currently "only" handles direct dependencies from the pyproject.toml file and not all transitive dependencies?

christianplatta1012 avatar Apr 16 '25 14:04 christianplatta1012

Yes, that's my understanding at least. If you go to Insights > Dependency Graph and select pip ecosystem on a repo with uv.lock you'll only see dependencies from pyproject.toml.

isbldr avatar Apr 16 '25 14:04 isbldr

Is this the reason that PRs generated for dependabot vulnerability alerts only update the pyproject.toml but not the uv.lock file? The uv.lock file is updated fine for dependabot version update PRs.

ed-berry avatar Apr 17 '25 16:04 ed-berry

My understanding is that dependabot supports uv via the pyproject.toml and can update the uv.lock file via the tools command uv lock but is actually not currently parsing it for the dependency graph About Dependecy Graph

Thus not reporting the transitive(only direct) dependencies for security alerts and similar which this issue is about.

ch0wm3in avatar Apr 23 '25 10:04 ch0wm3in

Yes, that's my understanding at least. If you go to Insights > Dependency Graph and select pip ecosystem on a repo with uv.lock you'll only see dependencies from pyproject.toml.

I face precisely the same issue.

puchta avatar Jun 05 '25 15:06 puchta

A worse bug IMO is that configs from the uv ecosystem don't appear to be applied for security updates as pip is assumed

Example when generating a Gunicorn security update, even though I have this value set in the uv ecosystem config in my dependabot.yml Image

Here are the logs, notice how it picks pip

Image

phillipuniverse avatar Jul 28 '25 20:07 phillipuniverse

Since vulnerability scanning is critical for us and it was blocking uv adoption we came up with the following github action:

on:
  push:
    branches:
      - "**"

jobs:
  submit-uv-dependencies:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v4
      - name: Install uv
        uses: astral-sh/setup-uv@v5
        with:
          enable-cache: true
      - name: Install backend dependencies
        run: uv sync --frozen
      - name: Generate requirements.txt
        run: uv pip freeze > requirements.txt
      - name: Submit
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs/promises');
            const text = await fs.readFile("requirements.txt", "utf-8")
            const data = text.trim().split("\n").map(line => line.split("=="))
            await github.rest.dependencyGraph.createRepositorySnapshot({
              ...context.repo,
              version: 0,
              job: {
                id: context.job,
                correlator: `${context.workflow}-${context.job}`,
                html_url: `${context.serverUrl}/${process.env.GITHUB_REPOSITORY}/actions/runs/${context.job}`
              },
              sha: context.sha,
              ref: context.ref,
              detector: {
                name: 'custom-because-dependabot-doesnt-work',
                version: '0.0.1',
                url: "https://private.test",
              },
              scanned: new Date().toISOString(),
              metadata: {},
              manifests: {
                "uv.lock": {
                  name: "uv.lock",
                  file: {source_location: "uv.lock"},
                  metadata: {},
                  resolved: Object.fromEntries(data.map(([dep,ver])=>[dep, {
                    // https://github.com/package-url/purl-spec
                    package_url: `pkg:pypi/${dep}@${ver}`,
                    metadata: {},
                    relationship: "indirect",
                    scope: "runtime", // TODO: or development
                    dependencies: [], // TODO: PURLs
                    // https://docs.github.com/en/rest/dependency-graph/dependency-submission?apiVersion=2022-11-28#create-a-snapshot-of-dependencies-for-a-repository
                  }]))
                }
              }
            });

It's rudimentary and doesn't do everything correctly, but the dependencies do show in the list. Ideally, you'd parse the lockfile directly (it's just a toml file) and output the full dependency graph and relationship and scope.

It's still a mystery to me why dependabot doesn't support this proper. Please, prioritize this. This is the most critical part - reporting that there's an issue. I can update my dependencies manually, but scanning for vulnerabilities needs to be automated. I'd send a PR, but I don't want to learn ruby for this.

isbldr avatar Aug 07 '25 09:08 isbldr

+1 for this feature, would be great to have out of the box. Since dependabot supports requirements.txt we can use https://docs.astral.sh/uv/reference/cli/#uv-pip-freeze in the meantime. Would it be manageable for dependabot to call this under the hood so that end users don't need to manage this redundantly?

davidroeca avatar Aug 28 '25 17:08 davidroeca

I created a workaround action for now, that parses the uv.lock files in your repository and submits them, so you have the full graph: https://github.com/rmuir/uv-dependency-submission

rmuir avatar Oct 02 '25 07:10 rmuir

I created a workaround action for now, that parses the uv.lock files in your repository and submits them, so you have the full graph: https://github.com/rmuir/uv-dependency-submission

Awesome, we have something very similar internally. I went through your implementation with an eye on differences and it seems that you handle some cases better than we do. Good stuff. I added it to the top-level issue for people googling this.

isbldr avatar Oct 02 '25 10:10 isbldr