Федеральная служба по техническому и экспортному контролю утвердила поправки к порядку сертификации средств защиты информации. Приказ №9 от 20 января 2026 года уже зарегистрирован в Минюсте. Документ вносит изменения в действующее положение 2018 года и заметно смещает акценты.
Если раньше главным было, как средство защиты информации выполняет свои функции, то теперь регулятор требует заглянуть под капот.
Разработчики средств защиты информации теперь обязаны раскрывать, из каких именно компонентов собран их продукт. Речь идёт не только о собственном коде, но и о любых заимствованных элементах. В первую очередь это касается программных компонентов с открытым исходным кодом.
Если в продукте используется open source, придётся составить и приложить к заявке на сертификацию полный перечень таких компонентов. То же самое касается образов контейнеров. Оба перечня стали полноценными документами сертификации.
Но просто перечислить библиотеки недостаточно. Испытательная лаборатория теперь обязана оценить не только правильность работы функций безопасности, но и сам состав продукта. Лаборатория проверит, насколько полно заявитель описал все заимствованные компоненты, а главное — правильно ли он оценил риск кибератак на них, и их отношение к элементам, которые реализуют или помогают реализовывать функции безопасности.
Кроме того, в формуляр или паспорт средства защиты информации теперь нужно вносить контрольные суммы исполняемых файлов. Это делается для того, чтобы чётко фиксировать, какой именно образец прошёл испытания, чтобы любые последующие изменения было невозможно скрыть.
Самая чувствительная новация касается изменений в составе open source. Если разработчик вносит правки в перечень заимствованных компонентов с открытым исходным кодом, он обязан в течение пяти календарных дней сообщить об этом в ФСТЭК и представить скорректированный перечень. Пять дней — это очень короткий срок. На практике это означает, что процессы управления зависимостями и контроля версий должны быть выстроены практически в реальном времени. Автоматическая генерация обновлённого перечня при каждом изменении в репозитории становится не роскошью, а необходимостью.
За нарушение этого требования предусмотрены наказания. В перечень оснований для аннулирования сертификата добавили пункт о непредставлении сведений об изменениях в перечне open source компонентов. Иными словами, не успел уведомить — можешь лишиться сертификата.
Документ уточняет и другие этапы сертификации. Например, программа и методика испытаний теперь должна включать план проверки заимствованных компонентов. Сроки согласования этой программы с органом по сертификации формализованы жёстче: орган рассматривает документы в течение десяти календарных дней, а общий цикл с учётом возможных доработок не должен превышать тридцати дней.
Также изменились требования к формату подачи материалов. Часть документов, включая технические условия, задание по безопасности и формуляр, нужно подавать и на бумаге, и в электронном виде. А вот протоколы испытаний, перечни open source и контейнеров — только в электронном виде. Важно, что электронные копии должны быть идентичны подписанным бумажным оригиналам.
Необходимо вести и поддерживать в актуальном состоянии перечень всех заимствованных open source компонентов, входящих в продукт. Аналогичный перечень требуется для образов контейнеров. Оба перечня становятся неотъемлемой частью сертификационного досье. Сквозная видимость запасов. Почему цифры сходятся, а товара на полке нет Евгения Шенкао: «Купить технологию — не проблема. Проблема — начать с ней жить» Администрацию Трампа обязали вернуть 166 миллиардов долларов
При любом изменении в составе open source разработчик обязан в пятидневный срок уведомить ФСТЭК и передать обновлённый перечень. Промедление или сокрытие изменений грозит аннулированием сертификата.
В формуляр продукта нужно вшить контрольные суммы исполняемых файлов, чтобы однозначно идентифицировать испытанный образец.
Компании должны быть готовы к тому, что испытательная лаборатория будет анализировать не только функции безопасности, но и корректность классификации каждого компонента с точки зрения атак хакеров, а также участия в реализации защиты. Это требует более глубокой документации и, вероятно, дополнительных разъяснений.
Наконец, нужно соблюдать гибридный порядок сдачи документов, и заполнять бумажные экземпляры плюс электронные копии, причём с полным соответствием подписей и реквизитов.
Самое прямое последствие — аннулирование сертификата соответствия. В перечень оснований для аннулирования добавлено непредставление сведений о внесении изменений в перечень заимствованных программных компонентов с открытым исходным кодом. Если компания поменяла open source в продукте и не уведомила ФСТЭК в течение пяти дней, сертификат могут отозвать. Причём неважно, ухудшилась безопасность или нет — сам факт неуведомления становится достаточным поводом. Читайте также 
ИИ находит баги быстрее, чем их успевают исправить Искусственный интеллект научился находить уязвимости в программном обеспечении с такой скоростью, что небольшие команды разработчиков просто не успевают реагировать на все выявленные проблемы. И это при том, что на рынок ещё официально не вышла одна из самых мощных моделей — Anthropic Mythos.
Ещё одно последствие вытекает из требований к испытательной лаборатории. Если лаборатория найдёт недостатки в перечнях open source или контейнеров, она направит заявителю предложения по доработке. Это приведёт к затягиванию сертификации, дополнительным согласованиям и дополнительным расходам. В худшем случае сертификат может быть не выдан вовсе, если компания не сможет доказать полноту и корректность своих перечней.
Контрольные суммы в формуляре означают, что любое несоответствие между испытанным образцом и продуктом, который реально поставляется заказчику, будет обнаружено при проверках. Если компания не ведёт строгий учёт изменений и не обновляет контрольные суммы, она рискует получить предписание или лишиться сертификата по результатам контрольных мероприятий.
Наконец, неисполнение правил ведёт к репутационным и рыночным потерям. Заказчики из госсектора и сферы КИИ просто не смогут покупать несертифицированные средства защиты информации. Компания, потерявшая сертификат из‑за нарушения сроков уведомления или неполноты перечней, выпадает из этого рынка как минимум на время переоформления. А переоформление с учётом новых требований может занять месяцы.
Для многих разработчиков эти требования станут серьезной проблемой. Особенно для тех, кто привык активно использовать open source, не особо задумываясь об учёте каждой библиотеки. Теперь придётся наводить порядок в управлении зависимостями и внедрять инструменты для автоматического формирования перечней. Затраты на документацию и сопровождение сертификации вырастут. Впрочем, те, кто уже строил процессы с оглядкой на международные практики SBOM, окажутся в выигрыше.
Заказчикам же стоит быть готовыми к тому, что вывод новых сертифицированных продуктов на рынок может замедлиться. Не все вендоры смогут быстро перестроиться. Кроме того, само понятие сертифицированного ПО станет более неопределенным, так как любое неучтённое изменение в программном обеспечении может привести к отзыву сертификата, даже если сам продукт продолжает исправно защищать информацию.
В целом ФСТЭК последовательно двигается к модели, где безопасность определяется не только тем, что умеет система, но и тем, как она устроена внутри. Прозрачность состава и управляемость изменений становятся такими же обязательными атрибутами, как и сертификационные испытания. Видимо, российским IT-компаниям, работающим в области защиты информации, вскоре придется привыкать к новой реальности.
С цифровой копией документа можно ознакомиться здесь.
Источник: www.it-world.ru