Дослідники Truffle Security повідомили про 543 699 унікальних облікових даних із публічних репозиторіїв GitHub, які успішно пройшли автентифікацію під час перевірки 27-28 липня 2026 року. Результат показує не всі витоки на платформі, а іншу проблему: секрет може давно зникнути з видимого коду, але залишатися дійсним, доки його власник не відкличе доступ.
Перевірка охопила 224 553 295 публічних репозиторіїв
За даними дослідження Truffle Security, аналізували знімок 224 553 295 публічних репозиторіїв із понад 58,4 млрд файлів. Для цього використали набір The Stack v3, збір якого завершився 7 серпня 2025 року.
Саме тому цифра 543 699 не описує повний поточний стан GitHub і не є кількістю всіх секретів, що коли-небудь ставали публічними. Це кількість унікальних облікових даних, які лишалися дійсними під час окремої перевірки в липні 2026 року.
Медіанний строк дійсності секрету становив 784 дні
Медіанний час, протягом якого дійсний секрет перебував у публічній основній гілці репозиторію, становив 784 дні. Найстаріший дійсний обліковий даний у вибірці додали комітом ще у 2009 році.
Ці строки не доводять використання ключів зловмисниками і не означають, що кожен із них відкривав критичний доступ. Однак вони вказують на системну прогалину в процесі відкликання облікових даних після їхнього потрапляння до коду.
Видалення секрету з коду не скасовує доступ
Сканування секретів і механізми, що обмежують випадкову публікацію чутливих даних, можуть виявити проблему або не допустити новий витік. Але вони не можуть самостійно зробити вже виданий ключ недійсним у сервісі, який його приймає.
Якщо токен, пароль або ключ уже потрапив у коміт, його просте видалення з файлу не змінює статус доступу. Вирішальним кроком є відкликання облікових даних у постачальника сервісу та випуск нових.
Відкликання у постачальника має бути першим кроком після витоку
Для команд, що знайшли секрет у власному публічному репозиторії, пріоритет має бути таким:
- відкликати скомпрометовані облікові дані у відповідному сервісі;
- замінити їх новими та перевірити, де саме секрет потрапив до коду;
- застосовувати перевірки секретів до комітів і публікацій, не зберігати ключі у файлах конфігурації;
- обмежувати права доступу та використовувати короткоживучі токени там, де це можливо.
Виявлення витоку є лише початком реагування. Без відкликання старого ключа навіть давно очищений репозиторій може залишатися джерелом робочого доступу.