JFrog CLI allows only one repository to be specified for resolving artifacts

[luigidematteis]

Hi,
I'd like to describe a technical challenge that we are facing in order to implement JFrog Xray scan steps into the CI/CD process of our customer.

We have 1000+ projects, i.e. thousands of repositories, and JFrog Artifactory is integrated with our customer LDAP system, in such a way that if a user has permissions to access repositories A, B, and C, he can run a pipeline and build an application that uses artifacts from those repositories.

Now we're integrating JFrog Xray as a security scan tool, but we've found a limitation that is seriously compromising its integration in our customer infrastructure, because the jf-cli allows only one repository to be specified to resolve artifacts.

To explain better the issue we're facing, I'll take as example only one specific tool (Maven) for simplicity, but it applies also to any other tool that we have to cover in our CI/CD process.

https://docs.jfrog-applications.jfrog.io/ci-and-sdks/ci-integrations/jenkins-jfrog-plugin

jf mvn-config --repo-resolve-releases libs-release --repo-resolve-snapshots libs-snapshots --repo-deploy-releases libs-release-local --repo-deploy-snapshots libs-snapshot-local

The flags --repo-resolve-releases, --repo-resolve-snapshots, etc. de-facto override the repositories configuration specified in settings.xml that Maven uses to configure the application.

It means that without using the jf-cli a User that has permissions to access repositories A, B, C, as previously said, will be able to build the application in pipeline, while using the jf-cli this will not possible anymore.

The solution proposed by the support and by somebody from your team in other threads is to create virtual repositories that include the required repositories (for example, in this case they would be: A, B, and C), but this is not feasible as it would require to dynamically create virtual repositories for each user/application that requires artifacts from different projects.

In addition, this mechanism would required a lot of maintenance costs, as dependencies for an application can change, i.e. the virtual repositories should be constantly maintained, which means updated or removed.

Looking at the jf-cli code, it seems to be a design choice to accept only one repository for resolving artifacts. What are the reasons behind it? Why not allowing to specify multiple repositories to resolve artifacts?

[luigidematteis]

I'd like to add one more detail about this issue, which is that to build the artifact using the jf-cli (instead of just scanning it) is required in order to have a complete SBOM also for non-Uber JARs, or essentially for any type of artifact that doesn't directly contains all the dependencies inside.