We understand that directly upgrading the JAR files inside the plugin manually is not a recommended approach as it may break the plugin’s functionality.
As part of mitigation efforts, we upgraded the Artifactory plugin to its latest available version (v4.0.8), but the vulnerabilities still persist in this release.
We would like to know:
Is there any alternative approach to address these vulnerabilities without breaking plugin functionality?
Would manually upgrading these JAR files within the plugin resolve the issue?
Is there a planned release for the Artifactory plugin that will update these dependencies and close the VAPT findings?
Any guidance or recommendations from the community would be greatly appreciated.
I would open a Jira ticket on the plugin. It currently packs many thirdparty jars resulting in a total size of 36MiB for the plugin. For many of those thirdparty things there are existing Jenkins api plugins e.g. jackson. Also guava is provided by core itself so not needed at all. That would solve the issue and also reduce the size of the plugin
You could create your own fork of the plugin, update its dependencies to fix the issues, and use your locally built version instead of the released version. You could submit your changes as a pull request to the upstream repository at GitHub - jfrog/jenkins-artifactory-plugin: Jenkins artifactory plugin .
The README says that JFrog welcomes contributions through pull requests
It depends on what you consider to be the issue.
I suspect that the issue for you is that a vulnerability scanner mandated by your organization has found a version of a dependency that has a known vulnerability and someone in your organization has said that dependencies with known vulnerabilities must be updated, whether or not the vulnerability affects the software using that dependency.
If that is the issue, then replacing jar files within the plugin might resolve the issue, but it will certainly create confusion when the plugin behaves unexpectedly. It will be better for you and better for future users of your system if you compile your own copy of the plugin with changes that resolve the issue for you. Then it is clear in the Jenkins plugin manager that you are using a private copy of the plugin.
If you’ve found an exploitable vulnerability in the plugin (and not just a scanner report), please follow the instructions for reporting vulnerabilities.
I’ve not seen any mention of any plan to release a new version of the Artifactory plugin. There are many pending pull requests for various changes. Assuming you have a commercial relationship with Artifactory, you might contact them to understand their recommendations.
“Thanks for the clarification. From what I understand:
Manually upgrading the JAR files is not advisable.
The safer option is to either fork the plugin, update dependencies, and maintain a custom build, or raise a Jira ticket to request maintainers to align dependencies with Jenkins’ provided APIs.
As of now, there’s no official release planned that addresses these outdated libraries.
We’ll evaluate raising a Jira ticket with plugin maintainers.
We’ve recently received a response from a person at JFrog that they are not accepting changes to the Artifactory plugin. They want users to migrate to the JFrog plugin. That seems like the best approach in this case as well.