requirements.txt: основной инструмент или скрытая угроза?
В каждом проекте Python есть этот невинный на вид requirements.txt Находящийся в корне вашего репозитория, файл pip install requirements.txt consumes, конечно, представляет собой список зависимостей, но если вы не будете осторожны, это может стать причиной нестабильных сборок, уязвимых пакетов и серьезных проблем с безопасностью.
В его ядре, requirements.txt контролирует, какие сторонние пакеты использует ваше приложение. Когда вы запускаете pip install -r requirements.txtМенеджер пакетов Python устанавливает все перечисленные зависимости. Но вот в чём загвоздка: если вы не закрепите точные версии, вы… доверяя PyPI Всегда предоставлять безопасную, совместимую и неизменённую версию. Современная система безопасности приложений работает иначе.
Без закрепления сборки могут быть нарушены. Хуже того, ваше приложение может непреднамеренно использовать вредоносные пакеты. Открытое управление версиями (Колба >=1.0, например) или слабые ограничения версий (джанго~=3.2) — благоприятная среда для внедрения небезопасного кода. Вот почему важно правильно управлять requirements.txt является основной задачей обеспечения безопасности.
Где pip замораживается и где pip устанавливает требования.txt
заморозка пипса удобно, но также опасно, если использовать без понимания того, что оно фиксирует. Разработчики часто генерируют requirements.txt через требования к заморозке pip.txt, ожидая, что это заблокирует их среду. Но заморозка не проверяет безопасность или происхождение зависимостей; она просто сбрасывает все установленные в данный момент пакеты, включая транзитные и потенциально устаревшие.
А теперь представьте, что ваш товарищ по команде или ваш главный инженер слепо бежит pip install -r requirements.txt. Если этот файл содержит устаревшие, уязвимые или даже пакеты с ошибками в коде, вы только что автоматизировали инцидент безопасности.
Короткий пример:
# Developer's freeze output
pip freeze > requirements.txt
boto3==1.24.20
requests==2.27.1
⚠️ Небезопасный пример, не использовать в продакшене
Теперь добавьте это в свой CI pipeline:
- name: Install dependencies
run: pip install -r requirements.txtВы верите, что среда воспроизводима, что в PyPI ничего не изменилось и что каждая зависимость всё ещё в безопасности. Это слишком смелое предположение, когда полагаешься на требования к заморозке pip.txt рабочих процессов.
Реальные угрозы безопасности приложений: тайпсквоттинг и путаница с зависимостями в requirements.txt
Злоумышленники любят экосистемы с открытым исходным кодом. Почему? Потому что разработчики часто полагаются на настройки по умолчанию и подразумеваемое доверие. Вот как они атакуют, используя requirements.txt:
- Typosquatting: Загрузка вредоносного пакета с именем типа запросы вместо Запросы. Один символ — и ваша сборка уже в собственности.
запросы # ⚠️ Иллюстративный пример, а не реальный пакет для установки
- Путаница зависимостей: Если ваш внутренний пакет не закреплён или не имеет приватной области действия, злоумышленники могут опубликовать вредоносную версию в PyPI с тем же именем. Если ваша CI не проверяет исходные коды, вы установите их пакет вместо своего.
Обе атаки используют отсутствие строгого контроля над исходным кодом и requirements.txt. Если ваш просто говорит некоторая-внутренняя-библиотека, и ты бежишь pip install requirements.txt в CI он может получить неправильный пакет из неправильного места.
Защита requirements.txt в CI/CD Pipelineс хэшами и закреплением
Вот как закалить requirements.txt против реальных угроз:
- Точные версии штифтов: всегда использовать == для каждого пакета в вашем requirements.txt. Никаких подстановочных знаков, никаких диапазонов.
- Используйте –require-hashes: Это делает pip install -r requirements.txt проверить целостность каждого загруженного пакета.
Пример:
flask==2.2.5 \
--hash=sha256:<actual_hash_here> ⚠️ Наглядный пример, замена на реальный хеш в реальных проектах
- Изолируйте свои сборки: Всегда используйте чистые, минималистичные контейнеры. Никогда не доверяйте слепо базовому изображению.
- Использовать частный индекс PyPI: Размещайте собственный прокси/кэш и зеркалируйте только доверенные пакеты.
Запустить сканирование зависимостей: Интеграция таких инструментов, как пип-аудит или использование SBOMанализ в вашем pipelines.
Пример фрагмента действий GitHub:
- name: Secure install
run: pip install --require-hashes -r requirements.txt⚠️ Образовательный pipeline например, адаптируйтесь к своей среде
Строгое обращение с pip install -r requirements.txt in CI/CD один из самых простых способов снизить риск, связанный с открытым исходным кодом.
Воспроизводимые сборки: сохранение их стабильности в различных средах
Если ваше приложение работает локально, но дает сбой на этапе подготовки или производства, несовместимые зависимости в requirements.txt — обычные подозреваемые. Даже небольшой дрейф приводит к серьёзным проблемам.
Используйте эти стратегии:
- пип-инструменты: Использовать pip-компиляция генерировать requirements.txt от требования.в. Он разрешает зависимости с помощью правильного закрепления.
- Маркеры окружающей среды: Для пакетов, специфичных для ОС, или зависимостей, специфичных для версии Python, используйте маркеры типа platform_system == 'Linux'.
- Кэширование Docker: В CI кэшируйте слои Docker после установки зависимостей из requirements.txt для уменьшения вариативности сборки.
Пример с pip-tools:
# requirements.in
flask
# Compile
pip-compile requirements.in
⚠️ Наглядный пример, фактический результат зависит от вашей среды
Выход полностью закреплен requirements.txt.
Такие инструменты, как заморозка пипса, в сочетании с pip install -r requirements.txt во время сборки требуется дисциплина и дополнительные меры безопасности.
Заключение: уверенное соблюдение ваших требований
Неправильное управление requirements.txt Это не просто плохая практика, это активная угроза безопасности. Незащищённое закрепление, непроверенные установки и слепое доверие к открытым реестрам — вот как злоумышленники используют ваши CI/CD pipeline. Это не теоретические недостатки; они эксплуатируются ежедневно.
Закрепление зависимостей — это больше, чем просто хорошая практика. Это ваша первая линия защиты от атак на цепочку поставок в Python. Объедините это с –require-hashes, изоляция сборки и воспроизводимые инструменты, такие как пип-инструменты, и вы получите pipeline здесь труднее пойти на компромисс.
Используете ли вы pip install requirements.txt Всегда проверяйте и отслеживайте, что входит в ваши сборки локально или в непрерывной интеграции. Такие инструменты, как Ксигени обеспечить прозрачность, соблюдение политики и автоматизированные проверки, которые защищают вашу цепочку поставок Python от требования к заморозке pip.txt на протяжении всего производства.
