Один із найважливіших open source‑проєктів у світі — Curl та бібліотека libcurl — оголосив про поетапне закриття своєї bug bounty-програми на платформі HackerOne. Ініціатором рішення став засновник та головний розробник Curl Данієль Стенберґ, який пов’язує цей крок з різким зростанням кількості низькоякісних, часто AI‑згенерованих звітів про вразливості.
Чому закриття bug bounty Curl важливе для екосистеми кібербезпеки
Curl і libcurl є критично важливими компонентами інтернет‑інфраструктури: вони використовуються у вбудованих пристроях, десктопних застосунках, контейнерах, хмарних сервісах і CI/CD‑ланцюгах. Будь-які проблеми з якістю процесу розкриття вразливостей у таких проєктах напряму впливають на безпеку тисяч продуктів та сервісів.
Рішення відмовитися від bug bounty на великій платформі HackerOne демонструє ширшу тенденцію: штучний інтелект різко знижує «сигнал/шум» у програмах винагород. Масова генерація формальних, але по суті порожніх звітів руйнує економіку ручної верифікації й змушує проєкти переглядати підходи до взаємодії з дослідниками.
Як саме Curl закриває bug bounty на HackerOne
Стенберґ анонсував поступове згортання програми. До 31 січня 2026 року Curl продовжить приймати репорти через HackerOne, а всі відкриті тікети буде доведено до завершення.
Починаючи з 1 лютого 2026 року, проєкт повністю припиняє прийом нових звітів на цій платформі та переходить до прямої моделі responsible disclosure через GitHub — без посередництва класичної bug bounty‑платформи.
AI slop: як ІІ перевантажив команду безпеки Curl
Проблема, яку Стенберґ описує як «AI slop», тобто потік поверхневих, слабо обґрунтованих звітів, активно проявилася вже у 2024 році. За його оцінкою, близько 20% усіх повідомлень тоді генерувалися за допомогою систем штучного інтелекту.
Найбільш тривожним став не сам факт використання ІІ, а обвал валідності: орієнтовно тільки близько 5% репортів містили реальні вразливості. Решта або описувала неексплуатовані сценарії, або взагалі базувалася на хибному розумінні функціоналу Curl.
Команда безпеки Curl складається лише з семи учасників. Кожен звіт потребував участі 3–4 рецензентів і займав від 30 хвилин до трьох годин на аналіз і відтворення. У січні 2026 року навантаження стало критичним: за перші 16 годин одного з тижнів проєкт отримав сім нових звітів через HackerOne, а протягом половини місяця було опрацьовано понад 20 — жоден не підтвердив реальну вразливість.
«Прибрати стимул» для сміттєвих звітів
За словами Стенберґа, головна мета відмови від bug bounty на HackerOne — прибрати фінансовий стимул для подання беззмістовних репортів. Формат (створено ІІ чи людиною) не має значення, якщо звіт не додає цінності, а лише спалює час мейнтейнерів.
Він визнає, що повний вихід із HackerOne не зупинить усі слабкі звіти, однак для невеликого open source‑проєкту це необхідний крок, щоб зберегти працездатність команди та уникнути професійного вигорання.
Оновлений security.txt та відмова від грошових винагород
Команда Curl також оновила файл security.txt — стандартний механізм публікації офіційних каналів зв’язку з питань безпеки. У новій редакції прямо вказано, що проєкт більше не виплачує грошові винагороди за знайдені вразливості і не сприяє отриманню компенсацій від третіх сторін.
Додатково мейнтейнери попереджають: відверто сміттєві звіти можуть призвести до блокування автора та публічної дискредитації. Це нетипово жорсткий, але показовий сигнал щодо ставлення до AI‑спаму в безпекових каналах.
Що буде замість HackerOne та як це змінює роль дослідників
Після лютого 2026 року звіти про вразливості в Curl прийматимуться через пряму responsible disclosure на GitHub. Дослідники зможуть контактувати з мейнтейнерами без посередників, що спрощує комунікацію для тих, хто дійсно працює із кодом.
Водночас зникає фінансовий мотив, який для багатьох фахівців з безпеки був ключовим. З 2019 року через HackerOne та ініціативу Internet Bug Bounty за 81 підтверджену вразливість у Curl і libcurl було виплачено понад 90 000 доларів. Тепер акцент зміщується від монетизації до співпраці заради стійкості всієї екосистеми.
Уроки для bug bounty-програм в епоху штучного інтелекту
Кейс Curl яскраво демонструє, що масові AI‑згенеровані звіти здатні зламати економіку bug bounty-програм. Створити псевдотехнічний репорт тепер майже безкоштовно, тоді як його перевірка вимагає годин роботи кваліфікованих інженерів безпеки.
Щоб зменшити цей дисбаланс, операторам програм винагород — як комерційним компаніям, так і open source‑проєктам — доцільно впроваджувати механізми попередньої фільтрації: жорсткіші шаблони звітів, обов’язкові PoC з відтворюваними кроками, чіткі мінімальні критерії впливу, а також контрольні питання, які складно коректно заповнити без реальної експертизи.
Дедалі більш затребуваними стають закриті або багаторівневі bug bounty‑програми з доступом лише для перевірених дослідників. Це дозволяє утримувати прийнятний рівень шуму та фокусувати ресурси на дійсно критичних знахідках.
Ситуація з Curl нагадує, наскільки обмежені ресурси навіть у широко використовуваних open source‑проєктів. Організаціям варто переглянути власні програми винагород і політики responsible disclosure, а також навчити команди безпеки працювати з інструментами штучного інтелекту так, щоб вони підсилювали аналіз, а не генерували спам. Інвестуючи у якість звітів, чіткі правила і здорову взаємодію з дослідницькою спільнотою, можна зберегти ефективність bug bounty‑програм навіть в умовах стрімкого розвитку ІІ.
