Когда разработчик впервые слышит про требования к включению в реестр российского ПО, чаще всего он ожидает увидеть понятный чек-лист: соответствуешь — проходишь, не соответствуешь — не проходишь. На практике всё устроено сложнее и, в каком-то смысле, тоньше. Речь идёт не просто о наборе формальных критериев, а о том, как государство определяет, можно ли считать конкретный продукт частью российской цифровой инфраструктуры или нет.
Именно поэтому требования к программному обеспечению — это не только про код или функциональность. Это одновременно про происхождение продукта, контроль над ним, архитектуру, инфраструктуру и даже про то, как вы сами его описываете.
Критерии анализа программного обеспечения
В основе лежит довольно понятная логика: программное обеспечение должно находиться под контролем российского правообладателя и не зависеть критически от иностранных элементов, которые могут ограничить его использование (этот вопрос мы с вами разобрали в предыдущей статье). Но если углубиться, становится видно, что проверка идёт сразу по нескольким направлениям.
Первое — это вопрос происхождения и контроля. Важно не просто то, где был написан код, а кто имеет над ним фактический контроль, где хранится исходный код, в какой юрисдикции находятся ключевые элементы инфраструктуры. Для государства это вопрос управляемости и безопасности: продукт должен быть доступен, поддерживаем и не зависеть от внешних ограничений.
Второе направление — это состав и структура самого программного обеспечения. Практически любой современный продукт использует сторонние библиотеки, фреймворки и компоненты. И это нормально. Но для реестра важно, чтобы эти компоненты не создавали критической зависимости, которая делает продукт «неуправляемым» в российских условиях. Иногда это очевидно, иногда — нет, и именно здесь возникает необходимость корректно описать состав продукта и используемые технологии.
Третья важная часть требований — это соответствие функциональности выбранному классу программного обеспечения. Реестр устроен так, что каждое ПО относится к определённой категории. И это не просто формальность для статистики. Это способ классифицировать рынок и понимать, какие решения существуют в каждой категории. Если описание продукта не совпадает с выбранным классом, для экспертизы это сигнал, что либо классификация выбрана неправильно, либо описание не отражает реальную функциональность.
И вот здесь появляется одна из самых частых проблем. Разработчик смотрит на свой продукт через призму бизнеса и маркетинга, а реестр смотрит через призму формального классификатора. И эти две картины нужно аккуратно совместить.
Куда проверяющий особенно смотрит?
Отдельное внимание уделяется архитектуре и способам распространения программного обеспечения. Экспертиза анализирует, как продукт разворачивается, где обрабатываются данные, как осуществляется доступ пользователей, какие используются каналы обновления. Это не глубокий аудит безопасности, но проверка на базовое соответствие требованиям российского ПО.
И, наконец, есть ещё один слой требований, о котором редко думают заранее, — это требования к формулировкам и согласованности информации. В реестре важно не только то, соответствует ли продукт критериям, но и то, как это отражено в заявке. Описание функциональности, сведения о разработке, данные о хранении кода — всё это должно складываться в непротиворечивую картину. Любая несостыковка вызывает вопросы, замедляет процесс и повышает шанс отказа.
В результате получается интересная ситуация. Формально требования понятны и публичны. Но на практике прохождение этих требований — это не просто проверка факта, а правильная подготовка и представление продукта в нужной логике.
Именно поэтому компании, которые подходят к включению в реестр системно, начинают не с заполнения формы, а с анализа своего продукта: соответствует ли он требованиям, какие формулировки нужно использовать, какие моменты нужно дополнительно обосновать или скорректировать.
А как этот процесс выглядит на практике, как всё это собирается в единую заявку и проходит экспертизу — мы подробно разберём в следующей статье.