Is the "Official OWASP ZAP" Jenkins plugin still maintained? Why does the repo say it's no longer an official ZAP project?

Using Jenkins Ask a question
1

I was trying to integrate DAST on my CI/CD lab and stumble across Official OWASP ZAP plugin on Jenkins available plugin tab and notices that the latest update was over 9 years ago. I did some research on the cause of it by going through their GitHub repo, searching around their website for some clue, and found nothing. The only thing that resembles of a hint is the latest commit message saying “Its no longer an official ZAP project” hinting at a possible abandonment, but why?
Is there a real concrete reason on why they abandoned it?

note: also, I’m still new in this community, so if I were to somehow break a guideline, I’m sorry in advance!
thanks

2

I suspect that they want users to run their recommended containerized environment instead of using a Jenkins plugin. Their documentation at “Automate Zap” includes:

The mailing list description says:

Note that this plugin is no longer supported by the ZAP Core Team, however you can use the ZAP Docker images in any CI/CD pipeline.

Why you should not use the Zap plugin

The plugin has a security vulnerability and bugs that will prevent it from working correctly in Jenkins versions released in the last 5 years.

The unresolved security vulnerability reports that the plugins stores a credential in plain text.

The Jenkins plugin health score is 46%. Most actively used Jenkins plugins have scores 80% or higher.

The Jenkins issue tracker includes the following known issues:

  • Plugin fails when configuring job with Jenkins 2.277.1 or later - JENKINS-65399
  • Adding a build step has the wrong behavior since 2.263.4 - JENKINS-68393
  • Plugin fails when content security policy checking is enabled JENKINS-74265
3

I see. It’s just that it’s a bit abrupt to discontinued it, seeing their other plugin project like dependency track is still maintained. But I really want to know the actual reason for the abandonment, like is it because of “favoring flexibility” over “ease of use”? perhaps it’s not worth the hassle to maintain it? I guess we will never truly know until one of the people behind it gave a valid answer. Regardless, thanks for the answer, Mark
Will use the containerized automation instead of the plugins!