Всё о получении статуса доверенного ПО: этапы, требования, сроки и наши услуги.
Материал давал точный и практически полезный разбор допустимости иностранного кода в составе доверенного ПО — с чётким разграничением зависимостей, вендорированного кода и форков, а также конкретными инструментами аудита компонентного состава. Портили его только вымышленный опыт, статистика и контакты. Оставляем практически весь технический и юридический анализ.
Главное: постановление №1937 требует принадлежности исключительных прав на продукт в целом российскому лицу — это требование не распространяется на каждую строку кода. Использование иностранных библиотек и фреймворков как внешних зависимостей — стандартная и допустимая практика: она не создаёт препятствий для доверенного статуса при отсутствии критических уязвимостей и корректном документировании. Проблема возникает не из-за факта использования иностранного кода, а из-за характера его использования: когда иностранный компонент становится функциональным ядром продукта или встраивается в дистрибутив с нарушением лицензии.
| Утверждение из старой версии статьи | Реальное положение дел |
|---|---|
| «10 лет опыт работы с реестровыми процедурами Минцифры»; статистика «95% наших клиентов проходят экспертизу с первого раза» | Доверенный статус существует с марта 2026 года, многолетнего опыта и статистики по нему быть не может |
Принципиальное разграничение: права и зависимости
| Тип иностранного кода | Правовая природа | Допустимость | Условия |
|---|---|---|---|
| Внешние зависимости: сторонние библиотеки, фреймворки | Используются по лицензии, права не принадлежат правообладателю продукта | Допустимо | Отсутствие критических CVE, совместимость лицензий, документирование |
| Код, включённый непосредственно в продукт (vendor) | Часть дистрибутива, права на него принадлежат исходному автору | Требует анализа | Лицензионная чистота, отсутствие CVE, корректное документирование |
| Иностранный open source как основа продукта (форк) | Производная работа, ядро принадлежит иностранным авторам | Ограниченно допустимо | Объём собственной разработки должен быть существенным |
| Переупакованный иностранный продукт без существенных изменений | Фактически чужой продукт — права не принадлежат российской компании | Недопустимо | Требование о правах не выполняется |
| Код, написанный иностранными разработчиками на заказ с передачей прав | Права переданы российскому правообладателю по договору | Допустимо | Корректно оформленный договор с отчуждением прав |
Внешние зависимости: что допустимо и что проверяется
Использование иностранных библиотек в качестве зависимостей — стандартная и допустимая практика. Практически каждый современный продукт зависит от десятков или сотен сторонних компонентов, центр тестирования при экспертизе не требует замены всех иностранных зависимостей на российские. Но зависимости проверяются по двум критериям. Отсутствие известных уязвимостей: центр сверяет полный перечень зависимостей с базой CVE. Компоненты с открытыми уязвимостями критического или высокого уровня становятся замечанием при экспертизе независимо от того, российская библиотека или иностранная. Уязвимость есть уязвимость, и регулярное обновление зависимостей до актуальных версий остаётся необходимой практикой подготовки. Документирование состава: для экспертизы нужен полный перечень всех зависимостей с версиями и лицензиями, включая транзитивные. Центр не принимает неполный список и запрашивает дополнение, что добавляет недели к сроку, поэтому инвентаризация всего компонентного стека — обязательная задача при подготовке.
Что точно является проблемой
Ряд ситуаций с иностранным кодом создаёт реальные препятствия либо при регистрации заявления, либо при экспертизе. Их лучше выявить на этапе предварительного аудита, а не в ходе официальной проверки. Иностранные компоненты как функциональное ядро продукта создают отдельный класс проблем. Когда продукт является надстройкой над иностранным движком, без которого не работает основная функциональность, права на ядро принадлежат иностранным авторам, а российская компания фактически выступает интегратором, а не правообладателем — это системная юридическая, а не техническая проблема.
Зависимости с критическими CVE без плана устранения: устаревшие библиотеки с известными уязвимостями высокого уровня опасности, которые не обновлялись годами. Центр тестирования выявляет их при проверке компонентного стека, и обновление обязательно, хотя нередко тянет за собой цепочку несовместимостей в остальном коде. Встроенные иностранные облачные сервисы: обращения продукта в процессе работы к иностранным облачным API (картографическим сервисам, сервисам распознавания, платёжным системам) как к неотъемлемым функциональным компонентам. Это одновременно вопрос информационной безопасности, поскольку данные уходят за рубеж, и вопрос архитектурной зависимости от иностранной инфраструктуры. Иностранные компоненты без лицензионного анализа тоже создают риск. GPL-компонент, включённый непосредственно в дистрибутив закрытого продукта, — потенциальное нарушение лицензии, а компонент с лицензией, запрещающей коммерческое использование, требует отдельной проверки. Центр тестирования проверяет лицензии зависимостей, и лицензионные конфликты становятся самостоятельной категорией замечаний.
Иностранные разработчики в команде: влияет ли это на статус
Национальность разработчиков сама по себе не является критерием для доверенного статуса. Требование постановления относится к правообладателю продукта и его корпоративной структуре, а не к гражданству сотрудников. Иностранный разработчик, работающий в российской компании по трудовому договору с условием о служебных произведениях, создаёт результаты интеллектуальной деятельности, которые принадлежат российскому работодателю. Практический нюанс: трудовой договор должен содержать явное условие о служебных произведениях, а если разработчик работает удалённо из-за рубежа, применимое право договора и его исполнение требуют дополнительного анализа. Сам факт иностранного гражданства сотрудника проблемы для доверенного статуса не создаёт.
Как провести аудит компонентного состава
Аудит компонентного состава — обязательный этап подготовки к экспертизе. Его цель — выявить проблемные зависимости до того, как их обнаружит центр тестирования. Инвентаризация полного стека зависимостей: сбор полного списка прямых и транзитивных зависимостей с помощью инструментов автоматизации вроде npm audit, pip-audit, Gradle dependency report или Maven dependency:tree. Результат — полный список с именами, версиями и лицензиями каждого компонента. Проверка на CVE: сверка каждого компонента с базой уязвимостей инструментами вроде OWASP Dependency Check, Snyk, GitHub Dependabot или Trivy, с выявлением всех компонентов уровня High и Critical и оценкой сложности обновления для каждого. Лицензионный анализ: проверка совместимости лицензий всех зависимостей между собой и с лицензией продукта, с особым вниманием к GPL-компонентам в закрытом продукте, компонентам с ограничениями на коммерческое использование и лицензиям, требующим раскрытия исходного кода. Анализ вендорированного кода: выявление иностранного кода, включённого непосредственно в дистрибутив (скопированных файлов, встроенных библиотек), с оценкой лицензии, наличия CVE и необходимости замены на внешнюю зависимость или собственную реализацию для каждого случая.
Вопросы и ответы
Короткие ответы на вопросы, которые чаще всего возникают при подготовке документов и подаче заявки.
Продукт использует React, PostgreSQL, Nginx — всё иностранное. Это проблема?
Нет, если это внешние зависимости, используемые по их открытым лицензиям без критических уязвимостей в применяемых версиях. React (лицензия MIT), PostgreSQL (PostgreSQL License), Nginx (лицензия BSD) — разрешительные лицензии без ограничений на коммерческое использование. Использование таких компонентов стандартно и не препятствует доверенному статусу; важно поддерживать актуальные версии и иметь полный документированный список зависимостей для передачи в центр тестирования.
В продукте есть компонент на GPL, а сам продукт коммерческий с закрытым кодом — это проблема?
Потенциально да, в зависимости от характера использования. GPL требует, чтобы производные работы и продукты, включающие GPL-код, распространялись под той же лицензией с открытым кодом. Если GPL-компонент включён непосредственно в дистрибутив закрытого коммерческого продукта, это лицензионный конфликт; если он используется как отдельный процесс через чётко разграниченный интерфейс, ситуация иная. Конкретный ответ зависит от архитектуры использования и требует юридического анализа — центр тестирования проверяет лицензионную чистоту, и конфликты становятся замечаниями.
Разработчики используют иностранные AI-инструменты вроде Copilot или ChatGPT — как это влияет на права?
Это актуальный вопрос без окончательно устоявшейся практики. Ключевые риски: неопределённость авторства сгенерированного кода, потенциальные претензии со стороны правообладателей обучающих данных, условия использования конкретных инструментов. GitHub Copilot, например, допускает коммерческое применение выходных данных по своим условиям использования, но вопрос авторства и принадлежности прав остаётся дискуссионным. Для продукта, претендующего на доверенный статус, разумно либо минимизировать использование таких инструментов для ключевых компонентов, либо иметь чёткую политику их применения с юридическим анализом.
Иностранная библиотека больше не поддерживается и имеет CVE — обязательно ли её заменять?
Зависит от уровня уязвимости. Критические и высокие CVE в неподдерживаемых библиотеках становятся замечанием при экспертизе без исключений — центр тестирования не принимает аргумент «библиотека не обновляется, поэтому патча нет». Варианты решения: замена на актуальный поддерживаемый аналог, собственный патч уязвимости с соблюдением лицензии, замена собственной реализацией. Откладывать это решение до начала официальной экспертизы означает практически гарантировать замечание и дополнительный цикл проверки. Если самостоятельная инвентаризация компонентного стека кажется трудоёмкой, разумно начать с консультации по конкретному стеку технологий — это быстрее выявляет реальный объём работы, чем попытка угадать результат экспертизы заранее.
Источники
- КонсультантПлюс, порядок формирования перечня доверенного ПО: требование принадлежности исключительных прав по постановлению №1937.
- Реестр российского программного обеспечения, Минцифры России: требования к документированию компонентного состава продукта.
