Clarification regarding the project's security policy
Daniel Beck
Hi everyone,
Challenges in working with some maintainers working for larger organizations with security teams made it clear to the Jenkins security team that we need to clarify the following.
The Jenkins security team is the initial contact point for vulnerabilities in Jenkins and Jenkins plugins. This is defined in the GitHub org's SECURITY.md and in security-related documentation on jenkins.io (e.g., 1, 2) and there are a lot of benefits for the project and Jenkins users to this approach.
Some plugins are maintained by companies that have their own, conflicting security policies, for their products. Some organizations consider Jenkins plugins they maintain to be their products (e.g., when the plugin integrates with their tool or service). As a consequence, the benefits of central reporting to the Jenkins security team are negated if vulnerabilities are reported to those security teams directly. Additionally, even if we're involved in the process, those policies usually result in a lot more work for the Jenkins security team (e.g., rejecting Jira as a tool to communicate vulnerability reports in favor of email / their own ticket system). With more than 2000 plugins maintained by well over 1000 individuals, adding that on top quickly becomes impractical.
While we've never explicitly stated it, the Jenkins security team does not consider such policies in our handling of security vulnerability reports, and we require that all plugins distributed by the Jenkins project do not have a conflicting security policy. We'll clarify existing documentation to make this explicit, and file pull requests to remove custom SECURITY.md or similar documentation from plugin repositories that currently have them. If there’s a security team that maintainers are expected to work with, they can define security contacts in their plugin metadata, which allows people other than maintainers to be informed about security vulnerabilities. If you have other requirements that this approach doesn’t satisfy, please reach out to the Jenkins team via Jira or email to discuss these.
Not everyone may consider this approach acceptable for the components they maintain. Longer-term, we plan to remove plugins with custom security policies from distribution from Jenkins update sites and suggest maintainers choose alternative methods of distribution to their users if they wish to be the primary/only security contacts.
Note that this restriction explicitly does not apply to CVE assignment coordination. The Jenkins CVE Numbers Authority (CNA) will continue to operate within the rules defined for CNAs, including reaching out to other CNAs when appropriate, as we've done many times in the past. However, we'll not let the security teams we reach out to for this purpose affect the rest of our process.
Regards
Daniel
Jenkins project security team