Как легализовать собственные разработки не ломая всей ИТ-инфраструктуры

Интервью с экспертом по защите информации промышленных предприятий Игорем Владимировичем Краевым о новых правилах игры для самостоятельных разработчиков внутри компаний.

Игорь Владимирович, в конце ноября 2025 года Правительство выпустило целый пакет постановлений — 1931, 1936, 1937. Многие предприятия, которые мы знаем, годами пишут для себя небольшие утилиты, модули мониторинга, интеграционные шины. И теперь, глядя на эти документы, возникает страх: неужели любая самоделка должна стать «доверенным ПО» и проходить экспертизу как промышленный софт?

Давайте сразу расставим точки над i, потому что это самый популярный страх последних лет. Регистрировать можно и нужно малые продукты. Никто не требует от вас строить экосистему уровня «Ростелекома». Постановления ввели три контура, разделив ПО «для всех» (Реестр российского ПО), ПО «для внутреннего потребления» (Перечень собственных нужд, ПП-1936) и «доверенное ПО» (ПП-1931).

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

Давайте уточним. Есть привычный «Единый реестр российского ПО», а теперь появился «Перечень программ для собственных нужд» из ПП-1936. Чем они отличаются для директора по безопасности?

Принципиально отличаются условиями и требованиями регулятора (Минцифры).

Первый путь — Реестр российского ПО (ПП-1236, редакция ПП-1937). Это «витрина» продуктов, которые предлагаются рынку.

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

Второй путь — Перечень программного обеспечения для собственных нужд (ПП-1936). Он создан для тех, кто разрабатывает ПО исключительно для себя.

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

Практический вопрос. Какие типы продуктов вы рекомендуете регистрировать в первую очередь? Многие говорят: «Мы только начали приводить в порядок промышленные сети».

Начните с того, что уже работает и приносит пользу. Вот три направления, где самодельные разработки есть почти у каждого промпредприятия в 2026 году.

1. Средства мониторинга и контроля событий ИБ (СИМ-подобные системы собственной разработки). Приказ ФСТЭК 117 от 11 апреля 2025 г. прямо требует проведения мероприятий по мониторингу информационной безопасности в отношении «всех информационных систем» (п. 49). Если вы не доверяете внешнему вендору или у вас уникальные протоколы АСУ ТП, вы можете разработать упрощенный сборщик логов и коррелятор. Зарегистрировав такой продукт в Перечне собственных нужд, вы закрываете вопрос о легитимности этого ПО с точки зрения импортозамещения.
2. Коннекторы и шлюзы к технологическому оборудованию. У вас есть станки с ЧПУ, ПЛК или полевые шины, которым нужен драйвер для безопасной передачи данных в МЕШ-систему? Это идеальный кандидат. Вы пишете небольшое ПО, соблюдаете регламент безопасной разработки (ГОСТ Р 56939-2024, разделы 4 и 5, как того требует п. 50 Приказа ФСТЭК 117) и включаете его в Перечень собственных нужд.
3. Внутренние инструменты управления уязвимостями и обновлениями. Приказ 117 (п. 38, 39) установил жесткие тайминги: критические уязвимости — 24 часа на закрытие, высокие — 7 дней. Управлять этим в Excel невозможно. Самописный сканер или дашборд, который агрегирует данные из открытых баз ФСТЭК и вашего периметра, может и должен быть зарегистрирован. Это небольшая, но очень важная разработка.

Вы упомянули ГОСТ Р 56939-2024 по безопасной разработке. Для многих ИБ-специалистов в промышленности это «зверь». Можно ли соблюсти этот стандарт малым коллективом?

Можно и нужно. Приказ ФСТЭК 117 ссылается на ГОСТ Р 56939-2024, но его требования масштабируются.
Для включения продукта в Перечень собственных нужд вы подаете:

1. Декларацию о соответствии ПО части 3² статьи 2 Федерального закона (это требования российского происхождения — контроль над правообладателем, выплаты иностранцам и т.д.).
2. Описание функциональных характеристик и архитектуры.
3. Сведения о реализации мероприятий по защите информации в вашей инфраструктуре разработки.

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

Это подводит нас к теме «брать готовое или дорабатывать». Понятно, что ЕРП-систему никто самостоятельно писать не будет. А где граница? Где целесообразно взять готовое и доработать, а не писать с нуля?

Давайте разделим три сегмента.

Нет смысла писать самим: то, что требует глубокой экспертизы в ИБ и уже есть на рынке в «доверенном» исполнении. Это системы антивирусной защиты, межсетевого экранирования, криптошлюзы. ПП-1931 вводит Перечень доверенных российских программ. Если вы покупаете продукт, уже находящийся в этом перечне, это наилучший способ сразу закрыть вопросы совместимости с российскими ОС и требований к отсутствию закладок.

Стоит брать готовое и дорабатывать:

• Крупные промышленные МЕШ/СКАДА-платформы. У них уже должны быть сертификаты совместимости с доверенными ОС. Ваша разработка — это специфические экранные формы, отчеты, модули интеграции. Такую кастомизацию логично зарегистрировать как отдельный продукт (или модуль) в Перечне собственных нужд, если она будет эксплуатироваться именно у вас.
• Платформы IIoT. Покупаете платформу, сертифицированную по 4 уровню доверия для КИИ 1 категории, а специфические сценарии аналитики дописываете сами.

Точно стоит писать самим и регистрировать:

• Все, что касается ваших уникальных технологических процессов. Рецептуры, алгоритмы нечеткого управления, режимные карты. Это ваша коммерческая тайна, которая не должна выходить за пределы предприятия. При этом соблюдайте режим «особенностей»: раз это ПО не продается, вы четко прописываете во внутреннем техническом задании на разработку и в документации, что данное ПО совместимо с одной или двумя вашими доверенными ОС, которые вы уже используете на предприятии (например, Astra Linux и РЕД ОС).

Остается последнее. Когда все-таки придется идти в «доверенное ПО» и проходить полную экспертизу в аттестованном центре тестирования?

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

Если ваша система или самодельный модуль начинает выполнять функции управления производственным процессом, который при нарушении его работы дает последствия федерального масштаба (показатели «Политической» или «Социальной» значимости из ПП-127), или если вы решили выводить ваш софт на рынок, то:

1. Вам нужен аттестованный центр тестирования (перечень ведет Минцифры).
2. Вам нужно будет подтвердить совместимость не менее чем с двумя доверенными ОС (если ПО не для ПАК).
3. Вам понадобится сертификат безопасности в сертифицированной лаборатории ФСТЭК.

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