Как мы регистрировали HConfig в реестре российского ПО

—

от автора

Привет, Хабр! На связи снова Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн». 

В прошлой статье я рассказывал об HConfig — нашем консольном инструменте. Он задумывался как внутренняя утилита для решения проблемы воспроизводимости конфигураций, когда нам надоело настраивать Linux-серверы по памяти. 

Но одно дело — делиться утилитой как продуктом с коллегами-интеграторами, и совсем другое — внедрять ее у госзаказчиков и на объектах критической информационной инфраструктуры (КИИ), которые в силу своей специфики тщательно изучают устанавливаемые продукты. Так мы пришли к идее внести наш продукт в реестр российского ПО.

Соответственно, в этой статье я расскажу, как мы отстаивали независимость стека HConfig и на какие грабли наступили, прежде чем получить заветный реестровый номер 32983. Спойлер: с первого раза не получилось. Со второго тоже (см. рис. 1)

Ожидания и суровая реальность

Изначально мы видели в реестре только выгоду для компании: добиться отмены НДС, снизить страховые взносы, получить доступ к тендерам и грантам. И сама процедура казалась нам классическим бюрократическим квестом — заплати юристам, собери «макулатуру», получи номер, участвуй в закупках — и будет тебе счастье. Реальность, как водится, нас отрезвила. 

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

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

Рис. 1. Наш путь в Минцифру

Рис. 1. Наш путь в Минцифру

Первая попытка

Итак, 24 октября 2025 года мы подали первую заявку. 

К заявке на регистрацию мы приложили краткое техническое задание, архив с исходным кодом и свидетельства Роспатента. Ну, а что еще надо-то? Инструмент уже давно стал продуктом, работает в продакшенах, исходный код в наличии, свидетельство Роспатента имеется. Мало что ли? Оказалось, да, мало — и мы получили отказ. 

Причины оказались для нас неожиданными:

  1. Домен с документацией HConfig был зарегистрирован на физлицо (разработчика), а не на компанию. 

  2. Слишком кратко описали бесплатное распространение.

  3. Отсутствовал акт ввода в эксплуатацию (да-да, в министерстве требуют бумагу. Ну и что, что софт давно в продакшене — этого мало).

  4. Краткое техническое задание не устроило экспертов.

Вторая попытка

Окей, все поняли, все исправили, переоформили домен на юрлицо, выкатили вторую версию заявки. Снова отказ. В этот раз причиной отказа оказались особенности нашего свидетельства из Роспатента. 

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

А вот Минцифра увидела там потенциальную проблему: у HConfig было два правообладателя — компания и разработчик. На момент регистрации в Роспатенте все выглядело логично — человек писал код приложения, а компания предоставляла ресурсы. И, конечно, перед подачей документов в Минцифру мы читали их стандартную методичку — в ней описан общий случай. Однако наш случай с двумя правообладателями (один из которых физлицо) предусматривал расширенный пакет документов. Мы же этого не учли и закономерно получили отказ. 

Ладно, тут прояснилось. Но какие еще нас ждут открытия? Где узнавать? 

Решили, что терять нам нечего — проверим систему на прочность. Отправили запрос на разъяснение причин отказа через обычную форму в подвале сайта Минцифры.

4. Живая поддержка

Поскольку это все же министерство (читай: госучреждение), мы ожидали бюрократическую отписку. Но в этот раз шаблон сломался. 

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

Сотрудник поддержки детально разложил по полочкам, какие именно сведения и подробности отсутствуют в нашем пакете документов:

1.  Пакет документов на двух правообладателей. Нам были нужны договор и приказ о совместной разработке, а также нотариальная доверенность от второго правообладателя (разработчика) на подачу заявки.

2.  Информационное письмо о подтверждении отсутствия выплат в пользу иностранных лиц. Минцифру не устроил формально заполненный бланк с прочерками в соответствующих полях (ну а что там писать-то? У нас же выплат иностранным поставщикам не было). Потребовалось подготовить официальное информационное письмо в PDF-ке с математическими расчетами, плюс подпись каждого правообладателя.

3.  Бухгалтерия. Пришлось оформлять приказы и акты о создании программного обеспечения и карточки учета нематериальных активов (НМА).

4.  Формат файлов. Все документы должны быть строго в PDF, в виде сканов с живыми подписями и печатями. Никаких выгрузок из 1С в Word или Excel и никаких архивов (ZIP, RAR) (рис. 2).

Рис. 2. Как формировать пакет документов для регистрации в реестре

Рис. 2. Как формировать пакет документов для регистрации в реестре

5. Технический аудит 

Параллельно со сборкой юридического пакета шел и технический  аудит. Написать код — полдела. Вторая половина — доказать экспертам, что этот код действительно твой, а не одолженный. 

  • Стек и независимость. Один из ключевых критериев — отсутствие в ПО скрытых механизмов удаленного управления. То есть софт гарантированно не должен однажды превратиться в «тыкву» или «кирпич» из-за отозванной лицензии или заблокированного сервера. Пришлось детально обосновывать использование Python, конкретных модулей и описывать работу с репозиториями РЕД ОС. Открытием стали строгие ограничения стека — потребовалось переписывать куски кода, которые опирались на запрещенные в России библиотеки.

  • Не прослойка над иностранным ядром. По этому критерию нужно было доказать, что HConfig — самостоятельный инструмент, а не скрипт-прослойка над условным Ansible, Terraform или тому подобным иностранным ПО. Если пытаешься такую прослойку выдать за российский продукт — тебе откажут. Нативная поддержка РЕД ОС8 пошла в жирный плюс для регистрации.

  • Air-gapped контур и SSL.  Один из важнейших критериев — работа в изолированном контуре. Их эксперты так и спрашивали: что будет без интернета? Мы показали fallback-режимы и продемонстрировали, что инструмент не «умрет» без интернета: SSL-сертификат либо поставляется заказчику целиком (ключ + цепочка + сертификат), либо выписывается через Let’s Encrypt при наличии доступа в сеть. Нет никакой скрытой телеметрии или «кнопок отключения».  

  • Отсутствие вендор-лока. По этому параметру проработали опцию депонирования кода (эскроу). Здесь, как я уже писал выше, Минцифра подстраховывается, чтобы вендор не исчезал вместе с кодом — для объектов КИИ и крупных госзаказчиков это важно. Мы подтвердили, что исходный код хранится на нашем сайте и сервере и доступен заказчикам. 

  • Руководство для экспертов. Разработчики часто считают, что хорошему коду не нужны простыни документации, а в крайнем случае всегда спасет README.md. Но тут вам не GitHub. Эксперт Минцифры затребовал пошаговое руководство, чтобы он с нуля смог развернуть присланный экземпляр программы на тестовом стенде (с жесткой привязкой к РЕД ОС 8, чтобы эксперт не пытался запускать проверки на случайном Ubuntu). Пришлось написать настоящий «талмуд» с описанием архитектуры и пошаговым мануалом по деплою. 

Отмечу, что на подготовку всех документов по этим юридическим и техническим трекам ушел не один десяток человеко-часов. Каждый файл документации, каждую схему и каждый акт приходилось конвертировать, загружать в отдельное поле веб-формы на портале и вручную прописывать его название. Объем проделанной работы, пожалуй, оказался сопоставим с написанием небольшой внутренней системы — только тут вместо кода мы готовили что-то вроде летописи-хронологии приведения нашего продукта в соответствие с регуляторными требованиями.

6. Результаты регистрации

Наконец, после трех попыток, звонков в поддержку, тонн PDF-сканов и нескольких месяцев томительного ожидания мы получили заветное письмо — HConfig официально занял свое место в единой базе российского ПО с номером реестровой записи 32983 (рис. 3).

Рис. 3. HConfig официально занял свое место в единой базе российского ПО с номером реестровой записи 32983

Рис. 3. HConfig официально занял свое место в единой базе российского ПО с номером реестровой записи 32983

Что же мы получили на практике, помимо галочки в коммерческом предложении? Стоила ли игра свеч? Судите сами (рис. 4). 

Рис. 4. Что нам дала запись в реестре

Рис. 4. Что нам дала запись в реестре

1. Радары госзаказчиков. Продукт автоматически попадает в базу, которую ежедневно мониторят госсектор и фонды вроде ФРИТ в поиске решений для импортозамещения. 

2. Закрытый комплаенс для КИИ. Для безопасников госкомпаний реестр — это обязательный комплаенс-барьер. То есть, внедряя продукт из реестра (в нашем случае HConfig), они получают гарантию «неотключаемости» продукта.

3. Доступ к грантам. Из разработчика «внутренней утилиты» мы превратились в верифицированного вендора с доступом к грантам, безвозвратному финансированию и субсидиям на продвижение, о которых раньше могли только читать в новостях.

4. Снижение налоговой нагрузки. После регистрации в реестре российского ПО мы получили право на нулевую ставку НДС. (Отмечу, что автоматически ее применить не получится, там отдельная история). 

7. Дорожная карта

Наверное, будет справедливо сказать, что опыт регистрации в реестре измеряется количеством отказов. При правильном подходе весь цикл занимает от 60 до 90 дней. Чтобы вы не теряли месяцы и не повторяли наших ошибок, предложу вам дорогу из «желтого кирпича» в Изумрудный город Минцифру (рис. 5).

Рис. 5 Дорога из «желтого кирпича»

Рис. 5 Дорога из «желтого кирпича»
  • Оформляйте домены только на юрлицо. Забудьте про личные аккаунты CTO или гендиректора. Если WHOIS показывает физлицо, получите автоматический отказ на старте. Заведите отдельный реестр доменов, которые зарегистрированы строго на организацию, и никогда не используйте личные аккаунты для публичных страниц продукта.

  • Не загружайте архивы и Word-файлы. Всё только в PDF, причем каждый PDF отдельно. Все приказы, акты и бухгалтерские справки — строго сканами с живыми печатями и подписями.

  • Подготовьте информационное письмо о подтверждении отсутствия выплат в пользу иностранных лиц, компаний за подписью генерального директора. Даже если у вас нет выплат за рубеж, бланк с прочерками в соответствующих полях, т. е. пустая отписка, не пройдет. Нужен официальный PDF с математическими расчетами. А если правообладателей несколько — подпись каждого из них.

  • Звоните в поддержку! Один созвон с живым экспертом Минцифры заменит вам недели чтения противоречивых (увы!) инструкций и сэкономит десятки часов работы.

Упомяну также более специфичные, но вряд ли уникальные задачи, которые нам тоже пришлось решать: 

  • проверьте структуру собственности, 

  • оформите права на код, 

  • задокументируйте стек, 

  • подготовьте бухгалтерские документы (поставьте ПО на баланс как НМА). 

Только после этого нажимайте кнопку «Отправить». Большинство отказов связаны не с принципиальным несоответствием продукта критериям, а с недостаточной подготовкой заявки.

ссылка на оригинал статьи https://habr.com/ru/articles/1091234/