Безопасность публичных репозиториев и собственных хранилищ артефактов не теряет своей актуальности с возросшим количеством атак на цепочку поставки. Оценивать важно, оценивать нужно.
В феврале 2024 года в сообществе Open Source Security Foundation (OSSF) были опубликованы Принципы безопасности пакетных репозиториев, которые не потеряли своей актуальности и сегодня.
Команда CodeScoring подготовила перевод и делится с сообществом.
Авторы оригинала: Jack Cable (CISA), Zach Steindler. Предложить улучшения можно в репозитории рабочей группы.
Контекст
Рабочая группа OpenSSF Securing Software Repositories подготовила разбор пакетных репозиториев и принципов для их защиты. Цель документа — предложить лучшие практики, к которым репозиториям стоит стремиться.
Под пакетным репозиторием (или реестром пакетов) мы понимаем сервис, который хранит и индексирует пакеты, позволяя пользователям и инструментам скачивать их. Часто для скачивания пакетов применяют CLI-инструмент, а в некоторых экосистемах их сразу несколько. Большая часть описанных защитных мер относится к самому репозиторию, но отдельный раздел посвящен мерам безопасности CLI-инструментов.
Не все рекомендации по безопасности применимы ко всем репозиториям. Например, https://proxy.golang.org/ не управляет учетными записями пользователей, поэтому ему не нужна документированная процедура восстановления аккаунта.
Особенности репозиториев пакетов
Набор защитных мер зависит от того, какие функции предоставляет репозиторий пакетов. Например, если в репозитории есть учетные записи пользователей, он должен безопасно реализовывать аутентификацию. В этом разделе перечислены значимые характеристики репозиториев пакетов.
Есть ли у репозитория пакетов учетные записи пользователей?
Да: тогда нужно управлять аутентификацией, восстановлением аккаунтов и связанными процессами. Пример: PyPI.
Нет: например, {index, proxy, sum}.golang.org.
Как репозиторий работает с пакетами?
Принимает собранные пакеты: например, npm.
Выполняет сборку за пользователей: например, Homebrew.
Только размещает исходный код: например, {index, proxy, sum}.golang.org.
Защитные меры репозиториев пакетов
Документ определяет четыре уровня зрелости безопасности:
Уровень 0 — очень низкая зрелость безопасности.
Уровень 1 — базовая зрелость безопасности, включая основные защитные функции: многофакторную аутентификацию (MFA) и возможность для исследователей безопасности сообщать об уязвимостях. Все экосистемы управления пакетами должны стремиться как минимум к этому уровню.
Уровень 2 — средний уровень безопасности, включая такие меры, как обязательная MFA для критически важных пакетов и предупреждения пользователей об известных уязвимостях.
Уровень 3 — продвинутый уровень безопасности, включая обязательную MFA для всех мейнтейнеров и поддержку сведений о происхождении сборки пакетов. Этот уровень — скорее ориентир, особенно для небольших экосистем управления пакетами.
Эти уровни разделены на четыре направления, описанные ниже: аутентификация, авторизация, общие возможности и CLI-инструменты. Не все направления применимы ко всем пакетным репозиториям, как указано выше. Такое разделение помогает репозиториям оценивать безопасность по разным аспектам.
Аутентификация
Применимо к репозиториям пакетов, в которых есть учетные записи пользователей.
Уровень 1
Репозиторий пакетов требует от пользователей подтвердить адрес электронной почты. Это гарантирует, что при потере доступа к аккаунту пользователь сможет его восстановить.
Репозиторий пакетов документирует политику восстановления аккаунта.
Репозиторий пакетов поддерживает надежную многофакторную аутентификацию (MFA), как минимум через TOTP. Если репозиторий предлагает только более слабые формы MFA, например, SMS, email или телефонный звонок, этого недостаточно.
Репозиторий пакетов уведомляет мейнтейнеров по email о критически важных изменениях безопасности аккаунта, например, о смене пароля или отключении MFA. Это помогает пользователям обнаружить компрометацию аккаунта.
Репозиторий пакетов реализует меры защиты аккаунтов, например, предотвращение перебора, включая попытки второго фактора при 2FA.
Уровень 2
Чтобы предотвратить захват аккаунта через восстановление доступа при перерегистрации заброшенного домена, репозиторий пакетов отслеживает заброшенные email-домены. Например, он может выполнять WHOIS-проверку всех зарегистрированных email-доменов и отключать восстановление аккаунта для адреса на заброшенном домене.
Репозиторий пакетов поддерживает MFA с защитой от фишинга, например, WebAuthn.
Репозиторий пакетов требует MFA для пакетов, признанных критически важными, например, для 1% самых популярных пакетов по числу загрузок.
Репозиторий пакетов интегрируется с публичными базами скомпрометированных учетных данных, например, Have I Been Pwned, чтобы при входе выявлять пользователей, использующих известные утекшие пароли. Если при входе обнаруживается такой пароль, репозиторий предлагает пользователю сменить его. При регистрации система проверяет пароли и не позволяет пользователям регистрироваться с известными скомпрометированными паролями.
Уровень 3
Репозиторий пакетов поддерживает вход без пароля, например, через passkeys.
Репозиторий пакетов требует MFA для всех мейнтейнеров.
Репозиторий пакетов требует MFA с защитой от фишинга для пакетов, признанных критически важными, например, для 1% самых популярных пакетов по числу загрузок. Если возможно, репозиторий предоставляет таким мейнтейнерам аппаратные ключи безопасности.
Авторизация
Применимо к репозиториям пакетов, в которых есть учетные записи пользователей и которые принимают собранные пакеты.
Уровень 1
Репозиторий пакетов позволяет мейнтейнерам выпускать API-ключи, ограниченные конкретными пакетами. Это позволяет поддерживать пакеты через автоматизированные процессы без передачи пароля от аккаунта.
API-токены имеют префикс, уникальный для конкретного репозитория пакетов.
Уровень 2
Репозиторий пакетов поддерживает ролевую модель доступа (RBAC) для мейнтейнеров, позволяя разделять роли управления пользователями и публикации пакетов.
Уровень 3
Репозиторий выпускает краткосрочные API-токены через обмен OpenID Connect (OIDC), чтобы не требовать долгосрочные API-ключи. Пример: trusted publishers.
API-токены пакетного репозитория распознаются распространенными инструментами поиска секретов. Обычно для этого нужен известный префикс или шаблон, чтобы снизить число ложных срабатываний. Кроме того, репозиторий пакетов предоставляет эндпоинт для сообщений об утекших секретах, через который такие программы могут сообщать о скомпрометированных учетных данных, а репозиторий автоматически отзывает действительные токены.
Пакетный репозиторий поддерживает публикацию сведений о происхождении сборки пакетов.
Общие меры
Применимо ко всем репозиториям пакетов.
Уровень 1
Репозиторий пакетов публикует политику раскрытия уязвимостей, позволяющую исследователям безопасности находить и сообщать об уязвимостях в самом репозитории пакетов и получать правовую защиту, если они действуют в рамках требований этой политики. Репозиторию следует исправлять выявленные уязвимости в течение 90 дней.
Репозиторий пакетов принимает меры против typosquatting-атак, связанных с именами пакетов. Это может включать пространства имен, обнаружение похожих имен или другие действия.
Уровень 2
У репозитория пакетов есть политика снятия пакетов с публикации, которая не позволяет заменять конкретные версии пакета, а при удалении пакета не дает другим пользователям повторно использовать то же имя пакета и ту же версию.
Репозиторий пакетов позволяет пользователям сообщать о подозрительном или вредоносном пакете через интерфейс реестра, CLI-инструмент и API.
Репозиторий пакетов принимает меры для обнаружения вредоносного ПО, включая сканирование на известные фрагменты вредоносного кода и хеши.
Репозиторий пакетов отображает в интерфейсе предупреждения об известных уязвимостях в зависимостях.
Уровень 3
Репозиторий пакетов регулярно проходит аудит безопасности инфраструктуры. Опционально он также публикует информацию об устраненных проблемах.
Репозиторий пакетов публикует журнал прозрачности событий для выявления аномальной активности. Пример: replicate.npmjs.com.
Уведомления о вредоносных пакетах публикуются в стандартизированном машиночитаемом формате, например, через схему OSV и агрегацию в сервисе OSV (например, здесь).
CLI-инструменты
Применимо ко всем экосистемам управления пакетами, хотя здесь основной фокус сделан на CLI-инструментах, а не на самом реестре.
Уровень 1
CLI позволяет устанавливать зависимости, зафиксированные по хешу, версии и другим параметрам.
Уровень 2
CLI предупреждает об известных уязвимостях в зависимостях при установке пакетов.
Уровень 3
CLI поддерживает генерацию SBOM.
CLI поддерживает автоматическое исправление известных уязвимостей в зависимостях путем обновления там, где это возможно.
Репозиторий пакетов может снижать число ложных срабатываний при поиске уязвимостей с помощью статического анализа, чтобы определить, достижим ли уязвимый участок кода на практике. Пример: функция vulncheck в Go.
Подписывайтесь на Codescoring в Telegram, МАКСе, YouTube или VK.