Как создать и поддерживать список доверенных репозиториев для разработчиков

В современной разработке приложений зависимость от сторонних пакетов становится нормой, но одновременно открывает путь для атак цепочки поставок. Список доверенных (whitelist) репозиториев позволяет ограничить источники, из которых система может загружать библиотеки, и тем самым снизить вероятность установки вредоносного или не проверенного кода.

Почему нужен список доверенных репозиториев

Основные причины:

• Защита от подмены пакетов (typosquatting, компрометированные учетные записи).
• Контроль над лицензиями и качеством используемых зависимостей.
• Упрощение аудита и соблюдения внутренних политик безопасности.
• Снижение нагрузки на внешние сети за счёт кеширования в артефакториуме.

Основные принципы формирования whitelist

Прежде чем приступать к технической настройке, полезно сформулировать правила, которым будут следовать все репозитории в списке:

• Проверка подлинности. Репозиторий должен поддерживать криптографическую подпись пакетов или хотя бы предоставлять хеши, которые можно проверить.
• Репутация и прозрачность. Предпочтительно использовать официальные репозитории языков или проверенные корпоративные артефакториумы.
• Минимализм. Включайте только те источники, которые реально нужны для текущих проектов.
• Регулярное обновление. Периодически пересматривайте список, удаляя устаревшие или неподтверждённые репозитории.

Пошаговый процесс создания списка доверенных репозиториев

1. Определите_scope. Установите, для каких языков и пакетных менеджеров будет применяться whitelist (npm, pip, Maven, Gradle, NuGet и др.).
2. Соберите текущие зависимости. Запустите команду вывода дерева зависимостей (например, npm ls, pip freeze, mvn dependency:tree) и сохраните список используемых пакетов.
3. Определите источники каждого пакета. Для каждого пакета укажите, из какого репозитория он обычно загружается (официальный registry, внутренний артефакториум, форк и т.д.).
4. Проверьте источники на соответствие принципам. Отфильтруйте те, которые не поддерживают подписи, имеют сомнительную репутацию или не нужны.
5. Сформируйте конфигурационный файл whitelist. В зависимости от инструмента это может быть файл .npmrc, секция [trusted-host] в pip.conf, настройки proxy в settings.xml Maven или аналогичные.
6. Интегрируйте whitelist в процесс сборки и CI/CD. Убедитесь, что скрипты сборки ссылаются только на одобренные репозитории и что попытка обратиться к другому источнику приводит к ошибке.
7. Настройте мониторинг и алерты. Логируйте запросы к репозиториям и получайте уведомления о попытках доступа к недоверенным источникам.
8. Планируйте регулярный пересмотр. Установите интервал (например, раз в квартал) для проверки актуальности списка и добавления новых доверенных источников при необходимости.

Настройка whitelist для популярных пакетных менеджеров

npm (Node.js)

Для npm можно использовать параметр registry в файле .npmrc или переменную окружения NPM_CONFIG_REGISTRY. Пример:

registry=https://registry.npmjs.org/

Если вы используете внутренний прокси (например, Nexus или Artifactory), укажите его URL. Чтобы блокировать доступ к другим registries, установите strict-ssl=true и укажите файл ca с корневыми сертификатами вашего прокси.

pip (Python)

В файле pip.conf (или pip.ini на Windows) добавьте секцию:

[global]

index-url = https://pypi.org/simple/

extra-index-url = https://my.internal.repo/pypi/simple/

[install]

trusted-host = pypi.org

trusted-host = my.internal.repo

Параметр trusted-host указывает, какие хосты считаются безопасными для загрузки по HTTP; для HTTPS достаточно проверить сертификат.

Maven и Gradle (JVM)

В settings.xml Maven определите mirrors и repositories. Пример mirror, который перенаправляет все запросы на внутренний артефакториум:

internal-mirror

*

https://artifactory.example.com/artifactory/libs-release

Для Gradle аналогично в init.gradle или через repositories { maven { url «https://artifactory.example.com/artifactory/libs-release» } }.

NuGet (.NET)

В файле NuGet.Config задайте packageSources и optionally disabledPackageSources:

Типичные ошибки и как их избегать

• Слишком широкий whitelist. Добавление «всех известных» репозиториев нивелирует пользу. Решение: начинайте с минимального набора и расширяйте только после явной необходимости.
• Отсутствие проверки подписей. Некоторые репозитории позволяют загрузку без проверки подписи, что открывает путь для атаки «person-in-the-middle». Решение: включайте строгую проверку TLS и, где возможно, проверку подписей пакетов.
• Жёсткая привязка к конкретному URL без резерва. Если внутренний артефакториум недоступен, сборка ломается. Решение: настройте fallback на официальный реестр, но только после подтверждения его доверия.
• Игнорирование transitive dependencies. Даже если ваш whitelist чист, зависимости могут тянуть пакеты из других источников. Решение: используйте блокировку версий (lock‑files) и сканируйте дерево зависимостей на наличие недоверенных источников.
• Отсутствие аудита изменений. Изменения в конфигурации whitelist могут пройти незамеченно. Решение: храните конфигурацию в системе контроля версий и требуйте код‑ревью для любых правок.

Как проверить, что whitelist работает правильно

1. Выполните чистую сборку в изолированном окружении (например, в свежем Docker контейнере).
2. Попытайтесь установить пакет из известного непроверенного источника (например, пакет с похожим именем на легитимный, но опубликованный в публичном реестре без вашего доверия). Сборка должна завершиться ошибкой.
3. Проверьте логи артефакториума или прокси: все запросы должны идти только на одобренные URL.
4. Запустите инструмент сканирования зависимостей (например, npm audit, pip-audit, OWASP Dependency-Check) и убедитесь, что он не сообщает о неизвестных источниках.

Поддержка и обновление списка

Whitelist — это не статический набор, а живой artefact. Рекомендуемые практики:

• Вести журнал изменений: кто, когда и почему добавил или удалил репозиторий.
• Автоматизировать проверку новых зависимостей: при добавлении нового пакета в проект автоматически сверять его источник с whitelist.
• Использовать группы репозиториев в артефакториуме (например, public‑proxy, internal‑release, snapshot) и включать в whitelist только группы, а не отдельные URL.
• Проводить краткие тренинги для команды, чтобы каждый разработчик понимал, почему нельзя менять реестр вручную без согласования.

Практический следующий шаг

1. Соберите текущий список зависимостей одного из ваших проектов.
2. Определите, из каких официальных реестров они приходят.
3. Создайте базовый whitelist, содержащий только эти официальные источники (или ваш внутренний артефакториум, если он уже используется).
4. Добавьте этот whitelist в конфигурационные файлы пакетных менеджеров и зафиксируйте изменения в системе контроля версий.
5. Запустите пробную сборку в чистом окружении и убедитесь, что всё работает без обращения к сторонним источникам.

После этого постепенно расширяйте список, следуя описанным выше принципам проверки и документирования.

Материал носит информационный характер и не заменяет консультацию специалиста по безопасности программного обеспечения. При внедрении изменений в критические инфраструктуры рекомендуется провести тестирование в изолированной среде и, при необходимости, привлечь эксперта по защите цепочки поставок.