Корпоративная инфраструктура держится на учётных данных, которые связывают сотрудников, приложения, облака, внутренние сервисы, автоматизацию и ИИ-агентов. Этот слой разрастается быстрее, чем службы безопасности успевают его учитывать. По словам операционного директора GitHub Кайла Дейгла, за весь 2025 год платформа зарегистрировала около 1 млрд коммитов, а к августу 2026 года их число достигло 2,9 млрд. В пересчёте на год темп превысил 14 млрд коммитов, то есть речь уже идёт о сотнях миллионов изменений кода в неделю. Инженерная команда GitHub прежде готовила инфраструктуру к десятикратному росту, теперь ориентир поднят до 30-кратного из-за распространения агентной разработки. В исходных данных встречается и формулировка «в шесть раз быстрее, чем число активных разработчиков», но без указанного предмета сравнения; по контексту она относится к опережающему росту объёма программной разработки.
Чем больше кода, тем больше приложений, интеграций, облачных ресурсов и систем, которым приходится удостоверять друг друга. В 2025 году в публичных коммитах GitHub появились 65 млн новых жёстко прописанных секретов, на 34% больше, чем годом ранее. Число утечек учётных данных, связанных с ИИ-сервисами, выросло на 81%. Секрет при этом редко остаётся в одном месте. Разработчик может создать ключ в разрешённой облачной учётной записи, записать его открытым текстом в репозиторий, вставить в базу знаний и сохранить управляемую копию в хранилище. Ещё несколько копий останутся на ноутбуке. «Гражданские разработчики», получившие доступ к агентам для написания кода, добавляют сюда личные проекты и недавно подключённые ИИ-сервисы.
Внутренний статус системы не гарантирует чистоты: внутренние репозитории примерно в шесть раз чаще публичных содержали хотя бы один секрет. Там оседают ключи от облачных сред, внутренних приложений, тестовых стендов и служебных API. Удаление значения из текущей версии файла тоже мало что решает, если оно сохранилось в истории Git, другой ветке, форке, соседнем репозитории или скопированном файле. Публичная утечка окончательно выводит секрет за пределы контроля компании, причём обнаружить её сразу удаётся не всегда. Около 28% инцидентов с секретами вообще возникли вне репозиториев: в чатах, системах совместной работы, тикетах поддержки и общих базах знаний, где пароль, вставленный ради починки сбоя, остаётся доступным для поиска спустя месяцы.
Ноутбук разработчика давно превратился в склад ключей. Локальные файлы окружения, конфигурации приложений, браузерные данные, кэши консольных утилит, хранилища программ и история командной оболочки могут содержать значения, которых никогда не видели централизованные средства контроля. Несанированная shell history помнит токен гораздо дольше своего владельца. В конце 2025 года волны атак Shai-Hulud и S1ingularity сделали рабочие станции разработчиков прямыми целями и входами в цепочку поставок ПО. Один такой компьютер нередко имеет доступ к GitHub, облачной инфраструктуре, внутренним сервисам, средам разработки и тестирования, сторонним интеграциям. Поэтому каждый ноутбук разработчика приходится считать частью общего слоя учётных данных.
В отчёте Verizon Data Breach Investigations Report за 2026 год скомпрометированные учётные данные обеспечили 22% случаев первоначального доступа. Корпоративные логины находили и на неуправляемых устройствах; такие находки участвовали в заметной доле изученных взломов. Период сбора данных Verizon завершился до того, как в начале 2026 года широко распространились самокопирующиеся инфостилеры, поэтому позднейший ущерб в этих 22% мог ещё не проявиться полностью. Попав на устройство, вредоносная программа перебирает браузеры, локальные файлы, кэши, каталоги приложений и любой доступный материал для аутентификации. Ей безразлично, какое подразделение выпустило ключ, лежит ли его эталонная копия в сейфе и какой защитный продукт формально за него отвечает.
На тех же машинах появился ещё один пользователь: ИИ-агент. Агент для программирования способен читать файлы, запускать команды, обращаться к внешним сервисам и пользоваться локальными ключами. Подключения по Model Context Protocol, или MCP, расширяют набор доступных инструментов, но каждое из них требует отдельного контроля аутентификации, авторизации, хранения секрета, границ разрешений, отзыва доступа и ответственности. При исследовании 6 943 скомпрометированных систем были обнаружены 33 185 уникальных секретов; 44% машин содержали больше десяти, а 5% — больше ста. В 2025 году в публичных конфигурационных файлах MCP нашли 24 008 уникальных секретов, из которых 2 117 удалось подтвердить как действующие. Название отчёта, из которого взяты последние цифры, в опубликованном описании не указано.
Риск ИИ-агентов не сводится к захвату злоумышленником. Агент может использовать избыточные полномочия непредвиденным способом; уже рассматриваются сценарии, в которых он удаляет рабочую базу данных. Простое сканирование репозитория здесь бессильно: нужный токен может находиться только на компьютере, где программу создают, тестируют и запускают. Каждый MCP-сервер добавляет ещё одну связь между локальной машиной и внешним инструментом. Службе безопасности нужно видеть, какие файлы агент читает, какими командами располагает, от чьего имени подключается к сервису и можно ли быстро отозвать этот доступ.
Сам факт обнаружения строки мало полезен без контекста. Для каждого секрета требуется установить действительность, все места хранения, историю распространения, владельца, применяемую политику, разрешения и зависимые нагрузки. Действующий административный ключ от производственной среды требует иной реакции, чем отозванный токен тестового сервиса. Отпечаток учётных данных позволяет связать копии без сохранения самого секрета: семь срабатываний должны учитываться как одна учётная запись с семью известными экспозициями, а не как семь разных находок. Владельцем при этом считается не только человек, создавший ключ, но и команда, приложение, сервис или рабочая нагрузка, которые от него зависят. Без карты зависимостей поспешный отзыв может остановить важную систему.
Одно средство контроля такой карты не даёт. Сканер репозиториев видит текущий код и историю Git; внешний мониторинг замечает публичные коммиты, конфигурации и утечки; проверка платформ совместной работы находит секреты в тикетах, чатах и базах знаний. Средства защиты конечных точек исследуют локальные файлы, браузеры, кэши, shell history, хранилища приложений, конфигурации ИИ-агентов и MCP. Разрешённые сейфы показывают, что хранится под формальным управлением, кто имеет доступ и как используется значение. Связать эти источники должен единый реестр, где у каждой учётной записи есть отпечаток, статус действительности, владелец, разрешения, зависимости, полный перечень мест и отметка о появлении в публичной среде.
Отчётность только по сейфам создаёт удобную, но ложную картину. Компания может хранить 50 000 учётных данных в разрешённых vault-системах и считать их полностью охваченными, хотя ещё тысячи открытых копий лежат в репозиториях, чатах и на ноутбуках. Часть окажется дубликатами управляемых значений, часть никогда не попадала в менеджер секретов. Реальный знаменатель для метрик — вся обнаруженная популяция. Уже от неё следует считать долю учётных данных с установленным владельцем, действующим статусом, известными разрешениями и зависимостями, публичной экспозицией либо хранением вне разрешённых средств. Покрытие сейфами остаётся одной метрикой, а не заменой инвентаризации.
Периодическая проверка проигрывает скорости атаки. По данным CrowdStrike за 2025 год, среднее время eCrime breakout time, то есть перехода злоумышленника от первой взломанной системы к боковому перемещению по сети, составило 29 минут. Самый быстрый зафиксированный случай занял 27 секунд. При таком окне ручная реакция запаздывает ещё до открытия тикета. Рабочая последовательность звучит как «обнаружить, устранить и предотвратить»: непрерывно искать секреты в публичных и внутренних репозиториях, истории Git, интернете, корпоративных платформах и конечных точках; объединять копии по отпечатку; сначала отзывать действующие ключи с широкими полномочиями, не забывая о зависимых приложениях; удалять открытые копии, сокращать разрешения и переводить значения в одобренные хранилища. Контроль репозиториев, ноутбуков, ИИ-агентов и MCP должен работать с машинной скоростью, иначе инвентаризацию раньше составит атакующий.[/final]
Изображение носит иллюстративный характер
Чем больше кода, тем больше приложений, интеграций, облачных ресурсов и систем, которым приходится удостоверять друг друга. В 2025 году в публичных коммитах GitHub появились 65 млн новых жёстко прописанных секретов, на 34% больше, чем годом ранее. Число утечек учётных данных, связанных с ИИ-сервисами, выросло на 81%. Секрет при этом редко остаётся в одном месте. Разработчик может создать ключ в разрешённой облачной учётной записи, записать его открытым текстом в репозиторий, вставить в базу знаний и сохранить управляемую копию в хранилище. Ещё несколько копий останутся на ноутбуке. «Гражданские разработчики», получившие доступ к агентам для написания кода, добавляют сюда личные проекты и недавно подключённые ИИ-сервисы.
Внутренний статус системы не гарантирует чистоты: внутренние репозитории примерно в шесть раз чаще публичных содержали хотя бы один секрет. Там оседают ключи от облачных сред, внутренних приложений, тестовых стендов и служебных API. Удаление значения из текущей версии файла тоже мало что решает, если оно сохранилось в истории Git, другой ветке, форке, соседнем репозитории или скопированном файле. Публичная утечка окончательно выводит секрет за пределы контроля компании, причём обнаружить её сразу удаётся не всегда. Около 28% инцидентов с секретами вообще возникли вне репозиториев: в чатах, системах совместной работы, тикетах поддержки и общих базах знаний, где пароль, вставленный ради починки сбоя, остаётся доступным для поиска спустя месяцы.
Ноутбук разработчика давно превратился в склад ключей. Локальные файлы окружения, конфигурации приложений, браузерные данные, кэши консольных утилит, хранилища программ и история командной оболочки могут содержать значения, которых никогда не видели централизованные средства контроля. Несанированная shell history помнит токен гораздо дольше своего владельца. В конце 2025 года волны атак Shai-Hulud и S1ingularity сделали рабочие станции разработчиков прямыми целями и входами в цепочку поставок ПО. Один такой компьютер нередко имеет доступ к GitHub, облачной инфраструктуре, внутренним сервисам, средам разработки и тестирования, сторонним интеграциям. Поэтому каждый ноутбук разработчика приходится считать частью общего слоя учётных данных.
В отчёте Verizon Data Breach Investigations Report за 2026 год скомпрометированные учётные данные обеспечили 22% случаев первоначального доступа. Корпоративные логины находили и на неуправляемых устройствах; такие находки участвовали в заметной доле изученных взломов. Период сбора данных Verizon завершился до того, как в начале 2026 года широко распространились самокопирующиеся инфостилеры, поэтому позднейший ущерб в этих 22% мог ещё не проявиться полностью. Попав на устройство, вредоносная программа перебирает браузеры, локальные файлы, кэши, каталоги приложений и любой доступный материал для аутентификации. Ей безразлично, какое подразделение выпустило ключ, лежит ли его эталонная копия в сейфе и какой защитный продукт формально за него отвечает.
На тех же машинах появился ещё один пользователь: ИИ-агент. Агент для программирования способен читать файлы, запускать команды, обращаться к внешним сервисам и пользоваться локальными ключами. Подключения по Model Context Protocol, или MCP, расширяют набор доступных инструментов, но каждое из них требует отдельного контроля аутентификации, авторизации, хранения секрета, границ разрешений, отзыва доступа и ответственности. При исследовании 6 943 скомпрометированных систем были обнаружены 33 185 уникальных секретов; 44% машин содержали больше десяти, а 5% — больше ста. В 2025 году в публичных конфигурационных файлах MCP нашли 24 008 уникальных секретов, из которых 2 117 удалось подтвердить как действующие. Название отчёта, из которого взяты последние цифры, в опубликованном описании не указано.
Риск ИИ-агентов не сводится к захвату злоумышленником. Агент может использовать избыточные полномочия непредвиденным способом; уже рассматриваются сценарии, в которых он удаляет рабочую базу данных. Простое сканирование репозитория здесь бессильно: нужный токен может находиться только на компьютере, где программу создают, тестируют и запускают. Каждый MCP-сервер добавляет ещё одну связь между локальной машиной и внешним инструментом. Службе безопасности нужно видеть, какие файлы агент читает, какими командами располагает, от чьего имени подключается к сервису и можно ли быстро отозвать этот доступ.
Сам факт обнаружения строки мало полезен без контекста. Для каждого секрета требуется установить действительность, все места хранения, историю распространения, владельца, применяемую политику, разрешения и зависимые нагрузки. Действующий административный ключ от производственной среды требует иной реакции, чем отозванный токен тестового сервиса. Отпечаток учётных данных позволяет связать копии без сохранения самого секрета: семь срабатываний должны учитываться как одна учётная запись с семью известными экспозициями, а не как семь разных находок. Владельцем при этом считается не только человек, создавший ключ, но и команда, приложение, сервис или рабочая нагрузка, которые от него зависят. Без карты зависимостей поспешный отзыв может остановить важную систему.
Одно средство контроля такой карты не даёт. Сканер репозиториев видит текущий код и историю Git; внешний мониторинг замечает публичные коммиты, конфигурации и утечки; проверка платформ совместной работы находит секреты в тикетах, чатах и базах знаний. Средства защиты конечных точек исследуют локальные файлы, браузеры, кэши, shell history, хранилища приложений, конфигурации ИИ-агентов и MCP. Разрешённые сейфы показывают, что хранится под формальным управлением, кто имеет доступ и как используется значение. Связать эти источники должен единый реестр, где у каждой учётной записи есть отпечаток, статус действительности, владелец, разрешения, зависимости, полный перечень мест и отметка о появлении в публичной среде.
Отчётность только по сейфам создаёт удобную, но ложную картину. Компания может хранить 50 000 учётных данных в разрешённых vault-системах и считать их полностью охваченными, хотя ещё тысячи открытых копий лежат в репозиториях, чатах и на ноутбуках. Часть окажется дубликатами управляемых значений, часть никогда не попадала в менеджер секретов. Реальный знаменатель для метрик — вся обнаруженная популяция. Уже от неё следует считать долю учётных данных с установленным владельцем, действующим статусом, известными разрешениями и зависимостями, публичной экспозицией либо хранением вне разрешённых средств. Покрытие сейфами остаётся одной метрикой, а не заменой инвентаризации.
Периодическая проверка проигрывает скорости атаки. По данным CrowdStrike за 2025 год, среднее время eCrime breakout time, то есть перехода злоумышленника от первой взломанной системы к боковому перемещению по сети, составило 29 минут. Самый быстрый зафиксированный случай занял 27 секунд. При таком окне ручная реакция запаздывает ещё до открытия тикета. Рабочая последовательность звучит как «обнаружить, устранить и предотвратить»: непрерывно искать секреты в публичных и внутренних репозиториях, истории Git, интернете, корпоративных платформах и конечных точках; объединять копии по отпечатку; сначала отзывать действующие ключи с широкими полномочиями, не забывая о зависимых приложениях; удалять открытые копии, сокращать разрешения и переводить значения в одобренные хранилища. Контроль репозиториев, ноутбуков, ИИ-агентов и MCP должен работать с машинной скоростью, иначе инвентаризацию раньше составит атакующий.[/final]
