Архив метки: HackerOne

"Slop" стало главным словом 2025 года по мнению редакторов словаря Merriam-Webster

Добавить комментарий

Slop стало главным словом 2025 года по мнению редакторов словаря Merriam-Webster

"Slop" стало главным словом 2025 года по мнению редакторов словаря Merriam-Webster. Первоначальное значение этого слова "мягкая грязь", но теперь им обозначают "цифровой контент низкого качества, который обычно производится в большом количестве с помощью искусственного интеллекта".

Пару недель назад Daniel Stenberg, основатель опенсурсного проекта curl, поделился статистикой по багрепортам на HackerOne. Из статистики видно, что количество подтверждённых уязвимостей падает, а общее количество репортов год от года растёт, в том числе из-за стремительного роста генерённого AI Slop-а.

Daniel Stenberg видит проблему в попытках багхантеров использовать неподходящие AI-инструменты:

"AI-чат-боты всегда отвечают, никогда не говорят «нет» и отчаянно стремятся угодить. Им задают вопрос - и они выдают ответ. Очень часто они его просто выдумывают. Они лгут. Люди, которые так ими пользуются, не умеют выявлять и отделять ложь от правды и, по сути, даже не пытаются этого делать."

Почему участники багбаунти нашли в прошлом году 65 тысяч уязвимостей, а CVE зарегистрировано за это время только 25 тысяч?

1 комментарий

Почему участники багбаунти нашли в прошлом году 65 тысяч уязвимостей, а CVE зарегистрировано за это время только 25 тысяч?

Почему участники багбаунти нашли в прошлом году 65 тысяч уязвимостей, а CVE зарегистрировано за это время только 25 тысяч? Подсмотрел занимательный вопрос в канале Алексея Лукацкого.

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

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

В принципе, ничего не мешает сделать багбаунти программу вообще для любых приложений. Например, на hackerone есть багбаунти для Chrome/Chromium. И для этих уязвимостей Google заводит CVE. Ничего не запрещает самому вендору заводить CVE под найденные в рамках багбаунти уязвимости кроме нежелания этого вендора.

И не сказать, что это требует каких-то особенных усилий со стороны вендора, т.к. сама багбаунти платформа может заводить CVE уязвимости для своих клиентов. В списке CVE Numbering Authority (CNA) есть 11 организаций типа "Bug Bounty Provider", включая Bugcrowd, HackerOne, ZDI:

"Provides CVE IDs for its customers as part of its bug bounty and vulnerability coordination platform"

В общем, уязвимостей меньше, потому что не для всех уязвимостей есть смысл заводить CVE. А для тех уязвимостей, для которых смысл есть, CVE идентификаторы не заводят, т.к. сам вендор уязвимого продукта этого не хочет. 🤷‍♂️ А сам исследователь хоть и может добиться заведения CVE идентификатора помимо воли вендора, но это не массовая история.

PS: хороший вопрос для собеседования VM-щиков 😉