We have a corporate/private maven registry ("artifactory") in place, which is used by our projects to resolve the project's dependencies.
This private maven registry also proxies Maven Central for common dependencies, meaning dependencies that were not resolved by the internal registry in the first place.
We want to avoid supply-chain attacks, namely someone overloading a custom dependency we use in our private/corporate maven registry with the same identifiers in Maven Central.
Say, i.e. publishing a malicious dependency artifact in Maven Central with the same groupId
and artifactId
as the internal one, but with a higher version
- that one would then take precedence and wreak havoc in our systems.
In npm, there is a mechanism that allows "tagging" a dependency to a certain private registry (via scope
).
Is there a similar mechanism in Maven that allows certain dependencies to only resolve from the internal artifactory, and prevent it from being resolved from Maven Central?
I am thinking of something like artifactory
:
<dependency>
<groupId>org.acme</groupId>
<artifactId>supersecret</artifactId>
<version>3.141</version>
<artifactory>internal_corporate_artifactory_name</artifactory> <!-- as described in settings.xml or Super-Pom -->
</dependency>
CodePudding user response:
You can solve this problem differently.
First of all, you define a <mirror>
in your settings.xml
, so that all requests go to your Artifactory.
Inside the Artifactory, you define a virtual repository for all external repositories you want to access (which will be part of the general virtual repository you use as mirro).
Now for that virtual repository, you can define "exclude patterns". This allows you to tell Artifactory NOT to resolve the groupId com.yourcompany
against external repositories.
CodePudding user response:
Adding to J Fabian Meier's answer -
Use exclude patterns on the remote repository which is mirroring Maven Central e.g. to exclude artifacts matching your company's group ID.
More information can be found in the following links:
- JFrog Knowledge Base: How to use Include/Exclude patterns?
- JFrog Blog: Yet Another Case for Using Exclude Patterns in Remote Repositories: Namespace Shadowing (a.k.a. “Dependency Confusion”) Attack
- JFrog Blog: A Year of Supply Chain Attacks: How to Protect Your SDLC
- JFrog Blog: Optimizing Repository Security and Performance with Include and Exclude Patterns