2021 priorities for Jenkins - Security

[Oleg Nenashev]

Hi all,

To follow-up on the Jenkins Governance meeting we had last week, I'd like to continue the discussion about Jenkins security which was suggested as one of 2021 priorities. In this thread I propose to discuss ideas w.r.t improving security of Jenkins components and software supply chains. NOTE: Please do not reference unfixed security issues in this thread (reporting vulnerabilities). 

Current state. Jenkins Security Team is doing a great job w.r.t. addressing security issues. In 2020 we had 19 security advisories with 198 fixed vulnerabilities and 72 disclosed ones. There were great additions to devtools: Dependabot, GitHub CodeQL, Find-Sec-Bugs, etc. Also, new plugin hosting requests now get on-demand security reviews before being published. All of that is a great progress compared to the state we had several years ago.

What’s next? With all the recent events, security of the software delivery chain is in the spotlight for the many organizations. Jenkins is a key part of this chain for many users, and for sure we want to keep it that way. It is not “just” about timely fixing security issues and preventing misconfiguration. We are also interested to keep our own delivery processes in the best possible shape.

Some ideas we discussed at the meeting:

• Growing security awareness among contributors so that the new code and documentation get developed with security in mind.
• Expanding developer tooling. It would help to automate, and, when relevant, enforce preferred security practices in Jenkins components.
  • Examples: release automation infrastructure, adopting more analysis tools in the default pipelines. With a great start in previous years, we could definitely do more by using available tools and sponsorships.
• Getting more contributors involved in the security effort. It is not only about delivering the security fixes. Many topics could be discussed publicly in SIGs and sub-projects, e.g. hardening Docker images, demonstrating security tools with Jenkins, and so on. Contributors could also help with security reviews
• // Add your ideas in replies!

What do you think about these items? Would you like to suggest more additional areas where we could improve? Any feedback would be appreciated.

Best regards,
Oleg Nenashev

[Oleg Nenashev]

Just a quick follow-up to this thread, there is ongoing discussion about hosting a contributor summit after FOSDEM.

Should it happen, I suggest having a security track/section there. We had a similar one last year in Brussels, and IIRC it went quite well.

Ideas/comments and topic suggestions are welcome :)

[Olblak]

Thanks, Oleg for putting down this, I would definitely be interested to chat during the contributor summit about this topic.

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/ea30b90e-c2ee-433f-868d-384793350481n%40googlegroups.com.

[Matt Sicker]

Getting together to define some secure setup guidelines for users
would be useful, too. It's not that helpful that Jenkins and its
plugins are more secure if users end up configuring Jenkins insecurely
in the first place!

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/735b71c9-6321-41a0-b3cc-7c13177ac66e%40www.fastmail.com.



--
Matt Sicker
Senior Software Engineer, CloudBees

[Daniel Beck]

Hi Oleg,


Thanks for getting this started! Unfortunately I missed the meeting in which this was discussed, but some of this nicely extends things I tried to get started but simply haven't had the time for.

Some thoughts:

> Expanding developer tooling. It would help to automate, and, when relevant, enforce preferred security practices in Jenkins components.

I've looked into extending the InjectedTest to cover common error causes. One such attempt[1] tries to make sure people think about the verbs they make web methods accessible with. All that's needed to make this viable is something like [2] in individual plugins. A potential problem with failing builds is that it puts pressure on maintainers to "just make it work" and that may end up negating the benefits entirely (in this example to put "@GET @POST" even on something that shouldn't be GET-accessible).

Another work in progress is code scanning using CodeQL with Jenkins-specific rules. While maintainers could (and should) run whatever generic tools they like, this is the one focused on Jenkins (well, Stapler mostly). This project is ongoing and has had some success already, as I wrote about[3]. I hope to open up the rules later this month, but even now people can ask for invitations to participate in the rules writing. I think Alex is already using these for hosting request reviews. The benefit with such an approach is that it's generally nonblocking for development unless you decide you want that as a maintainer.

> Getting more contributors involved in the security effort. It is not only about delivering the security fixes. Many topics could be discussed publicly in SIGs and sub-projects, e.g. hardening Docker images, demonstrating security tools with Jenkins, and so on. Contributors could also help with security reviews

The security team occasionally is in a situation in which we want input from the larger community. Way back when we did this sort of ad-hoc when we killed off the wiki integration into the update center to prevent depublishing of plugins, or introduced upload permissions. There are parts of Jenkins where the decision whether to document something as being not great, or whether to fix it in a potentially painful way is difficult. Recent regressions also feel like maybe we should have an extended group of testers for proposed security fixes to ensure they're safe.

This all nicely aligns with your suggestions, so I'm all for us doing more of this.


Daniel


1: https://github.com/jenkinsci/jenkins-test-harness/pull/133
2: https://github.com/jenkinsci/matrix-auth-plugin/pull/99
3: https://www.jenkins.io/blog/2020/11/04/codeql/

[Oleg Nenashev]

Hi all,

We will have a "Securing Jenkins Delivery Pipelines" track at the Jenkins contributor summit on Thursday, Feb 25, noon-1:30PM UTC.

• Zoom Link:  https://zoom.us/j/95649564362?pwd=eTV1ZVpqVk5PVFY1Wi9uMFJLVFkrdz09

• Passcode: 337043

• Meeting notes: https://docs.google.com/document/d/1AnwVFpxZUsIwD_d_JiB2rhAKpAAmEzQim4X9FYV6iCw/edit#heading=h.gpz2xooy9cwi 

Best regards,

Oleg