Automatic Dependency Submission no longer works with private repository packages

[andre-HiD]

Since at least a couple of weeks ago, it seems the automatic submission can no longer read from the repository packages (also recently mentioned in Issue 91 by another user).

The submit-dependency-snapshot step fails during execution of depgraph-maven-plugin:aggregate with an authorization error (401 Unauthorized) if the project references at least one private repository package. This previously worked out of the box without any additional configuration until recently.

Is there any ongoing plan to potentially address this? We can make it work by disabling the automated submission, and using the published version of the action (and explicitly setting the token).

While this is not a blocker per-se, it is a little counter intuitive in the sense that your recommendation is to use the automated submission.

Any clarifications on why this issue recently appeared, and whether there are any plans to address it (or if there is anything we can do on our end as users) would be greatly appreciated!

[juxtin]

I wonder if this is related to Actions workflow permissions.

[dangoor]

@andre-HiD Sorry for not replying to this sooner. @juxtin and I just chatted about this. We're left wondering if v4 of this action works still for you, or if there was some other change that occurred at about the same time.

In v5, we changed the use of the depgraph-maven-plugin from its aggregate mode to graph mode. (Note that the label in the workflow still says aggregate, but it is actually graph). From a cursory look, it does not seem like there should be a difference in how those two modes access any external resources.

We had a hypothesis that maybe graph mode was finding some private, transitive dependencies that weren't there in aggregate mode, but haven't found evidence that this is the case.

Hence the interest in "does using v4 of this action fix the problem?" We're currently thinking that v4 wouldn't fix the problem and that there's something else going on.

[andre-HiD]

@dangoor @juxtin Hey guys, it took me a while to get some free time to look into this in more detail, but I just managed to squeeze in some time to run an array of tests of the action (v4 and v5) under different conditions, which I outline below. Those with sharp eyes among you will notice I used an LLM to speed up the generation and formatting of the summary, but try not to focus too much on that 😃

Feedback Summary — Maven Dependency Submission Action

I recently managed to find some time to run a series of tests on the Maven Dependency Submission Action across versions 4 and 5.
The goal was to understand the behavior when authenticating against private GitHub Packages (Maven), both with and without explicit configuration or tokens.

Throughout these tests, all PATs refer to classic tokens, not fine-grained ones.

---

Definitions

• Automatic Dependency Submission (ADS): GitHub’s built-in automatic submission
• PAT: "machine" account personal-access token (classic)
• Error 1 = 401 → Unauthorized during Maven aggregate goal (package resolution failure)
• Error 2 = 404 → Error during dependency snapshot submission (after aggregate)

Test Conditions

• Multi-module project repository
• Repository using private Maven packages hosted on GitHub Packages
• Tests executed from PR (test → main, default branch) - I am aware this should not be run on PRs, but for testing purposes it does the trick.
• Dependabot .yml configuration present only in test branch
• Default Workflow permissions (i.e. the ones configured in the repo Settings): repository read and write
• No settings.xml explicitly configured

Results

Automatic Submission

The first round of testing involved enabling GitHub's automatic dependency submission, which executes as the action dynamic / submit-maven (dynamic). In this scenario, the PAT in question had repo and read:packages permissions.

Scenario	Result
Without dependabot.yml	❌ Failure (Error 1)
With dependabot.yml (in PR from test → main), using the registries field, and PAT as a Dependabot secret	❌ Failure (Error 1)

Observation: The built-in automatic submission does not appear to access dependabot.yml from the PR branch, nor does it seem to use Dependabot secrets. All runs failed with 401 during Maven aggregation. This was working just fine until some time in May 2025.

---

Manual Workflow Tests

Round 1 — Default permissions, PAT with read:packages

Version	Token	Result
ADS	N/A	❌ Error 1
v4	none	✅ PASS
v4	PAT	❌ Error 2
v5	none	❌ Error 1
v5	PAT	❌ Error 1

---

Round 2 — Default permissions, PAT with repo + read:packages

Version	Token	Result
ADS	N/A	❌ Error 1
v4	none	✅ PASS
v4	PAT	✅ PASS
v5	none	❌ Error 1
v5	PAT	❌ Error 1

---

Round 3 — permissions: contents:write, PAT with read:packages

Version	Token	Result
ADS	N/A	❌ Error 1
v4	none	✅ PASS
v4	PAT	❌ Error 2
v5	none	❌ Error 1
v5	PAT	❌ Error 1

---

Round 4 — permissions: contents:write, packages:read, PAT with read:packages

Version	Token	Result
ADS	N/A	❌ Error 1
v4	none	✅ PASS
v4	PAT	❌ Error 2
v5	none	❌ Error 1
v5	PAT	❌ Error 1

---

Summary

• For each of these cases, the failure occurs during the execution of the :graph goal for the parent (i.e. root) module, and does not proceed to the other ones. So it does not look like it's a authentication gap for a specific module. In other words, authentication fails for the first module it encounters.

• Automatic Dependency Submission (ADS) consistently fails, regardless of branch or PAT configuration.
  It does not appear to use dependabot.yml or Dependabot secrets for registry authentication.

• Version 4 of the action works “out of the box” with default permissions, and succeeds when a PAT (classic, repo + read:packages) is explicitly provided.

• Version 5 fails in all tested configurations with 401 during aggregation.

These findings suggest that ADS and v5 are currently unable to authenticate properly with private GitHub Maven Packages using only built-in permissions or limited-scope tokens.

If the only change between v4 and v5 is the switch from aggregate to graph, then either something in the latter implementation is subtly different, or there is something else more tricky at play which is not so easy to locate.

I can also share the actual workflow file, but it's nothing too complex (1. checkout repository v4, setup-java v4 with jdk 21, submit-action v4/v5 with and without token). I chose not to explicitly include the full thing because it's a "quick-and-dirty" copy-paste job and might lead to more noise than signal, but it's some (repetitive) variation of what's below 😉

---

Appendix - workflow.yml

name: Testing Maven Dependency Submission

on:
  pull_request:
    branches: [ default ]
  workflow_dispatch:

# permissions:
#  contents: write
#  packages: read 

jobs:
  submit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up JDK 21
        uses: actions/setup-java@v4
        with:
          java-version: "21"
          distribution: "temurin"

      - name: Submit Snapshot
        uses: advanced-security/maven-dependency-submission-action@v4 #(or v5)
        # with:
        #  token: ${{secrets.TEST_PAT}}

Final Notes

I understand now that in v5 we can supply a settings.xml file. But if the repositories are already defined within the POM and the default GITHUB_TOKEN does indeed have the correct permissions (and since this worked in v4, it is clearly the case), why would changing to a "per-module" resolution result in a different authentication behavior? Looking at the changes between v4 and v5, there doesn't seem to be anything which might impact the effective "default" settings.xml file that was used.

If this is a question of GitHub making changes to how Actions tokens are handled, then wouldn't it also equally affect v4 of the action?

A couple of things I was not able to check are the impact of removing the :reactor step, and whether there is some common setting between :aggregate and :graph whose default value (or null-value) handling is different between both goals.

Thanks for taking a look, and I am happy to share more information if needed.!

[juxtin]

Thank you so much for all those details, @andre-HiD! We'll be conferring amongst ourselves and pairing to see if we can figure this out.