Как проверить безопасность Python-скрипта перед запуском

Скачали скрипт из интернета, нашли на GitHub полезный инструмент, получили от коллеги файл «посмотри, пригодится» — и вот он лежит на рабочем столе. Запускать хочется, но переживается. И это правильная реакция. Запуск незнакомого .py-файла без проверки — это лотерея, в которой призом может стать майнер, кейлоггер или шифровальщик. Разберёмся, как реально оценить безопасность скрипта, не будучи специалистом по кибербезопасности.

Почему Python-скрипты — это не безобидный текст

Многие думают: «Это же просто текстовый файл, что он может сделать?» На практике — почти всё что угодно. Python даёт прямой доступ к файловой системе, сети, переменным окружения, процессам ОС. Одна строчка os.system('rm -rf /') способна уничтожить систему, а модуль subprocess позволяет выполнять любые команды от имени текущего пользователя.

Вот минимальный набор того, чего реально стоит опасаться:

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

Шаг 1. Прочитайте исходный код (хотя бы бегло)

Первый и самый очевидный шаг, который часто пропускают. Откройте файл в любом редакторе — даже в Блокноте — и пролистайте. Вам не нужно понимать каждую строчку, достаточно увидеть подозрительные паттерны.

На что смотреть в первую очередь:

• импорт модулей — особенно os, subprocess, ctypes, socket, requests, http.client, eval, compile, exec; если они используются — скрипт потенциально может делать что-то опасное;
• Адреса URL — ищите строки с http:// или https:// и IP-адресами напрямую; если скрипт куда-то что-то отправляет, определите куда;
• и другие кодировки — обилие строки вида aGVsbG8gV29ybGQ= или вызовов base64.b64decode — красный флаг; так часто прячут вредоносные нагрузки;
• eval() и exec() — выполняют произвольный код; если видите их, значит, скрипт что-то вычисляет динамически, и нужно понимать — что именно;
• обращение к файлам вне рабочей директории — пути вида /etc/passwd, /home/, C:\Users\, ~/.ssh/ — признак того, что скрипт лезет туда, куда не должен.

Если файл состоит из пары тысяч строк и вы не можете его прочитать — это уже сигнал. Нормальный скрипт для решения конкретной задачи редко бывает длиннее 300–500 строк.

Шаг 2. Проверьте зависимости

У большинства скриптов есть зависимости, и именно через них часто приходит проблема. Файл requirements.txt или pyproject.toml — ваш первый объект для проверки.

1. Откройте список зависимостей и проверьте названия пакетов. Опечатки в названиях — распространённый способ атаки (typosquatting). Например, requesrs вместо requests, numpi вместо numpy. Злоумышленники регистрируют пакеты с похожими названиями, и кто-то по невнимательности ставит не тот.
2. Поищите пакеты на PyPI — зайдите на pypi.org, найдите каждый пакет и посмотрите: сколько у него загрузок, когда обновлялся, кто автор. Свежий пакет с тремя загрузками и неизвестным автором — подозрителен.
3. Проверьте адрес репозитория, если он указан. Ссылается ли он на реальный GitHub-проект с историей и участниками? Или на подозрительную страницу?

Если проект использует pip install с флагом --extra-index-url или ссылается на сторонний индекс пакетов — это повышенный риск. Стандартный PyPI хотя бы проходит базовую модерацию.

Шаг 3. Изолируйте окружение запуска

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

Три уровня изоляции, от простого к надёжному:

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

Если хотите максимум — запускайте в Docker-контейнере с минимальным образом (python:3.x-slim), без привилегий, без монтирования системных директорий:

docker run --rm -it --network=none \
  --read-only --tmpfs /tmp \
  -v $(pwd):/app \
  python:3.11-slim python /app/script.py

Флаг --network=none отрезает сетевой доступ, --read-only не даёт менять файлы внутри контейнера, -v $(pwd):/app — только текущая папка. Такой скрипт физически не сможет отправить данные или повредить систему.

Шаг 4. Запустите и понаблюдайте

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

Что проверять во время работы:

• Сетевые соединения — откройте монитор ресурсов (Windows), lsof -i (macOS/Linux) или ss -tunap и посмотрите, не появились ли неожиданные исходящие соединения. Если ваш «полезный скрипт» устанавливает соединение с IP в незнакомом регионе — это проблема.
• Файловая активность — создались ли новые файлы? Изменились ли существующие? Используйте утилиты вроде opensnoop (macOS) или procmon (Windows) для отслеживания файловых операций в реальном времени.
• Нагрузка на CPU/GPU — высокая загрузка без видимых причин может указывать на скрытый майнинг.

Шаг 5. Проверьте автоматические изменения

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

Что проверять после запуска:

• crontab — выполните crontab -l и убедитесь, что там нет незнакомых записей;
• Планировщик задач Windows — откройте Task Scheduler и проверьте новые задачи;
• Автозагрузка — ~/.bashrc, ~/.zshrc, ~/.profile на macOS/Linux; папка автозагрузки или ключ реестра HKCU\Software\Microsoft\Windows\CurrentVersion\Run на Windows;
• Новые сервисы — systemctl list-units --type=service на Linux.

Если вы нашли что-то неожиданное — скрипт остался в системе, и его нужно не просто удалить, а зачистить все следы.

Частые ошибки при проверке скриптов

«Я просто запущу, посмотрю, что будет.» — это самый опасный подход. Многие вредоносные скрипты делают вид, что работают нормально, а фоном выполняют свои задачи. Вы можете не заметить.

«На GitHub — значит безопасно.» — нет, это не так. Даже популярные репозитории взламывают (были случаи с event-stream, ua-parser-js). Популярность ≠ безопасность.

«Скрипт небольшой, там нечего прятать.» — трех строк достаточно:

import os, codecs
os.system(codecs.decode(b'b' ... , 'hex'))

Кодирование, обфускация, base64 — всё это позволяет спрятать суть даже в крошечном файле.

«Я поставил антивирус, он ничего не нашёл — значит чисто.» — антивирусы плохо работают с Python-скриптами, потому что интерпретатор Python (python.exe / python3) — это легитимная программа. Антивирус видит, что python.exe что-то делает, но не знает, что именно делает скрипт. Это слепая зона.

«Запущу с правами администратора, чтобы точно всё сработало.» — никогда так не делайте с незнакомым кодом. Всегда запускайте с минимальными правами.

Ещё одна частая ошибка — игнорирование git-истории. Если вы скачали скрипт из репозитория, посмотрите коммиты: был ли добавлен подозрительный код недавно? Кто его добавил? Были ли конфликты слияния? Иногда именно в diff видно внедрение вредоносного кода.

Инструменты, которые реально помогают

Проверкой написано много статей, в которых перечисляют десятки инструментов. На практике для Python-скриптов полезны единицы. Вот те, что действительно стоит использовать:

• bandit — статический анализатор для Python; находит небезопасные конструкции: eval(), os.system(), захардкоженные пароли; запускается одной командой: bandit script.py; бесплатный, с открытым исходным кодом, есть на PyPI;
• pip-audit — проверяет установленные зависимости на известные уязвимости; pip-audit -r requirements.txt; простой и конкретный;
• pyright / mypy — не про безопасность напрямую, но показывают проблемы в коде; если инструмент находит десятки ошибок, код писали небрежно, а значит и про безопасность там не думали;
• Gitleaks — ищет захардкоженные секреты (токены, пароли, ключи API) в истории репозитория; полезен если клонируете чужой проект.

Что делать в зависимости от вашей ситуации

Ситуация 1: скрипт для себя, скачан с известного GitHub-автора.

Откройте код, проверьте зависимости, запустите в виртуальном окружении. Посмотрите сетевые соединения минут пять. Если всё чисто — пользуйтесь, но не запускайте от имени администратора.

Ситуация 2: скрипт от коллеги или из чата.

Проверьте хотя бы названия импортов и зависимостей. Запустите в изолированном окружении (venv или Docker). Не запускайте с флагом sudo и не давайте права на запись за пределы рабочей папки.

Ситуация 3: нашли скрипт на форуме, в блоге, в Telegram-канале.

Полный цикл проверки: чтение кода, bandit, pip-audit, запуск в Docker без сети. Если не можете прочитать код и нет возможности проверить — лучше не запускать. Это не паранойя, это здравый смысл.

Ситуация 4: нужно автоматически проверять много скриптов (CI/CD, команда).

Настройте пайплайн: bandit + pip-audit + gitleaks на каждый коммит. Используйте принцип наименьших привилегий для среды выполнения. Храните зависимости в lock-файле с хеш-суммами (pip-compile или pip freeze --local).

Итог: минимальный чек-лист на каждый день

1. Открыли код. Смотрим импорты, URL-адреса, обращения к файлам. Если есть eval, exec, base64 — разбираемся, зачем и можно ли без этого обойтись.
2. Проверили зависимости. Нет ли опечаток в названиях? Сколько загрузок? Когда обновлялся автор?
3. Запускаем только в изолированном окружении. Минимум — venv, лучше — Docker, идеально — Docker без сети и без прав на запись в хост-систему.
4. После запуска смотрим сетевые соединения и автозагрузку. Если скрипт добавил себя в crontab — всё плохо, начинаем зачистку.

Безопасность — это не одноразовая проверка, а привычка. Десять минут осмотра до запуска экономят часы восстановления после инцидента. Если скрипт пришёл от неизвестного источника и вы не можете его полноценно проверить — не запускайте. Это самое надёжное правило.