ИИ используется для обнаружения проблем безопасности
Несколько дней назад, Даниэль Стенберг (автор Curl) сделал это известным в вашем блоге, Почта в котором оно выражается не только как критикует использование инструментов искусственного интеллекта, но в форме жалобы, неудобств, которые это создает для него и его команды, отчетов безопасности, созданных инструментами искусственного интеллекта.
И в своей публикации Дэниел Стенберг упоминает, что в течение многих лет процесс проверки всех отчетов и их отбраковки между «мусором» и «настоящими» проблемами безопасности, Это не требовало дополнительных усилий., поскольку в нем упоминается, что «нежелательные отчеты обычно очень легко и быстро обнаруживаются и удаляются».
С недавним появлением искусственного интеллектаМногие задачи, которые раньше требовали многих часов человеческого вмешательства, подверглись революционному преобразованию. Среди наиболее упоминаемых случаев в этом блоге мы затронули темы ИИ, предназначенные для программирования, генерации изображений и редактирования видео, таких как ChatGPT, Copilot, Bard и других.
В конкретной области программирования Copilot вызвал многочисленные критические замечания, основная проблема заключалась в возможности судебных исков. Однако на другом конце шкалы вмешательство искусственного интеллекта существенно изменило различные области. Например, ИИ сыграл решающую роль в обнаружении ошибок и проблем безопасности в коде. Многие люди используют эти инструменты для выявления потенциальных ошибок и уязвимостей в коде, часто участвуя в программах вознаграждений за обнаружение проблем безопасности.
Керл не избежал этой тенденции, и Дэниел Стенберг выразил мнение в своем блоге это, После нескольких месяцев сдерживания своего мнения он наконец взорвался. не согласны с использованием инструментов искусственного интеллекта. Причина вашего разочарования Это был растущее число «мусорных» отчетов, создаваемых с помощью этих инструментов.
В публикации подчеркивается, что Эти отчеты имеют подробный вид, написаны нормальным языком и выглядят качественно. Однако без тщательного анализа они оказываются вводящими в заблуждение. поскольку они заменяют реальные проблемы некачественным контентом, который кажется ценным.
В рамках проекта Curl, предлагающий вознаграждение за выявление новых уязвимостей., получил в общей сложности 415 сообщений о потенциальных проблемах. Из этого набора только 64 были подтверждены как реальные уязвимости, 77 описали ошибки, не связанные с безопасностью, и, что удивительно, 274 (66%) не содержали полезной информации, съедают время разработчиков, которое можно было бы потратить на что-то полезное.
Разработчики вынуждены тратить много времени на анализ бесполезных отчетов и многократную проверку содержащейся в них информации, поскольку внешнее качество дизайна создает дополнительное доверие к информации и возникает ощущение, что разработчик чего-то не понял.
С другой стороны, формирование такого отчета требует минимальных усилий со стороны запрашивающего, который не удосуживается проверить наличие реальной проблемы, а просто слепо копирует данные, полученные от ИИ-помощников, надеясь на удачу. в борьбе за получение награды.
Дэниел Стенберг, Поделитесь двумя примерами такого типа отчетов о мусоре:
- В первом случае, незадолго до запланированного в октябре обнародования информации о критической уязвимости, через HackerOne был получен отчет о том, что уже существует общедоступный патч для решения проблемы. Однако отчет оказался «фейковым», поскольку содержал данные об аналогичных проблемах и фрагменты подробной информации о прошлых уязвимостях, собранные помощником Google по искусственному интеллекту Бардом. Хотя информация казалась новой и актуальной, ей не хватало связи с реальностью.
- Во втором случае было получено сообщение о переполнении буфера при обработке WebSocket. Этот отчет поступил от пользователя, который уже сообщал об уязвимостях в нескольких проектах через HackerOne. Чтобы воспроизвести проблему, в отчете представлены общие инструкции по отправке измененного запроса и пример исправления.
Несмотря на тщательную тройную проверку кода, разработчик не обнаружил никаких проблем. Однако, поскольку отчет был написан таким образом, чтобы вызвать «некоторое» доверие и даже представил предлагаемое решение, ощущение, что что-то не складывается, сохранялось.
Чтобы прояснить, как пользователю удалось обойти проверку размера, отмечается, что пояснения не содержали никакой дополнительной информации, а лишь обсуждали очевидные распространенные причины переполнения буфера, не связанные с кодом Curl. Ответы напоминали общение с ИИ-помощником, и после тщетных попыток выяснить, как именно проявляется проблема, Дэниел Стенберг окончательно убедился в том, что никакой уязвимости на самом деле не существует, и закрыл тему как «неприменимую».
Наконец, если вы заинтересованы в том, чтобы узнать больше об этом, вы можете ознакомиться с подробностями в по следующей ссылке.