Nikesh outlines responsible vulnerability disclosure practices
When a vulnerability is found, the researcher should first notify the owner of the affected code or product so they can investigate and prepare a fix, Nikesh said. He cautioned against third-party patches that could cause collateral damage and described several levels of patch deployment difficulty.
For a SaaS service, the provider can usually deploy a fix itself. When a patch is released for software installed by customers, they must adopt and deploy it, so not every affected system will be fixed immediately. Hardware is more difficult: a patch has to be developed, and customers must test and install it.
Next, according to Nikesh’s account, researchers notify relevant government bodies depending on the issue’s severity and then inform the industry. In one case he described, participants had 48 hours to prepare tools to distribute patches. Nikesh warned that response timelines are shrinking: in the future, there may not be several weeks to verify and fix a problem, and information about a major vulnerability could become public almost immediately.
Никеш описал практику ответственного раскрытия уязвимостей
При обнаружении уязвимости исследователь, по словам Никеша, должен сначала сообщить владельцу затронутого кода или продукта, чтобы тот мог проверить проблему и подготовить исправление. Он выступил против сторонних патчей, которые могут вызвать побочный ущерб, и описал несколько сценариев по сложности установки исправления.
В SaaS-сервисе поставщик обычно может сам развернуть исправление. Если исправление выпускается для программного обеспечения, которое устанавливают клиенты, им нужно самостоятельно принять и внедрить патч, поэтому не все уязвимые системы будут исправлены сразу. С аппаратным обеспечением процесс сложнее: патч нужно разработать, а клиентам — протестировать и установить его.
Далее, по описанию Никеша, исследователи уведомляют соответствующие государственные органы в зависимости от критичности проблемы, а затем информируют отрасль. В одном случае, о котором он рассказал, у участников было 48 часов, чтобы подготовить инструменты для распространения патчей. Никеш предупредил, что сроки реагирования сокращаются: в будущем на проверку и исправление может не остаться нескольких недель, а информация о крупной уязвимости может стать публичной практически сразу.