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 :)


On Tuesday, January 19, 2021 at 9:02:51 AM UTC+1 Oleg Nenashev wrote:

> Hi all,
>
> To follow-up on the Jenkins Governance meeting 
> <https://docs.google.com/document/d/11Nr8QpqYgBiZjORplL_3Zkwys2qK1vEvK-NYyYa4rzg/edit#bookmark=id.ypwngla6o9i9>
>  
> 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 
> <https://www.jenkins.io/security/reporting/>). 
>
> *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
>

-- 
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/ea30b90e-c2ee-433f-868d-384793350481n%40googlegroups.com.

Reply via email to