Включение промышленной продукции в реестр Минпромторга - важная процедура для российских производителей.
Вопрос об иностранном коде в составе продукта, претендующего на доверенный статус, — один из наиболее практически значимых и наименее однозначных. Большинство современных программных продуктов используют сторонние библиотеки, фреймворки и компоненты — многие из которых созданы иностранными разработчиками. Означает ли это автоматическую невозможность получения доверенного статуса? Нет. Но означает ли это, что состав кода вообще не имеет значения? Тоже нет. Граница между допустимым и недопустимым проходит не по национальности авторов компонентов, а по характеру их использования и по тому, кому принадлежат исключительные права на продукт в целом.
Принципиальное разграничение: права и зависимости
Постановление № 1937 устанавливает требование о принадлежности исключительных прав на программное обеспечение российскому юридическому или физическому лицу. Это требование относится к продукту как к целому — а не к каждой строке кода, из которого он состоит. Ключевое разграничение выглядит так.
Тип иностранного кода Правовая природа Допустимость Условия Внешние зависимости — сторонние библиотеки, фреймворки Используются по лицензии, права не принадлежат правообладателю продукта Допустимо Отсутствие критических CVE, совместимость лицензий, документирование Код, включённый непосредственно в продукт (vendor) Часть дистрибутива, права на него принадлежат исходному автору Требует анализа Лицензионная чистота, отсутствие CVE, корректное документирование Иностранный open source как основа продукта (форк) Производная работа, ядро принадлежит иностранным авторам Ограниченно допустимо Объём собственной разработки должен быть существенным Переупакованный иностранный продукт без существенных изменений Фактически чужой продукт — права не принадлежат российской компании Недопустимо Требование о правах не выполняется Код, написанный иностранными разработчиками на заказ с передачей прав Права переданы российскому правообладателю по договору Допустимо Корректно оформленный договор с отчуждением прав
Внешние зависимости: что допустимо и что проверяется
Использование иностранных библиотек в качестве зависимостей — стандартная и допустимая практика. Практически каждый современный программный продукт зависит от десятков или сотен сторонних компонентов. Центр тестирования при экспертизе не требует замены всех иностранных зависимостей на российские. Но зависимости проверяются по двум критериям.
🔐
Критерий 1: отсутствие известных уязвимостей
Центр тестирования сверяет полный перечень зависимостей с CVE-базой. Компоненты с открытыми уязвимостями критического или высокого уровня — замечание при экспертизе. Это требование не зависит от того, российская библиотека или иностранная: уязвимость есть уязвимость. Регулярное обновление зависимостей до актуальных версий — необходимая практика подготовки.
📋
Критерий 2: документирование состава
Для экспертизы требуется полный перечень всех зависимостей с указанием версий и лицензий — включая транзитивные зависимости. Центр тестирования не принимает неполный список: запросит дополнение, что добавит недели к сроку. Инвентаризация всего компонентного стека — обязательная задача при подготовке к экспертизе.
Что точно является проблемой
Ряд ситуаций с иностранным кодом создаёт реальные препятствия — либо при регистрации заявления, либо при экспертизе в центре тестирования. Их лучше выявить на этапе предварительного аудита, а не в ходе официальной проверки.
🔴 Иностранные компоненты как функциональное ядро продукта
Продукт является надстройкой над иностранным движком, без которого не работает основная функциональность. Права на ядро принадлежат иностранным авторам. Российская компания фактически является интегратором, а не правообладателем. Это системная проблема — не техническая, а юридическая.
🔴 Зависимости с критическими CVE без плана устранения
Устаревшие библиотеки с известными уязвимостями высокого уровня опасности, которые не обновлялись годами. Центр тестирования выявляет их при проверке компонентного стека. Обновление обязательно — и нередко тянет за собой цепочку несовместимостей.
🔴 Встроенные иностранные облачные сервисы
Продукт в процессе работы обращается к иностранным облачным API — картографическим сервисам, сервисам распознавания, платёжным системам — как к неотъемлемым функциональным компонентам. Это и вопрос ИБ (данные уходят за рубеж), и вопрос архитектурной зависимости от иностранной инфраструктуры.
🟡 Иностранные компоненты без лицензионного анализа
GPL-компонент, включённый непосредственно в дистрибутив закрытого продукта — потенциальное нарушение лицензии. Компонент с лицензией, запрещающей коммерческое использование. Центр тестирования проверяет лицензии зависимостей. Лицензионные конфликты — самостоятельная категория замечаний.
Иностранные разработчики в команде: влияет ли это на статус
Национальность разработчиков, работающих в компании, сама по себе не является критерием для доверенного статуса. Требование постановления относится к правообладателю продукта и его корпоративной структуре — а не к гражданству сотрудников. Иностранный разработчик, работающий в российской компании по трудовому договору с условием о служебных произведениях, создаёт результаты интеллектуальной деятельности, принадлежащие российскому работодателю.
Практический нюанс: трудовой договор должен содержать явное условие о служебных произведениях, и если разработчик работает удалённо из-за рубежа — применимое право договора и его исполнение требуют дополнительного анализа. Но сам факт иностранного гражданства сотрудника не создаёт проблемы для доверенного статуса.
Как провести аудит компонентного состава
Аудит компонентного состава — обязательный этап подготовки к экспертизе. Его цель: выявить проблемные зависимости до того, как их обнаружит центр тестирования.
1
Инвентаризация полного стека зависимостей
Сбор полного списка всех зависимостей — прямых и транзитивных. Для большинства экосистем существуют инструменты автоматизации: npm audit, pip-audit, Gradle dependency report, Maven dependency:tree. Результат — полный список с именами, версиями и лицензиями каждого компонента.
2
Проверка на CVE
Сверка каждого компонента с CVE-базой. Инструменты: OWASP Dependency Check, Snyk, GitHub Dependabot, Trivy. Выявить все компоненты с уязвимостями уровня High и Critical. Для каждого — наличие обновлённой безопасной версии и оценка сложности обновления.
3
Лицензионный анализ
Проверка лицензий всех зависимостей на совместимость между собой и с лицензией продукта. Особое внимание — GPL-компонентам в закрытом продукте, компонентам с ограничениями на коммерческое использование, компонентам с лицензиями, требующими раскрытия исходного кода.
4
Анализ вендорированного кода
Выявление иностранного кода, включённого непосредственно в дистрибутив — скопированных файлов, встроенных библиотек. Для каждого случая: лицензия, наличие CVE, необходимость замены на внешнюю зависимость или собственную реализацию.
Вопросы об иностранном коде в доверенном ПО
Мы используем React, PostgreSQL, Nginx — всё иностранное. Это проблема?
Нет — если это внешние зависимости, используемые по их открытым лицензиям, без критических уязвимостей в применяемых версиях. React (MIT), PostgreSQL (PostgreSQL License), Nginx (BSD) — разрешительные лицензии без ограничений на коммерческое использование. Использование таких компонентов стандартно и не является препятствием для доверенного статуса. Важно поддерживать актуальные версии и иметь полный документированный список зависимостей для передачи в центр тестирования.
В нашем продукте есть компонент на GPL. Мы коммерческий продукт с закрытым кодом. Это проблема?
Потенциально да — в зависимости от характера использования. GPL требует, чтобы производные работы и продукты, включающие GPL-код, распространялись под той же лицензией с открытым кодом. Если GPL-компонент включён непосредственно в дистрибутив закрытого коммерческого продукта — это лицензионный конфликт. Если он используется как отдельный процесс через чётко разграниченный интерфейс — ситуация другая. Конкретный ответ зависит от архитектуры использования и требует юридического анализа. Центр тестирования проверяет лицензионную чистоту — лицензионные конфликты становятся замечаниями.
Разработчики пишут код на иностранных AI-инструментах — Copilot, ChatGPT. Как это влияет на права?
Это актуальный вопрос без окончательно устоявшейся практики. Ключевые риски: неопределённость авторства сгенерированного кода, потенциальные претензии со стороны правообладателей обучающих данных, условия использования конкретных AI-инструментов. GitHub Copilot, например, имеет условия использования, допускающие коммерческое применение выходных данных, но вопрос авторства и принадлежности прав остаётся дискуссионным. Для продукта, претендующего на доверенный статус, рекомендуется либо минимизировать использование таких инструментов для ключевых компонентов, либо иметь чёткую политику их использования с юридическим анализом.
Иностранная библиотека больше не поддерживается и имеет CVE. Обязательно ли её заменять?
Зависит от уровня CVE. Критические и высокие уязвимости в неподдерживаемых библиотеках — замечание при экспертизе без исключений. Центр тестирования не принимает аргумент «библиотека не обновляется, поэтому патча нет». Варианты решения: замена на актуальный аналог с поддержкой, собственный патч уязвимости с соблюдением лицензии, замена собственной реализацией. Откладывать это решение до начала официальной экспертизы — значит гарантировать замечание и дополнительный цикл проверки.
Иностранный код — управляемый риск, не принципиальное препятствие
Реестр Гарант проводит аудит компонентного состава как часть подготовки к экспертизе. Выявляем проблемные зависимости, анализируем лицензионную чистоту, составляем план устранения до подачи заявления. Проблемы, найденные на внутреннем аудите, решаются в рабочем порядке. Те же проблемы, найденные центром тестирования — это замечания, повторная экспертиза и дополнительные расходы.
✓ иностранные зависимости допустимы при отсутствии CVE CVE проверка всех зависимостей — обязательный этап подготовки 95% наших клиентов проходят экспертизу с первого раза 10 лет опыт работы с реестровыми процедурами Минцифры
Проверить компонентный состав продукта перед экспертизой
Расскажите о стеке технологий — проведём аудит зависимостей, выявим проблемные компоненты и составим план их устранения до начала официальной процедуры.
Телефон / WhatsApp / Telegram: +7 920-898-17-18
Email: reestrgarant@mail.ru
Первичная консультация бесплатная в рабочее время.
Оригинальная статья
Полная версия статьи на нашем сайте: https://vnesenie-v-reestr.ru/news/mozhno-li-ispol-zovat-inostrannyy-kod-v-doverennom-po-trebovaniya-k-sostavu-produkta
Мы занимаемся включением в реестр Минпромторга
📞 Телефон: +7 920-898-17-18
✉️ Email: reestrgarant@mail.ru