flawopen.com/Справочник/Dependency Confusion

Dependency Confusion: подмена источника пакета

High Severity CWE-829: Inclusion of Functionality from Untrusted Control Sphere Цепочка поставок ПО

Простое объяснение — Поставщик с похожим названием

Представьте, что команда заказывает компонент по каталогу, где два поставщика используют одинаковое название товара. Если правила не определяют доверенного поставщика, сборка может получить неожиданный компонент. Dependency Confusion — ошибка выбора источника пакета: сборка разрешает имя из реестра или пространства имён, которому организация не собиралась доверять.

Boundary: Имя пакета, пространство имён, конфигурация реестра и происхождение lock-файла

Failure: Резолвер может получить одноимённый пакет из непредусмотренного источника

Impact: В сборку может попасть непроверенный сторонний код; включённые сценарии установки могут выполняться

Remediation: Явные правила namespace-реестр, проверенные lock-файлы и сборки с минимальными правами

Как возникает Dependency Confusion

Поведение зависит от менеджера пакетов и его настроек. Например, документация pip предупреждает: сочетание частного --index-url с публичным --extra-index-url может привести к выбору одноимённого публичного пакета. npm выбирает реестр по scope пакета или настройке по умолчанию; он не всегда сравнивает частную и публичную версии и выбирает большую. Общая причина — неоднозначная политика источников. Если пакет установлен и его сценарии включены, они выполняются с правами задачи сборки.

pip.conf и requirements.txt (неоднозначные источники)Рискованная конфигурация

[global]
index-url = https://packages.example.internal/simple
extra-index-url = https://pypi.org/simple

corp-auth-utils

.npmrc и package.json (явная маршрутизация scope)Укреплённый пример

@corp:registry=https://packages.example.internal/repository/npm/

{
  "dependencies": {
    "@corp/billing-engine": "1.2.0"
  }
}

Возможная цепочка сбоя

1Имя внутреннего пакета или namespace становится известно за пределами организации.
2В публичном реестре есть пакет с таким же именем без scope либо политика разрешает этому реестру обработать запрос.
3Резолвер выбирает непредусмотренный источник; lock-файл или проверка могут не выявить подмену, если файл отсутствует, пересоздан или принят без проверки.
4При включённых сценариях установки или сборки код пакета выполняется с правами задачи. Последствия зависят от учётных данных, сети и изоляции; права root не являются обязательным условием этой атаки.

Защитные инженерные меры

✓Задайте явную политику источников: используйте организационные scopes или namespaces, направляйте их в нужный реестр и запрещайте переход к публичным источникам для частных имён. В Python не сочетайте частный индекс с --extra-index-url для частных пакетов; используйте контролируемый proxy или единственный доверенный индекс.
✓Контролируйте владение namespace: резервируйте имена организации, если реестр это поддерживает, но не считайте резервирование заменой политике резолвера. Ведите перечень внутренних имён и отслеживайте совпадения в публичных реестрах.
✓Проверяйте lock-файлы: храните lock-файл и используйте режим установки CI без изменения дерева (для npm — npm ci). Проверяйте изменения имён, URL реестров, версий и контрольных значений. Lock-файл повышает воспроизводимость, но не доказывает подлинность источника.
✓Ограничьте выполнение сборки: отключайте сценарии зависимостей, если проект работает без них, и проверяйте исключения. Используйте краткосрочные учётные данные с минимальными правами, изолируйте сборку от production-секретов и ограничьте исходящий сетевой доступ.

Связанные темы безопасности и разборы инцидентов:Каталог безопасности →

Источники

См. также Доступ к сокету Docker: риски и защита Инъекция скриптов GitHub Actions: безопасный ввод Cosign GHSA-fx35-mq7g-6g98: обход проверки