However, Apple is not only slow at patching the WebKit engine itself, but also at integrating those fixes into all of its WebKit-dependent software.
Eiram pointed to the patching timeline for a WebKit vulnerability identified as CVE-2013-2909 as an example. That vulnerability was originally fixed in Chrome on Oct. 1, 2013, then Apple patched it in Safari 6.1.1 and 7.0.1 on Dec. 16, 2013 (two-and-a-half months later); in iOS 7.1 on March 10 (five months later), and finally in Apple TV 6.1 on April 22 (six-and-a-half months later).
"The lack of coordination between Google and Apple is one thing," Eiram said. "However, Apple releasing fixes for vulnerabilities in some of their products while leaving other of their products vulnerable for a long time is a very curious practice that I strongly disagree with. It's unacceptable that they're putting their own users at risk like that."
Apple did not immediately respond to a request for comment.
Other vendors have faced criticism in the past for similar patching practices. For example, vulnerabilities patched in Flash Player used to remain unfixed for weeks in Adobe Reader, which bundled Flash Player as a library called authplay.dll. Adobe eventually removed the authplay.dll component from Adobe Reader starting with version 9.5.1.
One of the few cases when it can be acceptable to push out a security patch for one product while leaving others vulnerable is if a 0-day vulnerability was being actively exploited to target users of that product, but not users of the other products, Eiram said. However, even in such a case of immediate threat, the vendor shouldn't wait too long before patching the rest of its products as well, he said.
Sign up for Computerworld eNewsletters.