eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
BERLIN—How are security vulnerability disclosures handled in the open-source Kubernetes container orchestration and management system? That’s the question that was answered at length in a standing-room only session at the Kubecon/CloudNative EU conference in Berlin. Though the session had the somewhat whimsical title,’ Dance Madly on the Lip of a Volcano with Security Release Processes’ there is particular meaning behind the title.
“We’re constantly teetering on the edge of a volcano, where on one side we may fall in because of a security vulnerability,” Brandon Phillips, CTO of CoreOS said. “On the other side, we might fall down the mountain as we don’t have processes to deal with security vulnerabilities and we’re constantly afraid of the unstableness that lies on the other side of the volcano.”
The Kubernetes project has however taken multiple steps in recent months to improve its security disclosure processes. Google Software Engineer, Jessie Frazelle who co-presented in the session along with Philips noted that bugs are inevitable and it’s likely that more will be found in Kubernetes in the future. Phillips joked that the most secure computing system has already been invented—it’s just a basic calculator that isn’t connected to anything else. He added that once computing power is connected to the outside world, there is often an associated risk.
Frazelle noted that the users want software without bugs, but when there are bugs they want to know when fixes are available so they can update their applications. When it comes to security researchers, they want updates from vendors and projects after bugs are submitted and they also want defined timelines for disclosure.
For some types of high-severity security bugs, it’s often best for security information to remain embargoed until after a fix is available. Frazelle commented that the worst thing that can happen is that a bug becomes public before a fix and the bug gets its own nickname and logo.
“Every software bug needs a fun name, except any bug of mine,” she said.
There are a number of best practises for handling security disclosures that other open-source efforts already implemented, that Kubernetes has learned from. Phillips said that the Linux kernel developers have a policy of not negotiating with security researchers about disclosure timelines. Rather the best practise is often to just get a bug fixed as quickly as possible and then once it’s fixed to let users know about it.
Another best practise that other open-source projects have implemented is some form of early warning system for vulnerabilities. With such an approach, even though full details on the bugs are not provided as part of the early warning, users are given some advance notice so they will be more prepared to update as soon as a patch becomes available. Phillips and Frazelle also both emphasized that the security disclosure documentation for a project needs to be easily found by users doing a simple Google search. There also is a need for a dedicated security response team and some form of co-ordinated mailing list.
From a process perspective, Phillips said that the way Kubernetes works today, the security fix response team will typically respond to a security bug report within 24 hours. The fix for a security bug could take anywhere from one to seven days. Once the fix is done there is a ‘fix forthcoming’ notice sent to a Kubernetes user mailing list. Finally, the full patch disclosure and availability to distributions is completed within 14 days of the time the security bug report was made.
While Kubernetes does have a security disclosure process and policies in place, Frazelle and Philips said that there is room for improvement and a need for more participation from individuals and vendors.