Безопасность зависимостей

Наш исходник выражает несколько защитных правил, но значительную работу выполняют библиотеки. Flask обрабатывает HTTP и сессию, Werkzeug проверяет пароль, Pillow разбирает изображение. Состав этих зависимостей становится частью состояния приложения.

Результат урока — процесс фиксации окружения и проверки известных уязвимостей. Такой отчёт не доказывает безопасность всего кода. Он отвечает на более узкий вопрос: что установлено и какие опубликованные сведения относятся к этому составу на дату проверки.

Диапазон и конкретный состав

Начальный requirements.txt задаёт линии API. Для заключительного изображения добавлен Pillow. Выбранный набор выглядит так:

Flask>=3.1,<3.2
Werkzeug>=3.1,<3.2
Pillow==12.3.0

Это намерения установки, а не полный снимок окружения. Разные моменты разрешения диапазона могут выбрать разные патч-версии и транзитивные зависимости. Поэтому сравнение двух выпусков требует знать фактически установленный состав.

Точная версия Pillow здесь соответствует изученной линии документации на дату подготовки. Она не является бессрочным обещанием отсутствия ошибок. Перед самостоятельным выпуском нужно проверить актуальные рекомендации и совместимость, а не считать номер универсально безопасным.

Сохранить только три прямых имени недостаточно. Библиотека может зависеть от других пакетов; они тоже участвуют в выполнении. Некоторые возможности дополнительно опираются на системные компоненты, которые не представлены обычной строкой Python-пакета.

Снимок окружения

Для известного локального окружения читатель сохраняет разрешённые версии. Например, после самостоятельной установки:

.venv/bin/python -m pip freeze > requirements.lock.txt

Команда описывает будущую практику, при подготовке курса она не выполнялась. Полученный файл нужно просмотреть: необычные локальные пути или сведения о частном источнике не должны случайно попасть в публичный материал.

Freeze фиксирует состав Python-окружения, но не создаёт полный воспроизводимый образ. Платформа, Python, системные библиотеки и параметры сборки могут различаться. Для строгой поставки нужны дополнительные сведения и проверка установки на целевой системе.

Хеши дистрибутивов и утверждённый источник помогают контролировать поставку байтов. При этом один хеш не подтверждает отсутствие вредного поведения: он отвечает за соответствие ожидаемому файлу. Происхождение и содержание являются отдельными вопросами.

Проверка известных проблем

Для проверки Python-зависимостей можно использовать pip-audit в отдельном инструментальном окружении. Ниже последовательность для собственного известного файла требований:

python3.12 -m venv .audit-venv
.audit-venv/bin/python -m pip install pip-audit
.audit-venv/bin/pip-audit -r requirements.lock.txt -f json -o audit.json

Инструмент может разрешать зависимости и обращаться к службам сведений. Его не следует рассматривать как безопасное исполнение произвольного чужого файла. Область и модель работы описаны в официальном проекте pip-audit.

Отдельное окружение не означает полную изоляцию враждебного кода. Здесь оно разделяет инструменты и runtime учебного приложения. Для анализа неизвестной поставки нужна другая модель окружения.

Отчёт с отсутствием найденных известных уязвимостей имеет ограниченный смысл. Он не проверяет условие owner_id в нашем SQL, CSRF middleware или внешнюю конфигурацию. Отсутствие совпадения базы предупреждений не подтверждает отсутствие всех возможных ошибок.

Разбор найденного сообщения

Если опубликованная проблема относится к пакету, сначала сопоставьте версии, условия и используемую функцию. Затем выберите исправленную поставку или другую обоснованную меру. Автоматическое обновление всего окружения может нарушить работу интерфейса и зависимостей.

Нельзя игнорировать сообщение только потому, что приложение маленькое. Но нельзя и объявлять конкретный маршрут уязвимым, не прочитав условия проблемы. Правильный отчёт разделяет факт версии, применимость и решение.

Для временного исключения сохраняются причина, ответственный и срок пересмотра. Простой список ignore без объяснений быстро теряет смысл. При изменении функции приложения прежнее исключение может стать неправильным.

Не подставляйте вымышленные CVE и результаты аудита в учебный отчёт. В нашей редакционной заметке состояние проверки честно обозначено как невыполненное. Пример структуры решения можно объяснить без утверждения о реальной найденной уязвимости.

Обновление как выпуск

Изменение библиотеки должно иметь идентификатор выпуска и повторную проверку поведения. Например, новая версия Pillow может по-другому отвергать повреждённый файл, а Werkzeug изменить параметры формирования хеша. Такие изменения нужно сопоставить с текстом урока.

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

После обновления выполняются те же контрольные сценарии: вход, чужая заметка, неправильный токен, изображение и API. Это помогает связать состав зависимостей с реальным договором приложения, а не только с успешной установкой.

Сведения выпуска

Рядом с артефактом полезно хранить версию Python, разрешённый состав, дату проверки и ссылку на внутренний результат. Сам runtime не должен предоставлять внешнему посетителю административный отчёт зависимостей по свободному маршруту.

Срок проверки также имеет значение. Новое сообщение может появиться после публикации прежнего отчёта. Сопровождение должно пересматривать сведения, но эта серия не создаёт автоматический мониторинг или расписание.

Библиотека и системный слой

Изображение может обрабатываться кодом пакета и компонентами, включёнными в его сборку. Перечень Python-имён не всегда описывает все системные версии. Поэтому область отчёта pip-audit должна оставаться известной.

Также важно происхождение зависимости. Пакет с похожим именем или неожиданная локальная подстановка не становится доверенным после успешного импорта. Перед добавлением новой библиотеки проверяются её назначение, источник и поддерживаемый способ установки.

Автоматическое исправление версии требует повторной оценки. Оно может изменить API, параметры или доступные форматы. Если учебный PNG начал отклоняться, нужно исследовать конкретное изменение, а не возвращать прежнюю проблемную версию ради одного удобного результата.

Снимок окружения связывается с идентификатором выпуска. Дата отчёта и дата артефакта могут различаться; храните обе. Проверка одного окружения не подтверждает, что на другом сервере установлены те же зависимости.

Наконец, отсутствие сети при проверке может означать невозможность получить свежие сведения. Такой результат сохраняется как неполная проверка с причиной, а не превращается в «известных проблем нет».

Теперь зависимости представлены как управляемая часть выпуска с честной областью проверки. Следующий урок соединит настройки приложения с внешним HTTPS и доверенным прокси, где ошибки окружения могут изменить смысл уже настроенной cookie.