Add support for Azure Artifacts as an alternative to Central Analyzer (similar to Nexus/Artifactory)

[twrb]

Is your feature request related to a problem? Please describe.
Currently, Dependency-Check supports Nexus as an alternative to Maven Central for dependency metadata resolution. However, many organizations use Azure Artifacts as their private Maven repository. There is no native support for Azure Artifacts, which forces us to either disable the Central Analyzer or rely on external services, creating reliability and security concerns.

Describe the solution you'd like
Add support for Azure Artifacts as a repository source for dependency metadata, similar to the existing Nexus Analyzer. This should include:

Ability to configure an Azure Artifacts feed URL.
Support for authentication using Personal Access Token (PAT) or OAuth.
CLI and Gradle/Maven configuration options (e.g., --azureArtifactsUrl or -Danalyzer.azure.url).

Describe alternatives you've considered
Disabling the Central Analyzer and relying only on local scanning (losing version vulnerability checks).
Using Nexus as a proxy for Azure Artifacts (adds complexity and infrastructure overhead).
Manually mirroring Maven Central inside Azure Artifacts (still does not integrate with Dependency-Check directly).

Additional context
Azure Artifacts is widely adopted in enterprise environments, especially for teams using Azure DevOps pipelines. Supporting it natively would:

Improve reliability by reducing dependency on Maven Central availability.
Align with modern DevOps practices.
Enhance security by keeping dependency resolution within the organization.

Example Azure Artifacts Maven feed URL:
"https://pkgs.dev.azure.com/organization/project/_packaging/feed/maven/v1"

Example:

dependency-check.sh
--azureArtifactsUrl "https://pkgs.dev.azure.com/organization/project/_packaging/feed/maven/v1"
--azureArtifactsToken ""
--azureArtifactsEnabled true

[chadlwilson]

Best practice for JVM is to scan your projects with the ODC Maven or Gradle plugins directly. Presumably these would already be configured to pull artifacts from your Azure Artifacts, and so Maven and Gradle will already pull all information necessary for ODC to do its analysis. There is no need to use the Central Analyzer in most such cases, and it can/should be disabled (it’s disabled by default with Gradle now).

The Central Analyzer is essentially a fallback approach for non-project-aware scanning of archives and uber-jars to try and locate POM metadata. It will always have a greater rate of false positives/negatives than something natively aware of the transitive dependency relationships. In other words, if you care about reliability, security, reliability etc, don’t scan a (JVM) project with the CLI if you can avoid it.

Aside from that, these (commercial) organisations and “enterprises” could perhaps address their reliability and security concerns by contributing funding or pull requests to implement and support such a feature. Most (but not all) volunteer OSS contributors working on their own time generally have less interest in implementing support for proprietary paid services.

My personal view is that there are so many proprietary cloud services with their own custom artifact repositories, custom authentication and custom search APIs that I don’t think it will make sense for this project to try and maintain individual integrations to them solely for retrieving POMs.

[twrb]

@chadlwilson In Azure DevOps, we use the OWASP Dependency Check Azure DevOps Extension, which configures tasks similar to CLI options. We initially tried using the Sonatype Central Analyzer, but the API started returning HTTP 429 (Too Many Requests) errors. Sonatype’s official communication about this limitation can be found here: Maven Central and the Tragedy of the Commons.
the recommended workaround is to use Nexus as an alternative, but in Azure DevOps environments, we already have Azure Artifacts as the native package repository. It would make much more sense to support Azure Artifacts directly.

Example:

• task: dependency-check-build-task@6
  continueOnError: true
  timeoutInMinutes: 10
  inputs:
  projectName: 'Dependency-check scan: $(Build.Repository.Name)'
  scanPath: '${{ parameters.scanPath }}'
  excludePath: '${{ parameters.excludePath }}'
  format: '${{ parameters.format }}'
  suppressionPath: '${{ parameters.suppressionFile }}'
  reportsDirectory: '${{ parameters.reportsDirectory }}'
  reportFilename: '${{ parameters.reportFilename }}'
  dependencyCheckVersion: '${{ parameters.dependencyCheckVersion }}'
  additionalArguments: >
  --nvdApiKey $(nvdApiKey)
  --nvdApiDelay 6000
  --data "$(Build.Repository.LocalPath)/owasp-dependency-check-data"
  --noupdate
  --centralUrl $(centralurl)
  --ossIndexUsername $(sonartypeossindex)
  --enableExperimental
  --ossIndexPassword $(sonarToken)
  displayName: 'Dependency Check Scan'

I will try disable central analyzer for while ...

Thank you anyway :D

[chadlwilson]

Personally I don't think using think using the Azure DevOps extension is the right tool for the job when scanning JVM projects, if it is not able to inject plugins into builds and use native scanning approaches.

If you can't move to a more efficient integration, you should also look at caching ODCs data directory so it is not hammering Central repeatedly for the same POMs for the same jars over and over in builds. https://dependency-check.github.io/DependencyCheck/data/cacheh2.html

Since your dependencies don't change all the time this should massively decrease the requests needed to Central Search.