У публічних репозиторіях GitHub знайшли 543 тисячі чинних секретів

12 жовтня 2026 року, як пише Хабр, Truffle Security представила результати аналізу публічних репозиторіїв GitHub. Аналітики дослідили 224 млн репозиторіїв і 58 млрд файлів та виявили 543 тисячі токенів, ключів і паролів, які досі використовуються. Дослідження показує не лише масштаби публікації секретів у коді, а й те, як довго вони можуть залишатися у відкритому доступі.

Секрети залишаються відкритими роками

У середньому знайдені дані перебували у відкритому доступі 784 дні. Найстаріші виявлені ключі, які досі діяли, датувалися 2009 роком. Інакше кажучи, давня публікація не обов’язково стає з часом безпечною: важливо, чи було припинено доступ за опублікованими даними.

Частка чинних даних суттєво відрізнялася залежно від сервісу. Серед 101 886 знайдених токенів NPM чинним виявився лише один — близько 0,001%. Для GitHub результат становив 260 із 73 048 токенів, або 0,35%. Серед 30 437 токенів Hugging Face діяли 15 — приблизно 0,05%.

Для даних підключення до PostgreSQL співвідношення виявилося іншим: активними залишалися 11 465 із 12 985, або 88%. Для MySQL дослідники вказали частку 74%. У Google Cloud діяли 69 041 зі 126 963 знайдених даних — 54%; у SendGrid — 9 189 із 22 800, або 40%; у Docker Hub — 1 244 із 3 790, або 33%.

Різниця між цими показниками важлива для оцінки результатів. Велика кількість знайдених токенів сама собою не свідчить про те, скільки з них ще діє. Але й низьку частку чинних токенів одного сервісу не можна переносити на доступи до іншого: серед опублікованих даних підключення до PostgreSQL дослідники побачили зовсім іншу картину.

Що пропустило блокування під час надсилання коду

Близько 200 тисяч одиниць даних потрапили до репозиторіїв після того, як GitHub за замовчуванням увімкнув механізм блокування витоків під час надсилання змін. Він перевіряє вміст на етапі push і здатен розпізнавати токени низки популярних сервісів: GitHub, AWS, Slack, SendGrid, Stripe і GCP.

Судячи з результатів аналізу, цього недостатньо, щоб перехопити всі випадки публікації секретів. Частина даних містилася у форматах файлів, які механізм не підтримує, тому перевірка їх не розпізнала. Захист має й обмеження щодо типів даних: він пропускає параметри підключення до баз даних, ключі доступу до API Google і приватні ключі.

Для параметрів підключення до баз даних причину такого рішення вказано окремо — прагнення уникнути хибних спрацьовувань. Це пояснює обмеження, але не змінює його наслідків для репозиторію: опубліковані дані підключення можуть залишитися поза цією автоматичною перевіркою.

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

Що це означає для сайтів і команд

Практичний висновок для команди, яка веде публічний репозиторій, — перевіряти його на наявність секретів і з’ясовувати, чи залишаються знайдені дані чинними. Якщо доступ залишається активним, його потрібно своєчасно замінити. Видалити рядок із поточного файлу й припинити дію опублікованого секрету — різні завдання.

Власнику сайту не обов’язково розрізняти всі види токенів, щоб поставити команді конкретне запитання: чи перевіряли опублікований код і що зробили зі знайденими чинними доступами. Для розробника результати дослідження підказують, на що звернути увагу під час такої перевірки: серед знайденого можуть бути не лише токени сервісів, а й дані підключення до бази.

Моя думка: успішний push — не привід заспокоюватися

Я пишу свої перші застосунки на TypeScript і саме вчуся не перетворювати роботу з базою на пригоду, тому найбільше мене зачепив показник для PostgreSQL. Із знайдених даних підключення активними залишалися 88%. Для мене це вагомий привід уважніше переглядати власний код перед публікацією і не вважати, що очевидні токени — єдине, що може там опинитися.

Мені подобається сама ідея зупинити помилку під час надсилання змін: попередження на цьому етапі корисне. Але після цих цифр я б не сприймав відсутність попередження як підсумок перевірки. Мені спокійніше спочатку пошукати секрети в репозиторії, потім з’ясувати, чи діють знайдені доступи, і за потреби замінити їх. Автоматичне блокування допомагає, але звички перевіряти опублікований код воно мені не сформує.

Джерела

Звідки новина. Текст — переказ своїми словами, факти — з джерела, думка — автора.

1. Аналитики Truffle Security нашли в открытом доступе на GitHub 543 тыс. активных токенов, ключей и паролей habr.com

Про автора

Лев Істраті

початківець фулстек-розробник

Пишу перші застосунки на TypeScript і вчуся не перетворювати кожен запит до бази даних на пригоду. Зараз створюю каталог місцевих майстерень, щоб попрактикуватися з фронтендом і API.

Усі публікації автора