Перед тем как выложить AI-проект в open source, проверьте четыре вещи: секреты в git-истории, личные данные пользователей, тип лицензии и содержимое README. Пропустите хотя бы одну, и рискуете отдать в паблик API-ключ, платежный токен или базу email адресов. Ниже — рабочий чеклист с конкретными командами, инструментами и разбором частых ошибок вайбкодеров.
В 2025 году в публичные репозитории GitHub утекло 28,65 млн новых секретов, рост на 34% год к году (GitGuardian). Чеклист закрывает четыре зоны риска: git-история, персональные данные, лицензия, README. Ниже — команды, таблицы сравнения инструментов и итоговый список для копирования.
Как проверить git-историю на секреты перед публикацией?
Обычный git status секреты в истории не покажет. Нужен отдельный проход по всем коммитам через gitleaks, trufflehog или ручной поиск по паттернам ключей.
Секрет, удаленный текущим коммитом, остается доступен через git log -p и в любом форке репозитория. GitGuardian зафиксировала 28,65 млн новых утечек в публичном GitHub за 2025 год, а доля AI-сервисных ключей выросла на 81%. Проверка истории, а не только рабочей копии файлов, обязательна перед публикацией.
Практика простая. Сначала гоните gitleaks или trufflehog по всей истории, не только по HEAD:
gitleaks detect --source . --log-opts="--all"
trufflehog git file://. --only-verifiedGitleaks быстрее и работает офлайн через regex-паттерны, хорошо подходит для pre-commit хука. Trufflehog идет глубже: он реально проверяет, живой ли найденный ключ, через запрос к провайдеру, и заодно смотрит не только git, но и Docker-образы, S3-бакеты. На практике многие команды ставят оба: gitleaks на pre-commit для скорости, trufflehog в CI для проверенных находок.
Что делать если инструмент нашел секрет в старом коммите
Смена ключа в новом коммите ничего не решает, старая версия файла останется в истории навсегда. Для полной зачистки нужен git-filter-repo или BFG Repo-Cleaner. git-filter-repo умеет переписывать историю и удалять файлы или строки из каждого коммита разом, но требует свежего клона репозитория и обязательного пуша тегов перед пушем коммитов. После зачистки старый клон у любого участника команды все еще содержит секрет, поэтому нужно попросить всех удалить локальные копии и клонировать репозиторий заново.
Что делать если секрет уже засветился в GitHub?
Первым делом отозвать сам ключ у провайдера, а уже потом чистить репозиторий. Переписанная история не убирает риск, если ключ остался рабочим.
Скорость реакции решает больше, чем метод очистки. Если утечка произошла в последнем коммите и никто еще не сделал pull, достаточно git reset --hard HEAD~1 локально и git push origin main --force в удаленный репозиторий. Если коммит уже старый или ушел в историю глубже, нужен git-filter-repo или BFG.
Но команда, которая правда работает, а не создает иллюзию безопасности, начинается не с git. Сначала отзовите или перевыпустите сам ключ на стороне провайдера (Stripe, OpenAI, Sanity и любой другой). Только потом чистите историю. Форки и локальные копии у других участников все равно сохранят старую версию файла, поэтому единственная гарантия — мертвый ключ, а не спрятанная история.
GitHub с марта 2026 расширил Push Protection: он по умолчанию блокирует push с паттернами ключей от Figma, Google, OpenVSX, PostHog и десятков других провайдеров, а с мая 2026 добавил MCP Server Secret Scanning — проверку прямо в IDE, до того как AI-агент вообще сформирует коммит. Для проектов, где код пишет Cursor или Claude Code, это первая линия защиты, а не последняя.
Максим: «Когда мы прогнали этот чеклист по нашему порталу VibeCoderz, нашли реальный токен Sanity прямо в .env.example. Лежал там месяцами, никто не заметил. Поменяли токен за 10 минут, но это тот случай, когда лучше проверить самому, чем узнать от кого-то другого.»
Какие личные данные нужно убрать из репозитория?
Помимо API-ключей в публичный код часто попадают email пользователей, тестовые базы данных и реальные .env файлы. Проверяйте не только git secrets, но и содержимое дампов и фикстур.
Личные данные утекают не только через переменные окружения. Тестовые фикстуры с реальными email из продакшена, экспортированные CSV с контактами пользователей, скриншоты админки с чужими данными в интерфейсе — все это регулярно оказывается в открытых репозиториях AI-стартапов.
Перед публикацией пройдитесь по трем местам. Первое: .env, .env.local, любые файлы с реальными ключами, они должны быть в .gitignore с самого первого коммита, а не добавлены задним числом. Второе: папки scripts/, seed/, fixtures/— там часто лежат тестовые данные, скопированные из боевой базы. Третье: логи и дампы в docs/ или debug/, если такие копились во время разработки.
Если проект собирался вайбкодингом за несколько дней, риск выше обычного: AI-агент часто сохраняет реальные значения из первого рабочего .env, потому что для него это просто рабочий контекст, а не чувствительные данные.
Какую лицензию выбрать для open source AI проекта?
MIT подходит для максимально свободного распространения без юридической возни. Apache 2.0 добавляет патентную защиту, важную для корпоративных пользователей. GPL и AGPL заставляют форки оставаться открытыми, включая SaaS-версии.
Без файла лицензии код формально остается под всеми правами автора, и никто не может легально его использовать, даже если репозиторий публичный. Выбор конкретной лицензии определяет, смогут ли компании форкнуть проект в закрытый продукт.
| Лицензия | Что разрешает | Когда выбирать |
|---|---|---|
| MIT | Коммерческое использование, модификация, включение в закрытый код | Максимальное распространение, минимум условий |
| Apache 2.0 | То же, что MIT, плюс патентная защита автора и пользователей | Проект с потенциальными патентными рисками, корпоративная аудитория |
| GPL v3 | Использование и модификация, но производный код обязан остаться открытым | Хотите, чтобы форки тоже были open source |
| AGPL v3 | Как GPL, но требование открытости распространяется и на SaaS-развертывание | SaaS-продукт, где важно закрыть лазейку с закрытыми форками в облаке |
Для большинства AI-инструментов и библиотек, которые вайбкодеры выкладывают на GitHub ради портфолио или комьюнити, разумный дефолт — MIT. Apache 2.0 имеет смысл, если в проекте есть собственные алгоритмы или интеграции, где патентный риск реален. GPL и AGPL выбирают осознанно, когда цель — не дать конкурентам взять код и закрыть его в платном SaaS.
Если проект зависит от сторонних библиотек, проверьте совместимость лицензий отдельно: GitHub Dependency Review автоматически подсвечивает конфликты лицензий прямо в Pull Request, до мержа.
Что обязательно должно быть в README перед публикацией?
README — первая и часто единственная точка контакта с проектом. Без установки, примера использования и лицензии в первых экранах разработчик закрывает вкладку за 30 секунд.
README решает, останется человек на странице проекта или уйдет. Минимальный рабочий набор: короткое описание что делает проект и зачем, команда установки, один рабочий пример использования без лишних шагов, ссылка на лицензию, и раздел с известными ограничениями.
Отдельно стоит указать, какие переменные окружения нужны для запуска, но без реальных значений. Файл .env.example должен содержать только имена переменных и заглушки вида your_api_key_here, а не значения, скопированные из рабочего .env. Именно так реальный секрет чаще всего и попадает в публичный репозиторий — через .env.example, который скопировали "для примера" и забыли почистить.
Какие инструменты автоматизируют проверку перед публикацией?
Полный набор проверок закрывают три слоя: pre-commit сканер, CI-проверка с верификацией ключей и встроенная защита GitHub. По отдельности каждый слой пропускает часть утечек.
Ручная проверка перед каждым коммитом не масштабируется, особенно если код частично пишет AI-агент. GitGuardian сообщает, что 64% секретов, утекших еще в 2022 году, до сих пор остаются рабочими, то есть их просто никто не отозвал вовремя.
| Инструмент | Слой защиты | Особенность |
|---|---|---|
| Gitleaks | Pre-commit, локально | Работает офлайн, блокирует коммит за миллисекунды, MIT-лицензия |
| TruffleHog | CI/CD | Проверяет, живой ли найденный ключ, через запрос к провайдеру |
| GitHub Secret Scanning + Push Protection | На push, встроено в GitHub | Включено по умолчанию для публичных репозиториев, с марта 2026 покрывает 39+ типов токенов |
| GitHub Dependency Review | Pull Request | Ловит уязвимые зависимости и конфликты лицензий до мержа |
На практике рабочая связка выглядит так: gitleaks в pre-commit хуке ловит очевидное на лету, GitHub Push Protection стоит второй линией на самом сервере, а TruffleHog раз в CI-пайплайне проверяет, не остались ли в истории живые ключи, которые обошли первые два слоя. Отдельный чек-лист из 14 пунктов для upstream-мейнтейнеров публикует OpenSSF Security Baseline — он покрывает не только секреты, но и подпись коммитов, MFA и SBOM.
Если вы ведете DevOps для своего AI-стартапа и хотите не держать весь этот чеклист в голове, посмотрите каталог агентов VibeCoderz: там есть готовые промпты под настройку CI-безопасности под конкретную задачу.
Итоговый чеклист перед публикацией open source AI проекта
Соберите все проверки в один прогон перед тем, как нажать «Make public».
| Пункт | Что делать | Инструмент |
|---|---|---|
| Секреты в истории | Прогнать всю историю, не только HEAD | gitleaks, trufflehog |
| Утекший ключ | Сначала отозвать у провайдера, потом чистить git | git-filter-repo, BFG |
| .env и фикстуры | Только имена переменных, без реальных значений | .gitignore с первого коммита |
| Личные данные | Проверить seed, dumps, скриншоты в docs | ручной аудит |
| Лицензия | Выбрать LICENSE файл осознанно | MIT / Apache 2.0 / GPL / AGPL |
| Зависимости | Проверить конфликты лицензий сторонних пакетов | GitHub Dependency Review |
| README | Установка, пример, лицензия, ограничения | ручная проверка |
| Push Protection | Включить перед первым публичным пушем | GitHub Settings → Code security |
Частые вопросы о публикации AI проекта в open source
Можно ли просто удалить .env из репозитория и все? Нет. Удаление файла в новом коммите не убирает его из старых коммитов. Файл остается доступен через git log и в любом форке, пока историю не переписать через git-filter-repo или BFG.
GitHub Secret Scanning точно поймает все ключи? Нет. Push Protection блокирует только новые push и только известные паттерны, около 39 типов токенов на март 2026. Старую историю он не сканирует, поэтому нужен отдельный проход gitleaks или trufflehog по всем коммитам.
Обязательно ли добавлять LICENSE файл? Да, если хотите, чтобы код легально использовали. Без файла лицензии репозиторий публично виден, но юридически не открыт для использования, даже с открытым исходным кодом на экране.
Чем GPL отличается от AGPL для AI-продукта? GPL требует, чтобы производный код оставался открытым при распространении. AGPL закрывает лазейку с SaaS: если модифицированную версию запускают как облачный сервис, исходники все равно обязаны быть открыты.
Что делать, если проект писал в основном AI-агент? Проверять тщательнее, а не меньше. AI-агенты часто сохраняют рабочие значения из первого .env как обычный контекст, потому что для модели это просто текст, а не секрет.
Сколько времени занимает полный чеклист? На небольшом проекте, если ничего критичного не найдено, вся проверка занимает 15-30 минут. Если находится живой ключ, время съедает не проверка, а его отзыв у провайдера.
Глоссарий терминов из чеклиста
Секрет — API-ключ, токен, пароль или другая учетная запись, дающая доступ к системе. Push Protection — механизм GitHub, блокирующий отправку коммита, если в нем найден паттерн известного секрета. Git-история — полный список всех коммитов репозитория, включая удаленные позже изменения. Copyleft-лицензия — тип лицензии (GPL, AGPL), требующий, чтобы производные проекты оставались открытыми. Permissive-лицензия — тип лицензии (MIT, Apache 2.0) с минимумом условий на использование кода.
Если после чеклиста остались вопросы по конкретному стеку или лицензированию своего AI-продукта, разберите их на консультации с Максимом: t.me/maxnagovitsyn. Полный каталог AI-инструментов для разработки и проверки кода — в каталоге VibeCoderz.