13 сентября 2022 г.
В течение последних месяцев восприятие импортозамещения в умах руководителей всех уровней качественно изменилось. До начала СВО нормативные акты, посвященные импортозамещению, воспринимались скорее как досадная инициатива правительства, которая отнимает время на совершенно лишние действия. Столкнувшись после начала СВО с уходом западных вендоров, невозможностью купить или продлить лицензии, а в ряде случаев — с прекращением работы оплаченных продуктов из-за блокировки, все ответственные лица быстро осознали, что происходящее требует незамедлительных мер, настоящего импортозамещения. Причем по-хорошему, переход с зарубежных на отечественные решения нужно было выполнить еще вчера.
Блокировки разработчиков
С проблемами импортозамещения столкнулись не только пользователи зарубежных решений, но и разработчики отечественных программных продуктов. И первой проблемой стали блокировки. В начале марта 2022 скандинавская компания Qt Group заблокировала загрузку своих коммерческих решений для российских программистов и полностью убрала с сайта русский язык.
Основной продукт компании — open source фреймворк Qt, который упрощает создание и поддержку технически сложных программных проектов под разные операционные системы. В составе Qt есть инструменты для создания интерфейсов. С их помощью, например, реализован мультимедийный интерфейс управления автомобилями в Яндекс.Авто. Qt Group не позволяет скачивать свои платные продукты в России, но бесплатные пока доступны.
Буквально через месяц, в апреле, Github заблокировал десятки аккаунтов российских компаний, среди которых были ВТБ, Сбертех, Positive Technologies, некоторые проекты «Альфа-Банка», платежного сервиса YooMoney.
За аккаунтом разработчика на GitHub, как правило, закреплен приватный репозиторий с кодом, представляющим собой фрагменты проектов, над которыми работают группы программистов. Приватный репозиторий позволяет удобно организовать совместную работу с кодом. В случае блокировки аккаунта теряется доступ к приватному репозиторию и ко всем данным, хранящимся в нем. Если при этом у разработчика не окажется свежей резервной копии, придется восстанавливать все вручную, то есть писать заново.
Политический активизм
Второй проблемой для отечественных разработчиков стал вредоносный политический активизм некоторых зарубежных программистов. Наиболее яркий пример такого поведения — инцидент с разработчиком npm-пакета node-ipc, который 8 марта 2022 года опубликовал обновленную версию с добавленным вредоносным кодом. Новая версия удаляла все данные и перезаписывала файлы на компьютерах разработчиков из России и Беларуси, а вместо оригинальных файлов создавала текстовые документы с призывами к миру.
Действия создателя node-ipc открыли ящик Пандоры и моментально обнулили доверие к готовым программным пакетам, размещенным в публичных репозиториях. Практика автоматического обновления программных продуктов и библиотек через интернет в текущих условиях становится неприемлемой с точки зрения рисков. Никто не может гарантировать, что увлеченный политической повесткой сотрудник компании или программист не решит внезапно проявить свою гражданскую позицию и попытаться нарушить работу компьютерных систем «страны-агрессора».
Атаки через цепочку поставок
Опасность атаки через библиотеки исходного кода наглядно продемонстрировал исследователь Алекс Бирсан. Он воспользовался особенностями работы популярных пакетных менеджеров и разместил в публичных репозиториях программные библиотеки, имена которых совпадали с приватными библиотеками, входившими в состав проектов известных компаний. В результате он сумел взломать внутренние системы более 35 крупных компаний, среди которых были Microsoft, Apple, PayPal, Shopify, Netflix, Yelp, Tesla и Uber.
Напуганные рисками использования сторонних библиотек кода, некоторые руководители попытались дать указание срочно скачать все что нужно для работы проектов. Но быстро стало понятно, что таким образом проблема не решается, поскольку создатели библиотек регулярно исправляют обнаруженные ошибки и уязвимости. Использование же заблаговременно скачанных старых версий приводит к тому, что ошибки попадут в готовое приложение и сделают его уязвимым для взлома.
Безопасные способы работы с зависимостями
Универсальным решением проблемы со страхом использования открытых библиотек кода и ненавистью некоторых представителей сообщества программистов будет отключение системы сборки от интернета. Но это создаст другую проблему в виде невозможности устанавливать внешние зависимости. Решить ее можно путем создания собственного хранилища кода, содержащего все необходимые пакеты.
В этом случае придется самостоятельно поддерживать сторонний код, выполнять слияния новых версий библиотек с локальными, проводить аудит безопасности кода и всей цепочки его зависимостей.
Такое решение помимо увеличения трудозатрат приведет к большому расходу дискового пространства. В качестве выигрыша можно получить полный контроль над версиями и безопасностью внешних зависимостей проекта.
Более щадящим решением может стать возможность создания прокси-репозитория, который будет по запросу системы сборки загружать пакеты зависимого кода из удаленного репозитория или использовать кэшированные библиотеки нужных версий.
Этот избавляет от хранения всего дерева зависимого кода на локальных дисках, но проблемы остаются, поскольку зависимости по-прежнему получаются через интернет, и значит, мы частично теряем контроль над кодом, который включается в проект. Кроме того, в этом случае утрачивается полный контроль над цепочкой поставки, поскольку нет возможности следить за рекурсивными зависимостями.
Возможно также объединение описанных подходов в виде создания локального хранилища, которое позволит зафиксировать безопасные версии пакетов и установить запрет обновления до последних версий из удалённых хранилищ или репозиториев.
Заключение
Импортозамещение программного кода — значительно более сложный процесс, чем импортозамещение готовых приложений, оборудования и сервисов. В реестре отечественного ПО Минкомсвязи нет библиотек из репозитория pypi или npm, но это не значит, что они не используются в готовых приложениях, входящих в этот реестр. При этом контроль над кодом этих библиотек находится в руках их разработчиков, которые, как показывают недавние события, могут использовать его не только в благих целях, но и для создания атмосферы страха и ненависти среди коллег из «неправильных» регионов.
Код многих современных приложений содержит до 90% заимствованного кода, созданного сообществом. По состоянию на текущий момент отечественные разработчики решают проблему безопасности такого кода собственными силами с разной степенью эффективности. Однако проблемы, которые потенциально может создать уязвимая или вредоносная библиотека, например, в составе приложения на объекте КИИ, требуют принятия более глобальных решений на государственном уровне.
В конце апреля замглавы Минцифры Максим Паршин пообещал, что в России до конца 2022 года должен появиться российский репозиторий проектов Open Source, который заменит GitHub. Однако, как сообщили «Ведомости» 9 августа, «Старт эксперимента по созданию государственного репозитория свободного ПО перенесен Министерством цифрового развития на неопределенный срок. Его запуск был предварительно запланирован на 1 мая 2022 г., но проект постановления правительства так и не был принят из-за сложностей с нормативным обеспечением».
Таким образом, отечественные разработчики по-прежнему вынуждены самостоятельно придумывать способы импортозамещения библиотек. Итогом вполне может стать создание российского аналога GitHub силами альянса разработчиков, вне государственных проектов.
Источник: Сергей Черномашенцев, исполнительный директор Smart-Soft
