Child pages
  • SECURITY issues in plugins

Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata

This page contains important advice for developers of plugins for which we receive reports of security vulnerabilities. We strongly recommend you read this page entirely if you've been assigned an issue related to a plugin you maintain on the SECURITY tracker.

The SECURITY project

The SECURITY project in the Jenkins Jira is a non-public issue tracker for security vulnerabilities. Public knowledge of these vulnerabilities could put our users at risk, so access is limited.

We grant access to specific SECURITY issues in JIRA to maintainers of affected plugins. They're often in a much better position to fix issues in their plugins, and the Jenkins CERT team ("security team") needs to coordinate releases with them even if they don't end up authoring the fix.

Recommended Practices

Due to the sensitive nature of security vulnerabilities, the following practices should be followed in resolving the issue and releasing the plugin:

  • Do not publish any information gained from the SECURITY tracker before a version of the plugin containing the fix is released, as it may put users at risk.
  • Do not publish the source code for your fix before a fixed version of your plugin has been released, e.g. by pushing it to GitHub, even it's just your fork that nobody watches. If you'd like the security team to review your fix, instead attach it as a diff/patch to the SECURITY issue, or post it to a secret gist and link to it from the SECURITY issue. If you need assistance in fixing the vulnerability, ask for it in the SECURITY issue.
  • Coordinate the date and time of the release of the fixed plugin with the security officer. This will allow for assigning a CVE ID prior to release, and a security advisory informing users of the security vulnerability, and how to fix it.


The following is a rough approximation of the recommended lifecycle of a plugin issue in the SECURITY tracker:

  1. Someone reports an issue in a plugin
  2. The security team evaluates the report.
    1. If we're confident it is not a security vulnerability, the issue is moved to the JENKINS project.
  3. We determine the maintainer. For the purposes of this document, only plugins maintained by people not also on the security team are considered here.
  4. We assign the issue to the plugin maintainer (resulting in access to the issue), and notify them in a comment.
  5. If necessary, plugin maintainers are contacted again after a while to notify them of this issue if they miss the JIRA notification.
  6. The plugin maintainer reviews the reported issue.
  7. If they identify it as an actual security vulnerability, they (and, if requested, the security team) work to resolve the issue.
    1. The security team provides a private repository for that work in the organization
    2. Work usually happens in a branch with the same name as the issue number (e.g. SECURITY-123) and a corresponding pull request to master (only for review, never expected to be merged)
  8. A date and time of the release is coordinated between the security officer and maintainer. The security officer handles CVE ID assignment, advance notification of users, and creation of the security advisory.
  9. The security fix is merged (squashed, from the Git command line) by the maintainer to prepare for a release. This is typically added to a branch based off the previous release so no unrelated changes make it into the security fix version. Possibly requires another release of the plugin between fix development and release if there are further public changes (and rebasing of the security fix onto that).
  10. A version of the plugin containing the fix is released to a staging repository (see below), usually by the maintainer.
  11. The staged release is published by the security team, and the corresponding security advisory is published and announced.

Security Update Procedure

Best Practices for Plugin Security Updates

  • Do not include unrelated changes. If the target branch of the security fix has unrelated changes, branch off from the previous release and target that branch instead, or make sure to release the plugin's unrelated changes a week or two before the security release. This limits the potential risk of regressions in the security update due to unrelated changes.
  • Do not push sources to public Git repositories. The instructions below prevent pushing the release commits, which would result in premature disclosure due to delays in the infrastructure, or the staging process. Once you've released (possibly to a staging repository), push the commits and release tag to the private repository in the jenkinsci-cert GitHub organization. From there, the commits and tag will be pushed to the public repository after the release is public, typically within an hour.
  • Use Git to merge pull request branches in the private jenkinsci-cert repository. Repositories in jenkinsci-cert are typically configured to not allow merging and squashed merging of pull requests so that no references to these private PRs are made part of the public Git history, just resulting in confusion. Instead, use Git to merge the branches.
  • No late changes. Don't add changes to the security release unless they're essential for the security fix to work. Otherwise this will invalidate the testing and review that has happened before.

Staging Procedure

Releases will be uploaded to a private staging repository (names can differ, see instructions provided by the security officer) a few days (up to a week or so) before the intended release date.

To accomplish this, do the following (REPONAME is a placeholder for the real staging repository name that is provided by the Jenkins security team):

mvn -DpushChanges=false -DlocalCheckout=true org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare org.apache.maven.plugins:maven-release-plugin:2.5.3:stage

Note that this must use release:stage instead of release:perform. While the latter also supports specifying a different repository, it's not a necessary parameter, so typos in the system property can result in accidental uploads to the public repository, disclosing any vulnerabilities early.

Then, manually push the release commits and tag to the private GitHub repository in the jenkinsci-cert organization, but NOT to the public (@jenkinsci) repository. The public pushes will typically be performed by the security officer only after the security advisory has been published.

Documentation (outside the plugin, e.g. on the wiki) should only be published once the security advisory has been published.

  • No labels