The Jenkins project takes security seriously. We make every possible effort to ensure users can adequately secure their automation infrastructure. To that end, we work with Jenkins core and plugin developers, as well as security researchers, to fix security vulnerabilities in Jenkins in a timely manner, and to improve the security of Jenkins in general.
Learn more about securing Jenkins in the Jenkins User Handbook.
See our archive of past security advisories for previously published security advisories.
We use the jenkinsci-advisories Google group to inform users about upcoming, scheduled security updates:
Whenever a security update is released, we inform the jenkinsci-advisories and oss-security mailing lists.
We recommend you subscribe to jenkinsci-advisories even if your Jenkins instance is not publicly accessible to receive timely notifications on security updates.
|
If you find a vulnerability in Jenkins, please report it in the issue tracker under the SECURITY project. This project is configured in such a way that only the reporter and the security team can see the details. By restricting access to this potentially sensitive information, we can work on a fix and deliver it before the method of attack becomes well-known.
If you are unable to report using our issue tracker, you can also send your report to the private Jenkins Security Team mailing list:
jenkinsci-cert@googlegroups.com
To show our appreciation for your help, we’ll send you a small reward for privately reported, valid vulnerability reports.
The Jenkins Security Team is a group of volunteers lead by the Jenkins Security Officer who triage and fix security vulnerabilities.
Membership is generally open to anyone with a history of positive contributions to the Jenkins project and subject to approval by the Jenkins Security Officer. In order to join, you’ll need to:
have a CLA in place, and
have a registered nickname on IRC.
Then, just contact us on the jenkinsci-developers mailing list. Be sure to tell us your GitHub, Freenode (IRC), and Jenkins community user names.
Security vulnerabilities in core are typically resolved by members of this team, while vulnerabilities in plugins are generally resolved in collaboration with the plugin maintainer(s).
To that end, plugin maintainers are granted access to issues involving their plugin in our issue tracker, and we create private repositories in the jenkinsci-cert GitHub organization for collaboration and PR review.
We strive to fix all security vulnerabilities in Jenkins and plugins in a timely manner. However, the structure of the Jenkins project, which gives plugin maintainers a lot of autonomy, and the number and diversity of plugins make this impossible.
In case of a plugin vulnerability, we try to contact the plugin maintainer(s) to inform them of it. If they decline (or otherwise fail) to fix the vulnerability, or don’t respond in a timely manner, and the security team doesn’t have the capacity to fix it, we follow the process outlined below in the interest of our users:
Publish a security advisory about the plugin, describing the nature of the vulnerability, but noting that there is no fix other than no longer using the plugin. If there are workarounds, explain them.
Depending on the severity of the vulnerability, stop publishing the vulnerable plugin on the Jenkins update site.
Add metadata to the plugin site indicating vulnerable plugins to inform administrator who may already have the plugin installed. Displaying these warnings is supported from Jenkins 2.40 and LTS 2.32.2.