Jenkins 2023 Recap

Contributed by: Wadeck Follonier

The Jenkins Security team has multiple missions, with the most visible to users being the publication of advisories.

In 2023, the team published 17 advisories: 4 included Jenkins core, and 13 were solely about plugins. In total, 211 vulnerabilities were announced.

In terms of reporting trends, we have seen an increase in people reporting CVEs originating from dependencies. Our position on this issue is that when analyzing CVEs, if they are impacting we correct them and publish an advisory; otherwise, we publish a blog post only for the most popular ones, such as Spring4Shell or Log4Shell. With dozens of CVEs published every month, we prefer not to publish information for each one unless it is relevant.

To reduce the occurrence of those issues and provide reporters with a point of reference, we have updated the security policy in Docker.

We would also like to extend our gratitude to the GitHub Security Lab for reporting 27 vulnerabilities through their CodeQL rules and for their collaborative efforts in both the analysis and the enhancement of our tools.

The team does not rely solely on “external” security researchers to find vulnerabilities; a considerable amount of time during the year is spent on proactively auditing the code. This year was marked by some specific research areas: OAuth flow and disabled SSL validation, in addition to the usual CSRF, XSS, or XXE vulnerabilities.

Additionally, we have expanded the scope of our security reviews for Pull Requests, particularly in Jenkins core. Approximately 70 PRs were labeled as “security-approved”. This proactive measure allowed the team to prevent the introduction of some vulnerabilities, which is significantly less costly than addressing them after they have been incorporated into the production code.

As part of our mission, raising community awareness about security is also a key factor in reducing the introduction of vulnerabilities at an early stage. In this regard, we welcomed Andrea to our security team for a summer internship from June to August. By the end of it, he had successfully reported 28 vulnerabilities. For more information about his internship, you can read his blog post.

Education and tooling are closely related for us. We are investing time to propose new security automation and to improve our existing tooling. This year, we introduced the existing CodeQL ruleset for hosting requests. This provided future maintainers with detailed explanations of the findings. Along with this effort, we also enhanced our security scan by supporting warning suppression through code annotation.

Continuing with tooling improvements, we added a beta feature to the bot present in SECURITY tickets, allowing maintainers to block or unblock releases of their plugins. The intent of this feature is to reduce the likelihood of an involuntary release when one is staged in private for a future advisory.

We also introduced the possibility of having an exclusive CD mode. This option allows maintainers to force all releases of their plugins to be done through the official CI, reducing the risk related to their laptops being compromised.

Nowadays, AI is everywhere. For security, it’s often a bit more complicated due to the aspect of confidentiality. To circumvent this while still delving into the topic, we have been using OpenAI API since October to triage the new JENKINS tickets. It’s the public tracker for Jenkins, but sometimes, vulnerability reports are wrongly submitted there. AI has helped us detect whether something is security-related and thus expands our scope without needing to monitor everything. This approach has proven to be quite successful after three months.

Along with other small projects, we continue to work on more long-term/background projects, such as the introduction of the Content-Security-Policy header. Throughout the year, we made significant progress in covering the core usage of inline JavaScript.