Автоматическая проверка лицензий в GitHub: защита от GPL

Как работает блокировка на уровне PR

Администратор GitHub Enterprise Cloud задаёт политику через набор правил веток (branch protection rules). Новое условие — «Require license compliance check before merge». Механизм прямолинейный: разработчик открывает пул-реквест, система автоматически сканирует каждую новую или изменённую зависимость, сверяет лицензию с утверждённым списком. Нашла несоответствие — аннотирует PR, мерж заблокирован.

Политика настраивается двумя способами. Встроенный список лицензий с категоризацией по степени риска — для тех, кто не хочет копаться в SPDX-идентификаторах вручную. Или ручное добавление SPDX-идентификаторов для нестандартных случаев. Правила каскадятся: централизованная политика на уровне предприятия, потом исключения для конкретных репозиториев. Удобно для организаций, где у одного сервиса Apache-2.0, а у другого — внутренняя лицензия, которую юристы написали на салфетке.

Если разработчик не хочет или не может удалить проблемный пакет, он отправляет запрос на исключение. Для этого вводится новая предопределённая роль — Enterprise Open Source License Policy Manager. Назначенный сотрудник получает уведомление на почту, обрабатывает запрос из консоли предприятия. Цепочка согласования встроена в процесс: без явного действия менеджера мерж невозможен.

Функция доступна клиентам GitHub Enterprise Cloud с лицензиями Advanced Security Code Security. В период публичного превью — бесплатно. После, вероятно, добавят в платный тир.

Атака через «чистый» репозиторий и ИИ-агента

Пока GitHub закрывает одну дыру, исследователи 0DIN (программа bug bounty от Mozilla) вскрывают другую. Сценарий: Claude Code клонирует репозиторий, запускает pip3 install -r requirements.txt. Один из пакетов отказывается работать до инициализации, в ошибке пишет: запусти python3 -m axiom init. Агент, как нормальный стажёр, слушается.

init вызывает setup.sh, который лезет в DNS TXT-запись, достаёт оттуда Base64-пейлоад и исполняет его как команду. На машине разработчика открывается реверс-шелл. Сигнатуры нет ни в репозитории, ни на диске, ни в сетевом трафике — полезная нагрузка лежит в DNS и может переключиться в любой момент без коммита. Атакующий получает шелл с правами разработчика, доступ к переменным окружения, API-ключам, токенам.

Классическая цепочка: безобидный пакет → фейловая ошибка → социальная инженерия агента → реверс-шелл. Никакого эксплойта в коде. Claude Code не пытался открыть шелл — он пытался исправить ошибку.

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

Настроить лицензионную политику, если вы на GitHub Enterprise Cloud и у вас есть Advanced Security. Даже в превью — бесплатно, а повод для включения очевиден.

Для ИИ-агентов единственный реальный костыль сейчас — обязать их показывать полную цепочку команд перед выполнением. Не «pip install прошёл успешно», а конкретно: что ставится, какие скрипты запускаются post-install, откуда тянется динамический код. Исследователи 0DIN предлагают именно это.

# Минимальная проверка зависимостей перед мержём
# В settings → Branches → Branch protection rules
# → Require license compliance check before merge ✓

Напутствие суровое: если ваш CI не проверяет лицензии — это не вопрос «а надо ли», это вопрос «когда прилетит письмо от юристов». Бэкапьте политики, документируйте исключения и не давайте стажёрам мержить GPL в проприетарщину.