“In the history of the Jenkins project, we’ve had 8 vulnerabilities reported with co-ordinated disclosure deadlines – all in the second half of 2018.”

JAXenter: 2018 has been a particularly tough year for open source on the security front and Jenkins, unfortunately, was not the exception. Why do you think we saw these many vulnerabilities this year?

Tracy Miranda: Back in 2014 Heartbleed was the first security vulnerability with a name and a cool logo. Then in early 2018, we had Spectre and Meltdown grabbing the headlines. As long as there has been useful software there have been vulnerabilities – as an industry, we just haven’t cared that much. Nowadays, there is definitely more awareness in the industry around security vulnerabilities, the consequences and the need to do better. This is a good thing, given how pervasive and complex modern software is.

From the Jenkins side, we are seeing that this increased awareness has led to a couple of things. Firstly, an increased professional involvement in security. I’ve learned from Daniel Beck, the Jenkins security officer that over the last couple of years the project has gone from just a handful of researches reporting vulnerabilities to many more, either independent security researchers or professional teams that are part of big companies. The increased professional involvement leads to the second trend which is that the vulnerabilities are now being reported with co-ordinated disclosure deadlines. In the history of the Jenkins project, we have had 8 vulnerabilities reported with co-ordinated disclosure deadlines – and these were all in the second half of 2018. Fortunately, my employer CloudBees invest heavily in the Jenkins open source community and are committed to working with the contributors, users and partners to serve up a more secure Jenkins.

JAXenter: Let’s talk a bit more about a crucial Jenkins vulnerability that was discovered some months ago,  CVE-2018-1999001. As mentioned by the Jenkins team, this issue was caused by the fix for SECURITY-499 in the 2017-11-08 security advisory. How did this happen exactly?

Tracy Miranda: Again, any useful code runs the risks of security vulnerabilities – that’s something we don’t say often enough in this industry – and software fixes are just code themselves.

The Jenkins project takes security seriously. The security team strives to fix all security vulnerabilities in Jenkins and plugins in a timely manner. The focus is on fixing the vulnerability while keeping the fix simple, so the minimal code to address the issue and limit the risk of introducing additional bugs. We want to give Jenkins admins the confidence that they can upgrade for a security advisory and not worry that things will not work.

One thing that the people and companies who use Jenkins really do value is the reputation the project has built over the years. Jenkins is the most popular tool for CI/CD and this comes with big benefits. For example, recently we have had the trend of new security scanning tools – each of these security scanning tools such as Anchore, AquaSec, Snyk – integrate with Jenkins first and make Jenkins plugins available. Jenkins users always have access to cutting edge security tooling first.

SEE ALSO: Jenkins community survey: Kubernetes usage rises 235% & Java crowned most used language

JAXenter: A fix has been issued for this vulnerability for many months already, however, a recent article written by Catalin Cimpanu brings an alarming reality into light: the fact that not all server owners have bothered to install this security update. Why do you think this is the case and does the Jenkins team have any means of dealing with this phenomenon?

Tracy Miranda: This is another reality of software that we see all the time, for instance, how many machines with Windows XP are still being used even years after its end-of-life? Or more recently unprotected AWS S3 buckets are vulnerable – to the point ethical hackers go in and leave friendly warning messages.  Users usually are much more conscious of the immediate risks of breaking their working systems, losing time upgrading or dealing with security than the seemingly distant threat of a security breach. So it is all about educating users to take a long term approach and also making it easier to do.

Since early 2017 Jenkins has had security warnings in the user interface to clearly inform admins that they are running insecure plugins or an insecure version of the core. The Jenkins project operates a dedicated mailing list for security-related notifications, and also sends updates to the general oss-security mailing list and we also tweet about security advisories regularly to ensure we have the best chance of catching our user’s attention. CloudBees, who offer enterprise Jenkins through CloudBees Core will also take the extra step to inform customers and work closely with them and partners to get the message out.

The Jenkins project always makes a continuous effort to improve security efforts. In fact just this year Jenkins became a CVE numbering authority (CNA). If there were any more ideas of what we could do to improve or help those as-yet unprotected servers I’d love to hear them! Just to finish, all open source projects that people are using and building on top of need proper care and funding and its in everyone’s interest that we all work together to keep software as secure as possible.

Thank you very much!

The post “In the history of the Jenkins project, we’ve had 8 vulnerabilities reported with co-ordinated disclosure deadlines – all in the second half of 2018.” appeared first on JAXenter.