На GitHub можно случайно раскрыть сведения через файлы, историю коммитов, комментарии или подключённое приложение. Перед передачей проекта стоит понять, кто его читает, какие доступы выданы и что именно вы собираетесь отправить.

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

Сведения сверены с документацией GitHub 3 октября 2026 года. Настройки аккаунта, реальные ключи и доступы при подготовке не менялись; пример правил исключения проверен локально.

Видимость проекта и секреты — разные вопросы

Public означает, что содержимое репозитория открыто посетителям. Private ограничивает доступ: его получают участники и приложения по выданным разрешениям. Приватность помогает выбрать аудиторию, но не превращает репозиторий в безопасное место для паролей.

Секрет — значение, которое даёт доступ к системе: пароль, ключ API, токен, закрытый ключ. Оно может сохраниться в истории даже после удаления из текущего файла. Личные данные и закрытые клиентские документы тоже требуют контроля, хотя сканер секретов может их не распознать.

Перед первой отправкой определите назначение репозитория и доступную аудиторию. Для сайта отдельно проверьте, какие файлы реально публикуются: приватный исходник не всегда означает приватный сайт.

Защитите вход и восстановление

Откройте настройки своего аккаунта, раздел Password and authentication, и проверьте действующий способ входа и двухфакторную аутентификацию — подтверждение входа дополнительным способом.

Настройка второго фактора должна сопровождаться понятным восстановлением. Сохраните резервные коды или другие предусмотренные способы в подходящем защищённом месте вне репозитория. Проверьте, что сможете восстановить доступ при потере устройства. Не вставляйте коды в README, issue или отчёт о настройке.

Для организации учитывайте её требования входа и доступа. Изменение способа авторизации выполняйте осознанно: оно может затронуть рабочие инструменты. Защита аккаунта.

Проверьте людей, приложения и токены

В настройках репозитория посмотрите участников и роли. Для нового человека определите, что ему требуется: читать документы, предлагать изменения или управлять настройками. Не выдавайте административную роль только ради небольшой правки.

В настройках аккаунта проверьте раздел приложений: GitHub Apps и OAuth Apps. Различайте установку приложения для выбранных репозиториев и авторизацию действия от имени пользователя. Прочитайте фактические права: чтение одного проекта и доступ ко всем проектам имеют разные последствия.

Для личных токенов проверьте назначение, срок и нужные репозитории. Если сервис предлагает ограниченный токен для конкретной задачи, не заменяйте его более широким без причины. Не печатайте значение токена в логе и не включайте вывод заголовков авторизации ради диагностики.

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

Что проверить перед коммитом и push

Коммит сохраняет выбранные изменения в истории; push отправляет коммиты на сервер. Просмотрите список файлов и diff, то есть разницу версий, до обоих этапов. Проверяйте не только код: секреты встречаются в .env, логах, выгрузках, ссылках и скриншотах.

Для локальных настроек можно использовать .gitignore:

# Локальные значения исключаются из новых отслеживаемых файлов.
.env
.env.*
# Шаблон разрешён только без настоящих значений.
!.env.example

В .env.example оставьте имена переменных и фиктивные значения, например APP_TOKEN=YOUR_TOKEN_HERE. Имя файла не гарантирует безопасное содержимое — его тоже нужно прочитать.

⚠️
.gitignore действует на ещё не отслеживаемые файлы. Он не удаляет уже добавленный файл из истории и не очищает старые коммиты. Граница правил исключения.

Если файл уже отслеживается, сначала выясните, что в нём сохранено и как его использует проект. Добавление одной строки в .gitignore эту ситуацию не исправляет.

Как читать предупреждения безопасности

Доступные функции зависят от плана, видимости и настроек. В текущем интерфейсе соответствующая вкладка может называться Security and quality. В обзоре функций GitHub отдельно перечислены общие возможности, GitHub Secret Protection и GitHub Code Security.

ВозможностьЧто она помогает обнаружитьЧего из неё нельзя вывести
Secret scanningПоддерживаемые типы секретов и доступные дополнительные правилаЧто во всех файлах нет закрытых данных
Push protectionОпределённые секреты перед отправкойЧто можно не читать diff
Dependabot alertsИзвестные проблемы обнаруженных зависимостейЧто приложение не содержит других уязвимостей
Code scanningПроблемы кода в рамках настроенного анализаЧто все способы работы приложения проверены

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

У Dependabot различайте предупреждения, security updates и version updates. Предупреждение сообщает о проблеме. Security updates могут подготовить обновление уязвимой зависимости. Version updates выполняются по отдельной настройке и могут обновлять версии без такого предупреждения.

Откройте конкретный alert: сопоставьте пакет, файл зависимостей, затронутые версии и рекомендации с проектом. Если предложен PR, прочитайте diff и результаты тестов. Закрытие предупреждения и зелёная проверка не заменяют оценку последствий обновления.

Если настоящий ключ уже опубликован

Сначала отзовите или замените ключ у его поставщика. Прекратите распространять скомпрометированное значение и проверьте доступные журналы использования. Удаление строки на GitHub не лишает прежний ключ силы в исходном сервисе.

Затем определите, где значение оказалось: текущие файлы, история, обсуждения, артефакты и чужие копии. По инструкции удаления чувствительных данных выберите необходимые действия. Перепись истории затрагивает других участников и требует согласованного процесса; запускать её наугад не следует.

Новое значение храните подходящим способом и передавайте только нужному процессу. Подтвердите у поставщика, что прежний ключ больше не действует. В обращении об исправлении укажите расположение проблемы без самого значения. Чужие копии могли сохраниться даже после очистки репозитория.

Полезные сценарии

Подготовить проект к передаче коллеге. Вход — свои файлы и известный состав получателей. Проверьте видимость, роли, приложения и каждую отправляемую правку. Итог — понятная аудитория и перечень допустимых файлов. Эта проверка не подтверждает отсутствие секретов во всей старой истории.

Подключить инструмент для одной задачи. Определите нужный репозиторий, действие и срок доступа. Сопоставьте их с правами приложения или токена и подтвердите только требуемый объём. Результат — объяснимый доступ, который можно позднее пересмотреть. Приложение может иметь отдельные правила хранения полученных данных.

Разобрать предупреждение зависимости. У вас есть конкретный Dependabot alert. Проверьте пакет и версию, изучите исправление, выполните штатные тесты и зафиксируйте результат. Получится обоснованное решение об обновлении. Автоматический PR не гарантирует совместимость.

Начальная проверка заканчивается конкретными наблюдениями и действиями. Если неизвестно, кто получает доступ или что окажется в истории, выясните это до отправки файлов.

Следующий шаг

Чтобы понимать, какие файлы попадают в историю и отправляются на сервер, изучите Git для новичков: установка, первый репозиторий и базовые команды.

Перед передачей проекта команде полезно составить короткий список действующих доступов и определить, кто их пересматривает.

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov.