Секрети в Git і CI/CD: чому видалені ключі досі працюють

Витік секрету в Git або CI/CD — це будь-які облікові дані, як-от ключ API, токен розгортання чи приватний ключ, що потрапили в історію репозиторію, відстежуваний файл або журнал збірки. Видалення з останнього коміту їх не відкликає. Будь-хто з клоном чи доступом до журналів може прочитати й використати їх, доки самі облікові дані не замінять.

У цьому дописі розглянемо чотири місця, де секрети витікають у конвеєрі постачання, порядок виправлення і запобіжники, що зупиняють наступний витік.

Більшість витоків у Git спричиняють два шаблони. Перший — жорстко прописаний ключ, який згодом «видаляють» комітом-прибиранням. Другий — цілий файл із секретами, як-от .env, приватний ключ чи JSON сервісного облікового запису, що відстежується з першого коміту, бо в репозиторії ніколи не було .gitignore.

В актуальному дереві обидва виглядають нормально. Тому вони й живуть роками.

Ні. Git зберігає кожну версію кожного файлу, тож значення лишається в коміті перед прибиранням. Одна команда git log -p або git show <commit>^:config.js повертає його, а кожен форк і клон має власну копію.

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

Журнали збірок публічніші, ніж думають автори workflow. Крок налагодження з echo $DEPLOY_TOKEN друкує секрет відкритим текстом, а в публічному репозиторії цей журнал може прочитати будь-хто.

Ті самі workflow часто мають другу ваду: недовірені вхідні дані, наприклад назва pull request, підставлені просто в крок run:. Такі дані виконуються як команди оболонки на раннері, де секрети конвеєра в досяжності. Незакріплені сторонні actions додають третій шлях, бо переміщений тег може підставити код, який ви ніколи не перевіряли.

У вправі «Розкриття секретів у CI/CD» ви забираєте токен розгортання з публічних журналів Actions і розгортаєте з ним власний образ. Потім виправляєте workflow і замінюєте токен.

Спершу замініть. Відкличте скомпрометовані облікові дані й випустіть заміну з обмеженими правами, перш ніж чіпати історію, журнали чи код.

Очищення історії через git filter-repo або маскування майбутніх журналів здається виправленням, але нічого не робить із ключем, який зловмисник уже скопіював. Прибирайте після того, як облікові дані мертві.

• Блокуйте файли з секретами під час коміту. Додайте .gitignore для .env, ключів і JSON з обліковими даними та pre-commit хук, що відхиляє назви й шаблони секретів.
• Скануйте в CI. Запускайте сканер секретів на кожен push, щоб витік ставав невдалою збіркою, а не публічним комітом.
• Ніколи не виводьте секрети. Приберіть налагоджувальні виводи, а маскування платформи вважайте лише страховкою.
• Вважайте вхідні дані конвеєра недовіреними. Передавайте назви PR, гілок і текст задач через змінні середовища, ніколи не вставляйте їх просто в команди оболонки.
• Закріплюйте actions за SHA коміту, а не за тегом.
• Надавайте перевагу короткоживучим обліковим даним, як-от федерації OIDC із вашою хмарою, щоб токен, що витік, сам спливав.

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

Більшість інженерів знає, що не можна комітити секрети. Поведінку змінює інше: знайти «видалений» ключ в історії й побачити, що він досі проходить автентифікацію.

Каталог безпеки Git побудований навколо циклу «експлуатуй, потім виправ», а каталог хмарної безпеки застосовує його до образів і хмарної інфраструктури. Хочете запровадити це для своєї команди розробки? Напишіть нам.