Hello everyone, I’m Sam Richard (@Pnkcaht on GitHub), an Jenkins contributor core and plugins. I’ve contributed security fixes to the Jenkins core, including a critical race condition fix during the initial administrator account creation (integrated in version 2.545).
To further support the community, I recently launched @JenkinsSecurity – an independent organization focused on aggregating security-focused plugins, tools, research, and best practices to help teams strengthen and audit their Jenkins CI/CD pipelines.
No, you haven’t contributed security fixes to Jenkins core. You’ve contributed a pull request that updated the README in Jenkins core and you’ve contributed a pull request that fixed a race condition where a member of the Jenkins security team said:
I do not consider this to be a vulnerability, since the user was clearly entitled to perform the action. They could just run a Groovy script instead. The outcome (multiple admin users) might be surprising, but it’s unlikely to occur.
Based on that description, you’ve submitted a bug fix pull request and a documentation pull request.
Please explain why you didn’t discuss this idea with the Jenkins security team or anyone else in the Jenkins community.
Please explain why you didn’t find a way to work within the Jenkins organization.
Please explain why you think that Jenkins needs an “An independent community-driven organization focused on Jenkins security”. Wouldn’t it be better to work with the Jenkins security team to improve as they suggest in “Other ways to contribute”
Document security best practices for Jenkins administrators and Jenkins developers.
Identify and report security issues, even in plugins you maintain yourself. As a reporter, you can include proposed fixes or ask the maintainer to collaborate with you on a fix. As a maintainer, please inform us about security issues in your own plugins, even if you fix the issue yourself. This lets us properly inform users
Inform us about plugin security updates without a corresponding security advisory. Plugin maintainers may be unaware of our process, so this helps ensure all security updates are properly announced.
You’re right about the race condition fix – it was treated as a bug rather than a formal vulnerability, and I appreciate the clarification.
The intention with @JenkinsSecurity is to complement the official efforts by aggregating existing resources (plugins, tools, best practices) in one place for easier discovery, especially for admins and developers looking to harden their instances.
I didn’t discuss it beforehand because I saw it as an independent community initiative (similar to other special interest groups or tools), but I completely understand the concern about potential confusion with the official security team.
I’m open to renaming the organization if that helps (suggestions welcome), or even collaborating directly with the security team on documentation/features if there’s interest.
I apologize for not consulting the security team or community beforehand – that was an oversight on my part, and I understand how the naming and approach could cause confusion.
My main goal has always been to contribute to and support the official Jenkins project. I have great respect for the work of the security team and would much prefer to collaborate directly with you on documentation, features, tools, or any ongoing efforts.
I’m happy to rename or even archive the organization if that helps, and contribute the existing resources through official channels.