[Nominations Open] Jenkins Security MVP 2024 🏆

[kmartens27]

This issue is to receive nominations for the Jenkins Security MVP 2024. This award is presented to an individual most consistently providing excellent security reports or resolving security issues.

To nominate someone, reply to this issue with the following:

Full name of the person you’re nominating A short description of their contributions to Jenkins and why they should win. Nomination Deadline: Monday, February 19, 2024

Please note: Last year's winner, Daniel Beck, cannot win the award for Jenkins Security MVP again this year.

Voting will be open from Thursday, February 22 to Friday, March 22. Winners will be announced at cdCon 2024 (April 16 - 18).

More details are available here https://github.com/cdfoundation/foundation/blob/main/CDF%20Awards%20Guidelines.md

[Wadeck]

Full name: Yaniv Nizry (@Yaniv-git) Contribution: Main vulnerability of the January 24 security release. As the vulnerability was reported to Jenkins Security in November and the collaboration continues even after the release, I think it could count for 2023 or 2024 ;-) Links:

• https://www.jenkins.io/security/advisory/2024-01-24/#SECURITY-3314
• https://www.jenkins.io/blog/2024/01/25/sonar-vulnerability-report/
• https://www.sonarsource.com/blog/excessive-expansion-uncovering-critical-security-vulnerabilities-in-jenkins/

Additional (and more detailed) information from Daniel (thanks!):

In January 2024, for the first time in several years, we published fixes for a critical vulnerability in Jenkins, and it's thanks to Yaniv's report that we went through the effort of identifying it as such.

Yaniv's November 2023 report of two vulnerabilities in Jenkins was remarkable because it completely changed our understanding of the impact of merely being able to read file contents. When previously we announced those as leading to compromised confidentiality of data on disk, by creating an administrator's "remember me" cookie using information from the Jenkins file system it demonstrated much more severe impact. We were able to build on this new perspective, and it ultimately enabled us to provide administrators with detailed information about the potential risk to their environment, as well as workarounds for those unable to immediately update.

Throughout the entire process, Yaniv was great to work with and set an example in terms of responsiveness, collaboration, and willingness to share information.

[daniel-beck]

Alvaro Muñoz @pwntester

The Jenkins project currently uses custom code scanning rules defined using GitHub's CodeQL for the Jenkins Security Scan functionality, due to a lack of support for the Stapler web framework used in Jenkins when it was introduced.

In 2023, in an effort to improve the security of the OSS ecosystem, Alvaro and his colleague Tony Torralba added support for Stapler to the default rules of CodeQL. Demonstrating the success of their effort, they reported more than 30 vulnerabilities in various Jenkins plugins to us, including the popular Blue Ocean plugins. These vulnerabilities got addressed and published over the next few months (1, 2, 3, 4, 5, 6).

While the Jenkins Security Scan currently still uses the initial custom rules, their work demonstrates the power of CodeQL and shows us an interesting path forward for our own scan.

(Alvaro was credited for most of the vulnerabilities reported, so I'm nominating him. Sorry Tony!)

[alyssat]

⚠️ Nominations for this award is now closed. Thank you all for submitting your nominations.

Voting is open on February 22, closes on March 22.

The Jenkins Award voting is done by the community. Cast your vote HERE

[MarkEWaite]

Voting has concluded. Award winners will be announced at cdCon in Seattle, April 16-18 2024