Private registry access for Automatic Dependency Submission

[h3rmanj]

Select Topic Area

Product Feedback

Body

Allow the Automatic Dependency Submission feature to access to the org-level Private Registry feature.

We tried turning on Automatic Dependency Submission for all our repos. But the NuGet action fails, because we use private registries (in this case GitHub Packages). The job fails, and subsequently marks all pull request and pipeline runs as failing.

It would be great if the feature had access to the same configuration as Dependabot and the default CodeQL setup.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[andreasnilsen]

So after 2 months, there is no plan to fix this, effectively making automatic dependency submissions useless for all organizations that utilize private package repositories like f.ex. Github Packages?

It would be nice with an acknowledgement that you are not going to fix this any time soon, so that organizations can assess wether it will be worth the effort to maintain individual component scanning workflows for each of their repositories.

[pedrojreis]

Following this in the hopes we can get some answers.
Attempted to make this work but with no avail :(

[m3ac-AllbrittenJ]

Also following this. Also, Private Registries need to be updated to support OIDC like the repo level yml can

[Hekku2]

I'm encountering the same issue.

[JarRami]

Also encountering the same issue with Telerik's licensed nuget feed. Seems odd I have to create a manual workflow to get a builtin feature like this to work.

[anthonymastreanvae]

The workaround the NuGet docs appear to offer does not work, and this thread records no one having tested it. Measurements below.

Setup

.NET repository on GitHub Enterprise Cloud with data residency. Central Package Management, so PackageReference carries no Version and the static parser records every NuGet component as >= 0 — an unbounded range that intersects no advisory range, so Dependabot can raise no .NET alert at all. Automatic Dependency Submission is the documented fix.

A handful of first-party packages resolve from a private GitHub Packages feed, mapped by packageSourceMapping:

<packageSourceMapping>
  <packageSource key="nuget.org"><package pattern="*" /></packageSource>
  <packageSource key="internal-feed"><package pattern="Acme.*" /></packageSource>
</packageSourceMapping>

Submission fails on every run:

error NU1301: Failed to retrieve information about 'Acme.SomePackage' from remote source
  'https://nuget.<host>/…/index.json'.
error NU1301:   Response status code does not indicate success: 401 (Unauthorized).

The failure is all-or-nothing. validate-project fails, submit-dependency-snapshot is skipped, and the components that resolve fine from nuget.org are not submitted either. One unreachable package costs the entire snapshot.

The workaround that does not work

The NuGet registry docs say GITHUB_TOKEN can be used "if the repository is granted read access to the package," and GitHub Packages exposes that per package under Manage Actions access. That reads like it should cover a GitHub-managed Actions workflow.

Tested it: granted the consuming repository read access on every private package it restores, re-enabled Automatic Dependency Submission, ran it against the default branch.

Identical NU1301 / 401. Same step, same package, dependency graph unchanged.

The grant governs permission. The failure is credential presentation. A request that carries no authentication header gets 401 regardless of who is permitted, and a GitHub-managed workflow has no step in which to present one.

Permission was never the constraint here, and our own SBOM workflow is the evidence: it restores the same packages successfully on every run, because it does this first.

- run: dotnet nuget update source "internal-feed" --username ${{ github.actor }} --password "${{ github.token }}" --store-password-in-clear-text

That step is precisely what cannot be added to the managed workflow.

What does work

Self-submitting the snapshot from a workflow you control. We run advanced-security/component-detection-dependency-submission-action in our existing SBOM workflow, after that authentication step and a normal dotnet restore, in its own job with contents: write, gated to the default branch.

Two things worth knowing if you go this way:

Build the snapshot from the restore graph, not from a CycloneDX BOM. Implicit .NET runtime packs (Microsoft.NETCore.App.Runtime.<rid> and the AspNetCore sibling) are PackageDownload items, absent from packages.lock.json by construction and therefore absent from a lockfile-derived BOM. In a sibling repository those runtime packs accounted for 240 Dependabot alerts that no other channel could see. A BOM-derived snapshot silently reproduces that blind spot.

A called workflow cannot hold more token permission than its caller grants. If your SBOM workflow is reusable, the calling job needs contents: write too, or the submission gets a 403 that looks nothing like a permissions problem.

It also turns out to be the more deterministic option, which cuts against the usual framing of self-submission as a workaround. It restores against the SDK pinned in global.json with rollForward: disable, where the hosted runner carries whatever SDK its image shipped with. .NET ships SDK servicing roughly monthly and an SDK version is not a package version, so a hosted-runner graph churns on runner drift.

Restating the ask

Reading the registries: block, or the organization private-registry configuration that Dependabot and code scanning already use, would make the hosted feature work for everyone in this thread. Until then, any repository with an authenticated feed has to reimplement submission itself.

The quieter case is a repository that adds its first private dependency. Its dependency graph was working, and now it is not. The symptom is a red check beside a graph that silently freezes on its last good snapshot, still serving yesterday's resolved versions.

🤖 Generated with Claude Code