39 мільйонів облікових даних витекло за один рік
Звіт GitHub Octoverse 2024 зафіксував 39 мільйонів секретів, що витекли на GitHub у 2024 році. Це зростання на 25% порівняно з попереднім роком відносно 2023-го. Серед секретів — API-ключі, рядки підключення до баз даних, токени автентифікації та хмарні облікові дані.
Причина відома. Розробники комітять код із секретами всередині. Ці секрети потрапляють туди під час сесій відлагодження. Або вони захардкожені замість того, щоб зберігатися у змінних середовища. При 39 мільйонах витоків це не рідкість. Це звична практика.
Інструменти ШІ додають другий канал витоків
Дослідження GitGuardian 2025 року показало, що 67% розробників випадково розкривали секрети у коді. Ті самі звички, що створюють витоки на GitHub, створюють і витоки через ШІ-інструменти.
Розробник вставляє код у Claude, ChatGPT або інший ШІ-асистент, щоб отримати допомогу. Цей код часто містить живі облікові дані. ШІ-модель отримує секрет. Вона може зберегти його в історії розмов. Вона відправляє його на сервери провайдера. Розробник втрачає контроль — без жодного попередження.
Три приклади:
Відлагодження бази даних. Розробник вставляє трасування стека. Трасування містить рядок підключення. ШІ зчитує і пароль теж.
Огляд конвеєра. Розробник ділиться скриптом конвеєра даних. Скрипт містить ключ доступу AWS та секретний ключ. ШІ отримує обидва.
Огляд API-інтеграції. Розробник просить переглянути інтеграцію. Код містить живий API-ключ партнера. Ключ покидає мережу розробника.
У кожному випадку мета є законною — отримати допомогу. Витік облікових даних є побічним ефектом надання ШІ достатнього контексту. Це той самий шаблон, що й витоки на GitHub — не зловмисний, просто звичний.
Конвеєри CI/CD стикаються з тим самим ризиком
Витоки секретів у CI/CD-конвеєрах зросли на 34% у 2024 році. Скрипти збірки, конфігурації розгортання та файли інфраструктури як коду тепер теж проходять перевірку за допомогою ШІ. Ці файли часто містять хмарні облікові дані та токени службових акаунтів.
Чим більше ШІ-інструменти охоплюють цикл розробки — огляд, документація, відлагодження, оптимізація — тим більше зростає поверхня атаки разом із ними.
Як архітектура MCP блокує витоки
Для команд, що використовують Claude Desktop або Cursor IDE, архітектура MCP-сервера (Model Context Protocol) розміщує фільтр облікових даних між розробником та ШІ-моделлю.
MCP-сервер обробляє весь текст, що проходить через сесію. Вставлений код, трасування стека, конфігураційні файли, контекст відлагодження — все це проходить крок анонімізації до того, як модель це побачить.
Двигун знаходить шаблони облікових даних: формати API-ключів, рядки підключення до баз даних, OAuth-токени, заголовки приватних ключів та власні формати, визначені вашою командою безпеки. Кожен збіг замінюється токеном перед передачею.
Як це виглядає на практиці:
Розробник вставляє трасування стека з рядком підключення до бази даних. MCP-сервер замінює рядок на [DB_CONNECTION_1]. ШІ бачить трасування з токеном на місці. Він надає допомогу з відлагодження на основі анонімізованої версії. Фактичний обліковий запис так і не покинув внутрішню мережу.
Це зупиняє той самий вектор витоків, що наповнює GitHub секретами. Канал інший — ШІ-інструменти, а не git-коміти — але виправлення працює так само: заблокувати до передачі.
Дивіться наш огляд безпеки про те, як anonym.legal справляється з цим в ШІ-інструментах і робочих процесах із документами, та центр відповідності для контролю аудиту.
Виявлення після факту — надто пізно
Деякі команди використовують сканування після коміту для виявлення витоків секретів. GitGuardian та truffleHog добре працюють для GitHub-каналу. Вони не охоплюють сесії ШІ-інструментів.
Коли секрет потрапляє на сервери провайдера ШІ, витік вже стався. Сканування знаходить його після. Анонімізація на рівні MCP зупиняє його від потрапляння до моделі взагалі.
39 мільйонів витоків на GitHub документують один канал. Витоки через ШІ-інструменти — це та сама проблема в каналі з меншим моніторингом та відсутністю журналу аудиту. Запобігання до передачі охоплює обидва.