Если ключ OpenAI попал в публичный GitHub, сначала отзовите ключ, затем восстанавливайте работу приложения и разбирайтесь с историей Git.
Публично раскрытый ключ нельзя считать безопасным только потому, что он пробыл в репозитории несколько секунд. У того, кто успел его скопировать, остаётся отдельная копия. Поэтому исправление нужно проверить и в настройках OpenAI, и в приложении, и в репозитории.
Проверено 9 ноября 2026 года.
1. Отзовите раскрытый ключ у OpenAI
Откройте настройки API Keys нужного проекта в OpenAI Platform и отзовите скомпрометированный ключ. Если ключ принадлежит рабочему проекту, сразу сообщите ответственному за него: отзыв может остановить сервисы, которые используют этот ключ.
GitHub рекомендует считать опубликованный секрет скомпрометированным. Новый коммит без ключа, удаление файла или пересоздание репозитория не прекращают его действие у провайдера.
OpenAI сообщает, что отключает обнаруженные публично раскрытые ключи. Но ждать автоматического обнаружения не стоит. Отсутствие письма не подтверждает безопасность, а письмо об отключении ещё не отвечает на вопрос, успел ли кто-то использовать ключ.
2. Восстановите работу с новым секретом
Создайте замену и обновите её там, где приложение действительно получает ключ: в серверном окружении, хранилище секретов и настройках CI. Проверьте работу зависимых сервисов. Новый ключ не должен снова попасть в тот же файл, лог или клиентскую сборку.
В документации OpenAI по ключам описана плановая ротация: выпустить замену, обновить приложение, проверить и отозвать старый ключ. При уже подтверждённой публичной утечке оставлять старый секрет действующим ради спокойного планового перехода опасно. Команде нужно отдельно согласовать последствия срочного отзыва.
3. Посмотрите расход и сохраните детали инцидента
Проверьте Usage нужной организации и проекта: есть ли незнакомая активность за период возможной утечки. Запишите время публикации и отзыва, затронутый репозиторий и замеченные отклонения. Не копируйте сам секрет в публичное обсуждение.
OpenAI советует проверять использование и обращаться в поддержку при подозрении на злоупотребление. Отзыв закрывает дальнейший доступ старым ключом, но не отменяет уже выполненные запросы. Автоматический возврат расходов обещать нельзя.
4. Разберитесь с Git-историей и причиной утечки
Удалённая из текущего файла строка может оставаться в прежних коммитах. Даже переписывание истории не очищает чужие клоны и форки. Поэтому GitHub предлагает сначала отозвать секрет, а необходимость очистки истории оценивать отдельно. Переписывание требует согласования с командой и меняет хеши коммитов.
На будущее храните секрет вне исходников: например, в переменной окружения на сервере, а для GitHub Actions используйте GitHub secrets. Проверяйте изменения перед публикацией и подключайте сканирование секретов. Ключ нельзя встраивать в браузерный JavaScript или мобильное приложение: пользователь получает эту копию вместе с программой.
Минимальный результат исправления: старый ключ больше не действует, приложение использует защищённую замену, расход проверен, а путь повторной утечки закрыт.
Последнее редактирование: