Токсичные сканеры: как автоматизация разрушает open source

В последние недели наблюдается увеличение количества некачественных отчетов о безопасности, которые отправляются в открытые проекты. Сообщения на первый взгляд могут показаться настоящими угрозами, но требуют много времени, чтобы доказать их беспочвенность. Проекты, такие как curl, также столкнулись с аналогичной проблемой.

Часто такие отчеты создаются с помощью автоматических инструментов для сканирования безопасности, которые не проверяют результаты должным образом. Например, недавно проект urllib3 получил отчет, в котором утверждали, что использование SSLv2 — это уязвимость, хотя на самом деле проект использует данный протокол только для его отключения.

В чем проблема для разработчиков?

Проблема заключается в том, что такие отчеты поступают в тысячи проектов с открытым исходным кодом. Из-за того, что многие вопросы безопасности конфиденциальны, разработчики не могут легко обсудить проблемы или попросить помощи. Время, которое специалисты могут потратить на анализ таких сообщений, ограничено.

Ответ на такие отчеты — это трудоемкий и дорогостоящий процесс. В открытых проектах безопасность часто не является главной целью разработчиков, которые больше заинтересованы в улучшении функций, и воспринимают безопасность как необходимую меру для защиты пользователей. Однако пустые или некачественные отчеты отнимают много времени и создают ненужную нагрузку на разработчиков.

Со временем проблема может привести к стрессу и усталости у тех, кто поддерживает проекты. В результате разработчики могут начать игнорировать реальные угрозы, что ослабляет общую безопасность.

Что могут сделать платформы?

Платформы, которые принимают отчеты о безопасности, должны внедрить механизмы, чтобы предотвратить автоматическую или чрезмерную отправку отчетов. Например, можно добавить CAPTCHA или ограничить количество отчетов, которые можно отправить за определенное время. Также важно дать возможность публиковать отчет без регистрации уязвимости, чтобы разработчики могли открыто обсуждать такие случаи.

Если кто-то хочет отправить отчет, важно использовать проверенные методы. Например, нельзя полагаться на искусственный интеллект для поиска уязвимостей — такие системы не могут в полной мере понять код. Все отчеты должны проверяться людьми.

Исследователям безопасности не стоит заваливать проекты множеством отчетов без предварительного анализа. Кроме того, важно не ограничиваться только сообщениями об уязвимостях, но и предоставлять исправления, что значительно облегчит работу разработчиков и повысит эффективность совместной работы.

Если разработчик получает сомнительный отчет, ему стоит кратко запросить дополнительные пояснения и, при необходимости, закрыть такой отчет. Если ответа не последует, можно смело продолжить работу, не тратя время зря. Также стоит обратить внимание на исследователей с новыми аккаунтами или тех, кто уже отправлял некачественные отчеты. Это может быть сигналом о недобросовестности.

Несмотря на все сложности, большинство исследователей отправляют отчеты о безопасности с хорошими намерениями. Проблемы возникают, скорее, из-за недостатка опыта или неверного подхода, чем из-за попыток навредить проектам.