CI/CD и секреты: как не утекать токенами, ключами и конфигами из репозиториев и пайплайнов

Полное руководство по защите чувствительных данных в современном DevOps

Введение: почему утечка секрета — это не просто неловкость

Представьте, что разработчик в спешке закоммитил файл .env с AWS-ключами в публичный репозиторий. Через несколько минут автоматический сканер, обходящий GitHub в режиме реального времени, обнаружит этот ключ. Ещё через несколько минут на вашем облачном счёте могут появиться тысячи виртуальных машин для майнинга криптовалюты — или, что хуже, ваши данные начнут копироваться на чужой сервер.

Это не гипотетический сценарий. Именно так выглядит статистика: согласно исследованию GitGuardian, в 2024 году было обнаружено почти 24 миллиона новых захардкоженных секретов только в публичных репозиториях GitHub [1]. Утечки по цепочке поставок с компрометацией CI/CD-среды превратились в регулярную угрозу.

CI/CD-пайплайны — это нервная система современной разработки: они строят, тестируют, подписывают и разворачивают программное обеспечение. Именно поэтому они хранят самые ценные ключи — к облачным ресурсам, базам данных, реестрам контейнеров, внешним API. Скомпрометировать пайплайн значит получить доступ сразу ко всему, что он деплоит.

Эта статья адресована всем, кто участвует в жизненном цикле разработки: разработчикам, DevOps- и DevSecOps-инженерам, архитекторам и руководителям ИБ. Мы разберём, где именно утекают секреты, как устроена современная защита, какие инструменты реально работают и каких ошибок не стоит повторять.

Что такое «секрет» в контексте CI/CD

Термин «секрет» в DevOps охватывает широкий спектр данных:

• API-ключи и токены доступа (GitHub, GitLab, AWS, GCP, Azure, Stripe, Twilio и сотни других сервисов)
• Пароли к базам данных и строки подключения
• Приватные SSH-ключи
• Сертификаты TLS/mTLS и закрытые ключи PKI
• OAuth-токены и JWT-токены с долгим TTL
• Переменные окружения с чувствительными значениями
• Webhook-секреты и подписи
• Ключи шифрования и симметричные ключи KMS

Все перечисленное объединяет одно: если эти данные попадают к злоумышленнику, он получает возможность действовать от имени вашей системы — читать данные, изменять конфигурацию, инициировать транзакции, запускать ресурсы.

Масштаб проблемы: цифры, которые заставляют действовать

Прежде чем переходить к методам защиты, нужно понять масштаб угрозы. Цифры неутешительные.

В 2024 году GitGuardian обнаружил 23 770 171 новых захардкоженных секретов в публичных репозиториях GitHub — на 25% больше, чем годом ранее [1]. Это не разовая вспышка: рост продолжается уже несколько лет подряд. С момента первого отчёта компании в 2021 году количество выявленных секретов выросло примерно в четыре раза [2].

Среди наиболее тревожных наблюдений:

• Так называемые «зомби-утечки»: 70% секретов, утёкших в 2022 году, оставались активными ещё в 2024-м [1]. Это означает, что их никто не ротировал.
• 58% всех обнаруженных секретов — «generic secrets»: они не имеют стандартного паттерна и хуже поддаются автоматическому обнаружению [1].
• 35% приватных репозиториев клиентов GitGuardian содержат открытые секреты [1]. Приватность репозитория не равна его безопасности.
• 96% утёкших GitHub-токенов имеют права на запись — то есть дают атакующему не только читать, но и изменять код [4].

Репозитории — лишь часть проблемы. Согласно тому же отчёту [5], инструменты для совместной работы — Slack, Jira, Confluence — превратились в значимый и практически неохраняемый канал утечки.

Verizon в своём ежегодном отчёте DBIR фиксирует, что за последние 10 лет использование скомпрометированных учётных данных фигурировало в 31% всех подтверждённых утечек данных [8]. IBM Cost of a Data Breach 2024 добавляет: инциденты, связанные с кражей учётных данных, занимают в среднем 292 дня на идентификацию и устранение — дольше, чем любой другой вектор атаки [7].

Где именно утекают секреты: восемь типичных векторов

1. Прямой коммит в репозиторий

Самый банальный и самый распространённый способ. Разработчик вставляет в код реальный токен «временно, чтобы проверить», или забывает убрать ключ перед коммитом. Ситуацию усугубляет то, что даже удалённый файл остаётся в истории git навсегда — если только не применялась специальная перезапись истории [10].

Особого внимания заслуживают файлы конфигурации: .env, application.properties, config.yml, Terraform-файлы с terraform.tfvars. Забытый файл в .gitignore или добавленный в репозиторий вместо игнорирования — типичный путь к катастрофе.

2. Переменные окружения в пайплайне и логи сборки

CI/CD-платформы (GitHub Actions, GitLab CI, Jenkins, CircleCI) предоставляют механизм переменных окружения для передачи секретов в задания. Проблема возникает, когда эти переменные попадают в лог — например, через отладочный echo, env, -x (trace mode) в bash, или через CLI-команды, которые пишут токен в stdout как часть вывода [9].

Специалисты Salt Security приводят показательный пример: CLI облачных провайдеров (AWS, GCP) могут включать токены в стандартный вывод команды, и если этот вывод не замаскирован — он оседает в публичном логе пайплайна [6]. Логи публичных репозиториев доступны всем — это прямой вектор утечки.

3. Docker-слои

Docker-образы строятся послойно. Если секрет был добавлен в файловую систему на одном слое, а потом «удалён» на следующем — он по-прежнему присутствует в истории образа и доступен через docker history или прямой анализ слоёв [10]. Это одна из самых недооценённых проблем в безопасности контейнеров.

4. Компромисс CI/CD-платформы или Actions

Атака на tj-actions/changed-files в марте 2025 года наглядно показала этот вектор. Злоумышленники получили доступ к GitHub Personal Access Token (PAT) бота, сопровождавшего популярное GitHub Action, и внедрили вредоносный Python-скрипт, который дампил секреты CI/CD из процесса Runner Worker прямо в лог сборки [3]. Уязвимость затронула более 23 000 репозиториев, использовавших действие.

Примечательно: атакующие ретроактивно обновили теги версий, чтобы даже «закреплённые» версии стали уязвимыми — за исключением репозиториев, использовавших закрепление по хешу коммита [3].

Инцидент с CircleCI в декабре 2022 — январе 2023 года демонстрирует похожую схему. Злоумышленник скомпрометировал ноутбук инженера CircleCI с помощью вредоносного ПО, похитил SSO-сессионную куки, прошёл двухфакторную аутентификацию и получил доступ к секретам клиентов — переменным окружения, токенам и SSH-ключам — прямо из памяти работающего процесса [11]. Всем клиентам было рекомендовано немедленно ротировать «любые и все секреты» [12].

5. Приватные репозитории и «тихая уверенность»

Распространённое заблуждение: раз репозиторий приватный, секреты в нём в безопасности. Данные GitGuardian опровергают это: приватные репозитории в 8 раз чаще содержат секреты, чем публичные — именно потому, что разработчики относятся к ним небрежнее [1]. Хранение AWS IAM-ключей встречается в приватных репозиториях в 5 раз чаще, чем в публичных.

6. Артефакты сборки и релизные архивы

Скомпилированные бинарные файлы, JAR/WAR-архивы, npm-пакеты, Docker-образы в реестрах — все они могут содержать секреты, встроенные на этапе сборки. Исследование GitGuardian показало, что в пакетах PyPI было обнаружено 56 866 случаев секретов — и многие разработчики не подозревают, что секрет публикуется вместе с библиотекой при каждом релизе [2].

7. Инструменты коллаборации: Slack, Jira, Confluence

Сотрудники регулярно делятся конфигурациями, отлаживают проблемы и вставляют в переписку чувствительные данные «на минуту». В отличие от кода, сообщения в корпоративных мессенджерах и тикет-трекерах практически никогда не сканируются на предмет секретов. При этом доступ к ним шире, чем к кодовой базе [5].

8. IaC-файлы и конфигурационные манифесты

Terraform, Helm-чарты, Kubernetes-манифесты, Ansible-плейбуки — всё это инфраструктурный код, который хранится в репозиториях. Секреты в них встречаются системно: строки подключения к базам, ключи облачных провайдеров, webhook-токены. Особая группа риска — файлы terraform.tfstate, которые в открытом виде содержат все значения, переданные в ресурсы.

Принципы защиты: три кита

Прежде чем переходить к конкретным инструментам, важно усвоить принципы. Они определяют, почему работают те или иные технические решения.

Принцип 1: секрет никогда не должен появляться в коде и конфигах, которые коммитятся в VCS

Звучит очевидно, но именно его нарушение — первопричина большинства инцидентов. Секрет не должен быть в .env-файлах, yaml-манифестах, скриптах развёртывания, Dockerfile, package.json или любом другом файле, который попадает в систему контроля версий.

Принцип 2: короткий жизненный цикл (TTL)

70% утёкших секретов остаются активными спустя два года [1] — это прямое следствие отсутствия ротации. Секрет с коротким TTL, даже если он утёк, быстро становится бесполезным. Динамические секреты (генерируемые на один запрос/задание и автоматически отзываемые) — идеал, к которому стоит стремиться.

Принцип 3: наименьшие привилегии

96% утёкших GitHub-токенов имеют права на запись [4]. Большинству CI-заданий не нужны такие широкие права. Секрет должен давать доступ ровно к тому ресурсу, который нужен конкретному заданию — и ни к чему больше.

Технические инструменты: как строится современная защита

Сканирование секретов: Gitleaks и TruffleHog

Два ведущих open-source инструмента для обнаружения секретов — Gitleaks и TruffleHog — охватывают разные, но взаимодополняющие сценарии [13].

Gitleaks написан на Go, работает быстро и идеально подходит для pre-commit хука — он сканирует staged-изменения за миллисекунды и блокирует коммит до того, как секрет попадёт в историю репозитория. Поддерживает кастомные regex-паттерны, экспорт в JSON/SARIF/CSV и интеграцию с GitHub Actions [13].

TruffleHog поддерживает более 800 типов секретов и обладает уникальной возможностью — верификацией обнаруженного секрета в режиме реального времени: если он нашёл AWS-ключ, он проверит через AWS API, работает ли этот ключ до сих пор [13]. Это резко снижает количество ложных срабатываний и позволяет команде безопасности сосредоточиться на реальных инцидентах.

Сравнительное исследование академических учёных показало, что Gitleaks и TruffleHog — лидеры по полноте охвата (recall), и их результаты существенно не перекрываются: каждый находит секреты, которые пропустил другой [14]. Оптимальная стратегия — использовать оба.

Рекомендуемая схема:

1. Gitleaks как pre-commit хук на рабочих машинах разработчиков
2. TruffleHog в CI-пайплайне (на каждый pull request и при merge в основную ветку)
3. Регулярное (еженедельное) сканирование всей истории репозиториев

Хранилища секретов: HashiCorp Vault и облачные аналоги

Централизованное хранилище секретов — основа правильного управления ими. Основные варианты:

HashiCorp Vault (OpenBSD License для open-source версии) — наиболее функциональный вариант. Поддерживает динамические секреты (генерируется новая пара учётных данных под каждый запрос с автоматическим истечением), политики на основе путей, полный аудит-лог всех операций с секретами, интеграцию с Kubernetes, GitLab CI, GitHub Actions, Jenkins через native-плагины [15]. Vault поддерживает on-prem развёртывание, что критично для российских компаний с требованиями локализации данных.

Облачные альтернативы: AWS Secrets Manager, Azure Key Vault, GCP Secret Manager — хорошо интегрируются с соответствующими облаками, но привязывают к конкретному провайдеру.

Для GitLab CI интеграция с Vault выглядит следующим образом: GitLab генерирует короткоживущий JWT-токен (ID-токен) для каждого задания. Vault проверяет этот токен через OIDC Discovery endpoint GitLab и выдаёт Vault-токен с ограниченным временем жизни (TTL), привязанный к конкретной политике доступа. После завершения задания токен автоматически истекает [16].

OIDC-аутентификация: решение проблемы рекурсивного секрета

Ключевой вопрос управления секретами — «bootstrap problem»: чтобы получить секрет из хранилища, нужен другой секрет для аутентификации в хранилище. OIDC решает эту проблему элегантно.

Современные CI/CD-платформы (GitHub Actions, GitLab CI, CircleCI) умеют генерировать короткоживущие JWT-токены для каждого запуска задания. Эти токены содержат верифицируемые «claims» — название репозитория, ветку, триггер — и подписаны провайдером идентичности платформы. Облачный провайдер или Vault принимает этот токен как доказательство идентичности и выдаёт временные учётные данные [17].

В результате в пайплайне не хранится ни одного долгоживущего секрета. Даже если токен перехвачен — он истекает через несколько минут.

Схема для GitHub Actions + AWS выглядит так: задание запрашивает OIDC-токен, передаёт его в AWS STS через AssumeRoleWithWebIdentity, получает временные IAM-учётные данные со сроком жизни, например, 15 минут. Никаких AWS-ключей в GitHub Secrets [17].

Pre-commit хуки и политики в pipeline

Защита должна работать на нескольких уровнях. На уровне рабочего места разработчика — pre-commit хуки (Gitleaks, detect-secrets). На уровне репозитория — GitHub Push Protection или аналог для GitLab, блокирующий пуш при обнаружении известных паттернов секретов. На уровне CI — сканирование каждого PR.

Важная деталь: даже GitHub Push Protection, при всей своей полезности, плохо справляется с «generic secrets» — они составили 58% всех утечек в 2024 году [1]. Push Protection работает с секретами известного формата, оставляя пробел для нестандартных токенов.

Маскирование в логах

Каждая CI/CD-платформа поддерживает маскирование переменных: GitHub Actions скрывает переменные, объявленные как secrets; GitLab CI маскирует переменные с флагом «Masked». Но автоматическое маскирование не всесильно — если секрет попадает в лог через нестандартный путь (например, как часть JSON-ответа API, через subshell или через динамически формируемую строку), маскирование может не сработать [6].

Правило: не выводите переменные окружения в логи. Никогда не используйте set -x в bash-скриптах, работающих с секретами. Никогда не логируйте полный вывод CLI-команд облачных провайдеров без явной проверки на наличие чувствительных данных.

Управление Docker-секретами

Правильный способ передачи секретов в Docker — через BuildKit secrets: --secret id=mysecret,src=./secret.txt и в Dockerfile RUN --mount=type=secret,id=mysecret .... При таком подходе секрет монтируется только во время выполнения RUN-команды и никогда не записывается в слой образа [10].

Категорически неправильно: COPY .env . или ARG API_KEY / ENV API_KEY=$API_KEY — всё это остаётся в слоях навсегда.

Практический чек-лист: что сделать прямо сейчас

Репозитории и история:

1. Установить Gitleaks как pre-commit хук на все рабочие машины команды
2. Запустить TruffleHog на полную историю всех репозиториев (включая приватные)
3. Просмотреть и обновить .gitignore — убедиться, что .env, *.pem, *.key, terraform.tfvars и *secret* в нём присутствуют
4. Включить GitHub Push Protection или аналог в GitLab/Bitbucket
5. Если в истории найдены секреты — немедленно их ротировать, затем применить git filter-branch или git-filter-repo для перезаписи истории

CI/CD-пайплайны:

1. Перейти на OIDC-аутентификацию с эфемерными токенами для облачных провайдеров — убрать долгоживущие cloud-ключи из переменных пайплайна
2. Перенести все оставшиеся секреты в централизованное хранилище (Vault, AWS Secrets Manager, Azure Key Vault)
3. Настроить маскирование всех секретных переменных на уровне платформы
4. Убрать set -x из всех bash-скриптов в пайплайне
5. Ограничить права сервисных аккаунтов CI: разные задания — разные роли с минимально необходимыми правами
6. Закрепить все внешние Actions/Orbs по хешу коммита, а не по тегу (например, uses: actions/checkout@abc123 вместо @v3) — урок из атаки tj-actions [3]

Docker и артефакты:

1. Аудит всех Dockerfile на предмет ARG, ENV и COPY с чувствительными файлами
2. Перейти на BuildKit secrets для сборки образов
3. Сканировать Docker-образы в реестре с помощью TruffleHog или аналогичного инструмента

Организационные меры:

1. Ввести периодическую ротацию всех секретов (рекомендуемый максимум TTL — 90 дней)
2. Вести инвентарь секретов: где, какие, кто владелец, когда последняя ротация
3. Настроить мониторинг аномальной активности токенов (неожиданная геолокация, нетипичные объёмы запросов)

Типичные ошибки и как их избежать

Ошибка 1: «Это приватный репозиторий, там всё безопасно». Опровержение: данные показывают, что в приватных репозиториях секреты встречаются чаще, чем в публичных [1]. Компромисс аккаунта сотрудника, внешний подрядчик с избыточными правами или будущий публичный форк — всё это делает приватность ненадёжной защитой.

Ошибка 2: «Я удалил файл с секретом — проблема решена». Опровержение: git хранит всю историю. Удалённый файл остаётся доступен через git log, git checkout и инструменты анализа истории. Необходима перезапись истории и немедленная ротация.

Ошибка 3: «Долгоживущий токен с ограниченными правами — это нормально». Опровержение: 70% утёкших в 2022 году токенов активны до сих пор [1]. Ограниченные права не компенсируют бесконечный срок жизни. Даже токен только на чтение даёт атакующему разведывательные возможности.

Ошибка 4: «Мы используем переменные окружения в CI — этого достаточно». Опровержение: переменные среды в CI могут утекать через логи, в дочерние процессы и через отладочные режимы. Если CI-платформа скомпрометирована (как в случае CircleCI), все переменные среды клиентов оказываются под угрозой [11]. Правильная альтернатива — получение секретов из внешнего хранилища в момент выполнения задания с немедленным истечением.

Ошибка 5: «Инструменты сканирования порождают слишком много ложных срабатываний, мы их отключили». Опровержение: это не причина отказаться от сканирования, а причина правильно его настроить. TruffleHog с верификацией и Gitleaks с кастомными правилами поддаются тонкой настройке. Лучше инвестировать время в калибровку, чем оказаться без защиты.

Ошибка 6: «Мы доверяем всем Actions/Orbs из GitHub Marketplace». Опровержение: атака tj-actions/changed-files в марте 2025 года опровергла это предположение [3]. Любая зависимость в пайплайне — потенциальный вектор атаки. Используйте закрепление по хешу и периодически аудируйте сторонние действия.

Резонансные кейсы: чему учит история

CircleCI, январь 2023

Злоумышленник установил вредоносное ПО на ноутбук инженера CircleCI, которое похитило SSO-сессионную куку, защищённую двухфакторной аутентификацией. Используя сессионный токен, атакующий получил доступ к рабочим базам данных и хранилищам платформы. Из памяти работающего процесса были извлечены ключи шифрования, что позволило расшифровать переменные окружения клиентов, токены и SSH-ключи [11].

Масштаб: CircleCI обслуживает более миллиона разработчиков. Всем клиентам пришлось немедленно ротировать все секреты — OAuth-токены, API-ключи, SSH-ключи, переменные контекста. Полная ротация GitHub OAuth-токенов заняла три дня [12].

Урок: зашифрованные секреты в хранилище не спасают, если ключи шифрования хранятся в оперативной памяти того же процесса, который можно атаковать. OIDC с эфемерными токенами полностью устраняет эту проблему: нечего красть, когда токена нет.

tj-actions/changed-files, март 2025

Атака на популярное GitHub Action иллюстрирует классическую атаку на цепочку поставок. Злоумышленник компрометировал PAT бота-мейнтейнера, внедрил вредоносный скрипт в репозиторий действия и ретроактивно обновил все теги версий, чтобы указывали на вредоносный коммит [3].

Поражённые репозитории выводили в лог сборки AWS-ключи, GitHub PAT, npm-токены и приватные RSA-ключи. Масштаб атаки — более 23 000 репозиториев. Вредоносный код был «тщательно замаскирован» от инструментов автоматического анализа [3].

Урок: закрепление Actions по хешу коммита, а не по тегу — обязательная практика. Теги изменяемы, хеш — нет.

Утечка ключей U.S. Treasury через BeyondTrust, 2024

В конце 2024 года взлом Министерства финансов США был отслежен до утёкшего API-ключа для аутентификационной платформы BeyondTrust. Используя один скомпрометированный ключ, атакующие обошли многомиллионные инвестиции в безопасность [1].

Урок: один утёкший ключ может нейтрализовать весь периметр защиты. Мониторинг аномальной активности токенов и быстрая ротация критичны.

Специфика российского рынка и регуляторный контекст

Для российских компаний к технической составляющей добавляется регуляторная. Федеральный закон №152-ФЗ «О персональных данных» требует применения технических мер защиты — это в том числе включает защиту доступа к системам, хранящим персональные данные. Приказы ФСТЭК России регулируют требования к средствам защиты информации.

Если токены или ключи доступа, находящиеся в CI/CD-пайплайне, открывают доступ к базам данных с персональными данными — утечка этих ключей автоматически создаёт риск нарушения 152-ФЗ. Регулятор оценивает не только факт утечки ПДн, но и наличие (или отсутствие) мер, которые её должны были предотвратить.

С практической точки зрения это означает:

• Ключи от баз данных с ПДн должны храниться в защищённом хранилище с аудит-логом доступа
• Доступ к ключам должен быть разграничён по принципу наименьших привилегий
• Необходим реестр: где какие секреты, к каким данным они дают доступ, кто и когда последний раз их использовал

Реализовать это без специализированного инструментария трудно — особенно в крупных компаниях с десятками микросервисов и разнородным ИТ-ландшафтом.

Тренды: что меняется прямо сейчас

Несколько тенденций определяют развитие сферы в 2025-2026 годах.

Рост использования AI-ассистентов в разработке. GitHub Copilot начал использоваться в 27% больше репозиториев в 2024 году по сравнению с 2023-м. При этом репозитории, использующие Copilot, демонстрируют частоту утечек секретов 6,4% — исследователи связывают это с тем, что AI-ассистенты могут предлагать паттерны кода, включающие примеры с «заглушками» на месте реальных секретов, которые разработчики забывают заменить [1].

Угроза Non-Human Identities (NHI). Традиционная безопасность была ориентирована на людей. Сейчас в корпоративных системах машинных идентичностей (сервисные аккаунты, API-ключи, токены CI/CD) больше, чем человеческих. Они хуже управляются: нет смены пароля по требованию, нет MFA, срок действия не истекает автоматически. Именно NHI становятся основным вектором атак на цепочку поставок.

Shift-left security. Смещение требований безопасности «влево» — на более ранние этапы разработки — означает, что pre-commit сканирование, IaC-анализ и политики защиты ветки становятся стандартом, а не опцией. Согласно отчёту GitLab 2024, 87% команд внедрили хотя бы частичную автоматизацию безопасности в CI/CD [18].

Стандарты SBOM и supply chain security. После ряда громких инцидентов (SolarWinds, Log4Shell, XZ Utils) индустрия движется к обязательному ведению Software Bill of Materials и верификации целостности артефактов сборки. Для CI/CD это означает подпись образов, верификацию в момент деплоя и контроль provenance цепочки сборки.

«Пятый фактор»: когда контроль секретов становится частью compliance

Управление секретами в CI/CD — это техническая задача. Но за ней стоит более широкий вопрос: какие вообще данные есть в системах компании, кто к ним имеет доступ и какие ключи открывают к ним путь?

Именно здесь возникает пересечение с задачами compliance и защиты персональных данных. Если ключ от базы данных с ПДн утёк из CI/CD-пайплайна, это не только инцидент ИБ — это потенциальное нарушение 152-ФЗ, обнаружить которое по факту проверки регулятора будет очень болезненно.

Платформа «Пятый фактор» (5factor.ru) решает смежную, но критически важную задачу: автоматическое обнаружение, инвентаризация и контроль персональных данных в корпоративных системах — базах данных, хранилищах, почте, AD/LDAP, CRM, 1С, API. Ключевое отличие — работа на уровне метаданных, структуры и агрегатов, без передачи и хранения «сырых» персональных данных. Это значит, что платформа сама по себе не становится источником риска.

В контексте безопасности CI/CD это даёт несколько важных возможностей:

• Понять, к каким именно данным (в том числе ПДн) открывают доступ ключи, хранящиеся в пайплайнах
• Видеть «живую карту» данных: новые поля в БД, новые интеграции — до того, как они превратились в инцидент
• Сократить время аудита и повысить готовность к проверкам регуляторов, опираясь на актуальную картину того, что где хранится

Технические меры защиты секретов и инвентаризация данных — это не альтернативы, а взаимодополняющие части зрелой программы ИБ.

Заключение: от точечных мер к системному контролю

Проблема утечек секретов в CI/CD — это не вопрос отдельных ошибок отдельных разработчиков. Это системная уязвимость, рождённая из скорости и автоматизации: чем быстрее и сложнее становятся пайплайны, тем шире поверхность атаки.

Хорошая новость: большинство инцидентов предотвратимы с помощью уже существующих инструментов и практик. Плохая новость: эти практики требуют системного внедрения, а не разовых мер.

Что делать прямо сейчас:

1. Провести инвентаризацию всех мест, где сейчас хранятся секреты: переменные пайплайна, файлы в репозиториях, Docker-образы, артефакты, инструменты коллаборации
2. Запустить TruffleHog на историю всех репозиториев
3. Ротировать все найденные активные секреты
4. Внедрить pre-commit сканирование с Gitleaks
5. Запланировать переход на OIDC-аутентификацию и централизованное хранилище секретов

Безопасность секретов — это не финишная черта, а непрерывный процесс. Новые сервисы, новые интеграции, новые разработчики в команде — каждый из них потенциально создаёт новые риски. Только регулярный автоматизированный мониторинг позволяет держать картину актуальной.

Источники

[1] GitGuardian — The State of Secrets Sprawl 2025 — https://blog.gitguardian.com/the-state-of-secrets-sprawl-2025/

[2] GitGuardian — The State of Secrets Sprawl 2024 — https://blog.gitguardian.com/the-state-of-secrets-sprawl-2024/

[3] The Hacker News — GitHub Action Compromise Puts CI/CD Secrets at Risk in Over 23,000 Repositories (март 2025) — https://thehackernews.com/2025/03/github-action-compromise-puts-cicd.html

[4] InfoQ — Secret Sprawl in Public Repos is Worse Than Ever (март 2025) — https://www.infoq.com/news/2025/03/gitguardian-secret-sprawl-report/

[5] Cyber Defense Magazine — The Hidden Danger: Secrets Sprawl Beyond the Codebase (2025) — https://www.cyberdefensemagazine.com/the-hidden-danger-secrets-sprawl-beyond-the-codebase/

[6] ReversingLabs — CI/CD pipelines and the cloud: Are your development secrets at risk? — https://www.reversinglabs.com/blog/cicd-in-the-cloud-are-your-secrets-at-risk

[7] Enzoic — Insights from IBM's 2024 Cost of a Data Breach Report — https://www.enzoic.com/blog/ibms-2024-cost-of-a-data-breach/

[8] Verizon — 2024 Data Breach Investigations Report — https://www.verizon.com/about/news/feed/2024-data-breach-investigations-report-vulnerability-exploitation-boom

[9] CloudMatos — Preventing CI/CD Token Theft in 2025 — https://www.cloudmatos.ai/blog/secrets-prevention-ci-cd-token-theft-2025/

[10] CISOClub — Секреты в CI/CD и Docker: как предотвратить утечки (декабрь 2025) — https://cisoclub.ru/konvejer-sborki-bez-utechek-kritichnyh-dannyh-ili-zashhita-ot-uiljama-testera-v-cifrovuju-jepohu/

[11] Help Net Security — CircleCI breach post-mortem: Attackers got in by stealing engineer's session cookie (январь 2023) — https://www.helpnetsecurity.com/2023/01/16/circleci-breach/

[12] CircleCI — Incident report for January 4, 2023 security incident — https://circleci.com/blog/jan-4-2023-incident-report/

[13] AppSec Santa — 8 Best Secret Scanning Tools (2026) — https://appsecsanta.com/sast-tools/secret-scanning-tools

[14] Arxiv — A Comparative Study of Software Secrets Reporting by Secret Detection Tools — https://arxiv.org/pdf/2307.00714

[15] HashiCorp Developer — Secure CI/CD secrets (Well-Architected Framework) — https://developer.hashicorp.com/well-architected-framework/security/security-cicd-vault

[16] GitLab Docs — Use HashiCorp Vault secrets in GitLab CI/CD — https://docs.gitlab.com/ci/secrets/hashicorp_vault/

[17] HashiCorp — Why we need short-lived credentials and how to adopt them — https://www.hashicorp.com/en/blog/why-we-need-short-lived-credentials-and-how-to-adopt-them

[18] Codeby School — Внедрение DevSecOps: автоматизация безопасности в CI/CD — https://codeby.school/blog/informacionnaya-bezopasnost/devsecops-bez-boli-gotovyy-gitlab-ci-pipeline-za-15-minut

[19] Kaspersky Blog — Атака на цепочку поставок через GitHub Action (март 2025) — https://www.kaspersky.ru/blog/malicious-github-action-changed-files/39239/

[20] Habr — Безопасность CI/CD. Часть 2. Как защитить пайплайны — https://habr.com/ru/companies/bimeister/articles/781274/