Аудит вебхуков

Проверка Webhooks в OpenSSF Scorecard верифицирует, что вебхуки репозитория используют общий секрет для аутентификации поверхности доставки — без него злоумышленник, узнавший URL вебхука, может воспроизводить или подделывать события.

Позиция Apothem по вебхукам

В настоящее время Apothem эксплуатирует ноль внешних поверхностей вебхуков. Каждая событийно-управляемая интеграция использует нативные рабочие процессы GitHub (CI, Scorecard, CodeQL, pip-audit), которые не подпадают под проверку Webhooks в Scorecard.

Будущее управление вебхуками

Когда Apothem обзаведётся поверхностями вебхуков (например, уведомления о выпусках Discord / Matrix, триггеры сборки для нижестоящих потребителей), оператор ОБЯЗАН:

1. Сгенерировать секрет с высокой энтропией (≥ 32 байта, криптографически случайный).
2. Хранить секрет в зашифрованной поверхности секретов репозитория — никогда в исходном коде, никогда в YAML рабочего процесса.
3. Настроить вебхук с этим секретом, чтобы GitHub подписывал заголовок X-Hub-Signature-256 при каждой доставке.
4. Верифицировать подпись на принимающей конечной точке, используя сравнение за постоянное время.
5. Ротировать секрет каждые 12 месяцев ИЛИ в течение 24 часов после любого подозрения на компрометацию.
6. Задокументировать вебхук в этом файле аудита с указанием его назначения, принимающей конечной точки и даты ротации.

Периодичность аудита

Этот файл пересматривается при каждом проходе /security-audit и на каждой контрольной точке перед переключением в рамках инженерии выпусков. Дрейф (например, поверхность вебхука, введённая без записи здесь) является находкой серьёзности HIGH.

Ссылки

• OpenSSF Scorecard — проверка Webhooks
• GitHub — Безопасность вебхуков
• Политика безопасности Apothem