Основные ошибки при получении доверенного статуса ПО

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

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

Ошибки на этапе подготовки

Большинство проблем при экспертизе закладываются задолго до подачи заявления — в период, когда компания только оценивает ситуацию или откладывает начало работ, а эти ошибки самые дорогие именно потому, что к моменту их обнаружения времени на исправление остаётся мало. Слишком поздний старт остаётся самой распространённой и критичной ошибкой: процедура занимает четыре-шесть месяцев при готовом продукте, и это без учёта технической доработки, которая нередко добавляет ещё два-четыре месяца, поэтому компании, начинающие работу за три месяца до дедлайна, физически не успевают. Пропуск предварительного аудита означает подачу заявления без проверки юридической позиции по правам и технической готовности продукта, и проблемы тогда обнаруживаются уже в центре тестирования, где их исправление стоит в разы дороже, чем на этапе внутреннего аудита. Неверное определение категории ПО по классификатору Минцифры влечёт ошибку в определении дедлайна: продукт, классифицированный как «серверное ПО» вместо «связующее ПО», может оказаться в другой группе с другими требованиями при экспертизе. Пограничные случаи вроде SIEM/мониторинг или ERP/отраслевое ПО требуют отдельного анализа. Устаревшая реестровая запись, отражающая версию продукта многолетней давности, тоже становится проблемой. Центр тестирования проверяет актуальный продукт, а документы описывают другой, и расхождение требует остановки, актуализации записи и возобновления процедуры.

Ошибки при работе с документами

Ошибки при технической подготовке продукта

Технические ошибки самые дорогостоящие по последствиям: они обнаруживаются в центре тестирования и требуют доработки продукта с последующей повторной экспертизой, а каждый такой цикл добавляет один-два месяца к сроку и значительные расходы к бюджету. Частый случай — команда тестировала продукт на Windows и Ubuntu, но не на Astra Linux или РЕД ОС, хотя специфика этих дистрибутивов (иные версии компонентов, политики безопасности, особенности инициализации служб) нередко создаёт проблемы, которых нет в стандартных Linux-средах вроде Ubuntu. Устаревшие зависимости с известными CVE тоже частый источник замечаний: библиотеки без обновлений год и более центр сверяет со своей базой и выявляет уязвимости, которые компания просто не отслеживала, а обновление зависимостей кажется простым, но нередко влечёт цепочку несовместимостей.

Несанкционированная сетевая активность (телеметрия разработчику, обращения к внешним серверам без действия пользователя, иностранные облачные сервисы как неотъемлемые компоненты) фиксируется центром тестирования при анализе сетевого поведения продукта, и каждое недокументированное внешнее соединение вызывает вопросы. Инсталлятор, требующий ручного редактирования конфигурации или недокументированных шагов на доверенной ОС, тоже фиксируется как замечание, поскольку центр устанавливает продукт штатным способом по документации. Отдельная ошибка: считать совместимость обеспеченной через Wine или другую эмуляцию Windows-среды. Постановление требует нативной работы, и продукт, запускающийся только через эмулятор, формально несовместим с доверенными ОС. Наконец, для продуктов с криптографическими функциями (шифрование, электронная подпись, защищённые каналы) применение российских ГОСТ-алгоритмов — требование, а не рекомендация: реализация только на иностранных алгоритмах вроде AES или RSA проверку не проходит.

Ошибки при работе с юридическими требованиями

Юридические ошибки нередко выявляются позже всего — на этапе детального анализа при подготовке к подаче, когда времени на исправление остаётся меньше всего. Путаница между правами на компанию и правами на ПО — распространённый случай: компания полностью российская, но права на продукт оформлены некорректно, потому что он создавался подрядчиком без договора об отчуждении или иностранными сотрудниками без надлежащих трудовых договоров. Права на компанию и права на конкретный продукт — разные юридические объекты, и исторические подрядчики без договоров остаются самым частым источником проблем. Решение здесь одно: дополнительные соглашения об отчуждении прав. Нераскрытый корпоративный договор с нестандартными правами создаёт ещё один риск. Иностранный миноритарный акционер с долей 20% может иметь право вето на стратегические решения по такому договору, что фактически означает контроль несмотря на формальное меньшинство, и скрытие такого договора при последующем выявлении создаёт серьёзный риск. Неправильный расчёт правила 30% для госкомпаний тоже частая ошибка: компания включает в расчёт только прямых «дочек», не учитывая «сестринские» структуры холдинга и организации, связанные через общих руководителей. Группа лиц по 135-ФЗ шире, чем очевидные аффилированные, и занижение числителя в расчёте выявляется при проверке.

Ошибки при работе с центром тестирования

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

Распространённые заблуждения и реальность

«Мы уже в реестре российского ПО, это почти то же самое» — на деле реестр лишь предварительное условие, доверенный статус отдельная сложная процедура. «У нас Linux-продукт, совместимость с доверенными ОС не проблема» — не все Linux-дистрибутивы одинаковы, Astra Linux SE имеет специфику, которая создаёт проблемы даже для нативных Linux-продуктов. «Наш конкурент пока тоже без статуса, не срочно» — первый получивший статус получает конкурентное преимущество во всех последующих тендерах. «Есть сертификат ФСТЭК, блок ИБ закрыт» — сертификат помогает, но не заменяет процедуру: требования пересекаются, но не совпадают. «SaaS-продукты не могут получить доверенный статус» — могут, при условии российской инфраструктуры, это зависит от архитектуры конкретного продукта. «Дедлайн через год, у нас ещё много времени» — год при наличии технических проблем это только период подготовки, без учёта самих официальных этапов.

Как проверить себя перед подачей

Источники

• КонсультантПлюс, порядок формирования перечня доверенного ПО: требования и основания для отказа по постановлению №1937.
• Реестр российского программного обеспечения, Минцифры России: актуализация реестровой записи как условие подачи на доверенный статус.