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 <https://docs.google.com/document/d/1AnwVFpxZUsIwD_d_JiB2rhAKpAAmEzQim4X9FYV6iCw/edit#heading=h.gpz2xooy9cwi> Best regards, Oleg On Friday, February 5, 2021 at 11:53:28 AM UTC+1 Daniel Beck wrote: > 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/ > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/21c1e11e-7b47-4eba-9962-b76bcb914fa4n%40googlegroups.com.
