Минцифры отложило маркировку российского ПО, потому что 90% открытого кода это норма, а не диагноз

Минцифры отложило разработку проекта об обязательной маркировке российского ПО из реестра при создании продукта на основе доработанного открытого кода. Ведомство считает инициативу преждевременной из-за сложности универсального определения минимальной доли заимствованного open source-кода. Дополнительный риск состоит в том, что подобная маркировка способна поднять порог входа для молодых вендоров, увеличить расходы на проверки и в итоге привести к росту цен на внедрение ПО.

О переносе разработки сообщил «Коммерсантъ» со ссылкой на Минцифры. Идея появилась после поручений премьер-министра Михаила Мишустина по итогам ЦИПР-2025, хотя подобные предложения обсуждались и раньше. Смысл инициативы был в выделении продуктов из реестра отечественного ПО с использованием доработанного открытого кода для демонстрации уровня самостоятельности разработки.

В Минцифры пояснили затруднительность определения минимальной доли открытого кода в составе продукта. Разные классы ПО устроены по-разному, и open source-компонент бывает разным:

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

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

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

Интересно, что в зрелых коммерческих продуктах 10% кода могут быть критическим ядром, а 70% относиться к стандартной обвязке, и формальная маркировка по проценту просто проигнорирует подобный нюанс.

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

Директор департамента реализации инфраструктурных проектов «Софтлайн Решения» ГК Softline Виталий Попов отметил, что у молодых вендоров доля открытого кода в продуктах может доходить до 90%. По мнению Виталия Попова, формальный подход к маркировке поставит под вопрос подобные решения даже при наличии уникальной функциональности. Для стартапов и небольших команд это особенно болезненно, поскольку open source часто позволяет быстрее вывести продукт на рынок и снизить стоимость разработки.

Директор по стратегическим проектам «ЛАНИТ-Терком» ГК ЛАНИТ Кирилл Чурилин смотрит на идею маркировки с другой стороны. По мнению Кирилла Чурилина, подобная процедура помогла бы очистить рынок от формально отечественных решений без должного уровня защиты и функциональности. Для заказчиков это значимая тема. Иногда под видом российского продукта продаётся почти неизменённая сборка открытого решения с минимальными доработками и слабой поддержкой.

Исполнительный директор «Кросс технолоджис» Станислав Дарчинов предупредил о возможных последствиях маркировки. По оценке Станислава Дарчинова, новая процедура повысит стоимость внедрения open source-решений и приведёт к дополнительным проверкам с ограничениями для отдельных категорий организаций. Сегодня бизнес часто выбирает самописные продукты на основе открытого кода именно ради экономии.

У инициативы вырисовываются 2 стороны. Заказчики действительно хотят прозрачности и понимания, покупают ли они полноценную отечественную разработку с поддержкой и ответственностью или красивую упаковку вокруг чужого проекта. Грубая маркировка по проценту заимствованного кода может наказать сильные команды с грамотным использованием open source.

Отдельный пласт связан с состоянием самих открытых проектов. Картина в open source-экосистеме выглядит тревожно:

• до 70% открытых проектов либо не поддерживаются вовсе;
• значительная часть проектов в неудовлетворительном состоянии;
• уязвимым может оказаться до 95% кода с подобными компонентами;
• многие зависимости не получают регулярных обновлений;
• риски в цепочке поставок остаются плохо контролируемыми.

Отмечается, что 70% открытых проектов в мире практически заброшены сопровождающими, и под угрозой оказывается до 95% использующего их кода.

Для корпоративных заказчиков открытое происхождение компонентов требует управления рисками, проверки зависимостей, мониторинга уязвимостей и понятного процесса обновлений. В конце 2024 года сообщалось о планах Минцифры ввести требования по защите для существующих репозиториев открытого кода. Тогда речь шла не о создании единого государственного хранилища, а о регулировании уже действующих площадок.

Глава Центра компетенций по импортозамещению в сфере ИКТ Илья Массух говорил журналистам «Коммерсанта» об отказе Минцифры от идеи единого репозитория открытого кода. Готовилась концепция отечественных репозиториев с прописанными общими требованиями к таким хранилищам. Подобный подход выглядит более реалистичным, поскольку разработчики уже используют разные площадки, а попытка собрать всё в одном месте столкнулась бы с техническими, организационными и рыночными ограничениями.

Государство явно ищет баланс между контролем и жизнью реальной разработки. Полностью игнорировать open source невозможно, поскольку современное ПО почти всегда опирается на открытые компоненты. Оставлять рынок без правил тоже рискованно, особенно при попадании подобных решений в чувствительные зоны:

• госсектор и государственные сервисы
• объекты критической инфраструктуры
• финансовый сектор и банковские системы
• промышленные предприятия и энергетика
• здравоохранение и социальные сервисы

Вендорам пауза даёт время подготовиться. Даже при отложенной маркировке вопрос происхождения кода никуда не денется. Компаниям предстоит лучше вести учёт зависимостей, фиксировать доработки, проверять лицензии, устранять уязвимости, документировать сопровождение и доказывать заказчикам несводимость продукта к простой копии открытого проекта.

Заказчикам стоит смотреть глубже стандартного ярлыка «отечественное ПО». В зрелой закупке вопрос звучит не «есть ли там open source», а «о том, насколько управляемо и безопасно он используется». Сюда входят сопровождение продукта, скорость закрытия уязвимостей, наличие гарантийной поддержки, состав компонентов и соблюдение лицензий.

Редакция CISOCLUB убеждена, что решение Минцифры отложить маркировку выглядит разумной паузой перед слишком грубым регулированием. Open source сам по себе не является ни проблемой, ни гарантией качества. По мнению редакции, риск появляется там, где открытые компоненты используются без контроля зависимостей, обновлений, лицензий и ответственности.

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