С сентября 2026 года уязвимость устройства становится проблемой производителя

Европейский Cyber Resilience Act меняет правила разработки электроники: теперь недостаточно выпустить работающее устройство — необходимо знать, из чего состоит его программное обеспечение, отслеживать уязвимости, выпускать обновления и быть готовым сообщить об атаке в течение 24 часов

Представим обычную для производителя электроники ситуацию. В пятницу вечером на корпоративную почту приходит письмо от независимого исследователя:

«В веб-интерфейсе вашего промышленного контроллера обнаружена уязвимость. Через специально сформированный запрос можно выполнить команду с правами администратора. Эксплуатация подтверждена на устройствах с прошивками 2.4–2.8».

Письмо пересылают разработчику прошивки. Тот отвечает, что проблема, скорее всего, находится в сторонней библиотеке. Руководитель проекта предлагает разобраться в понедельник. Отдел продаж просит не поднимать шум: контроллер уже установлен у нескольких крупных заказчиков.

Затем выясняется, что описание атаки появилось на форуме. Кто-то опубликовал демонстрационный код. В журналах одного из заказчиков обнаруживаются подозрительные подключения. Еще недавно производитель мог рассматривать такую ситуацию преимущественно как техническую и репутационную проблему:

• проверить сообщение;
• найти ошибку;
• подготовить новую прошивку;
• отправить обновление клиентам;
• постараться не допустить публичного скандала.

С 11 сентября 2026 года для продукции, представленной на рынке Европейского союза, этого может быть недостаточно.

Если имеются надежные свидетельства, что уязвимость действительно используется злоумышленниками, у производителя начинает идти регуляторный отсчет. В течение 24 часов необходимо направить раннее предупреждение, в течение 72 часов — основное уведомление с первоначальной оценкой, а после подготовки корректирующей меры — итоговый отчет.

Таким образом, уязвимость перестает быть внутренним делом программиста или сервисного отдела. Она становится юридически значимым событием, к которому должны быть готовы разработчики, производитель, служба поддержки, руководство и партнеры по цепочке поставок.

---

Важное уточнение: 11 сентября 2026 года начинает действовать не весь CRA

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

Европейский Cyber Resilience Act, или CRA, — Регламент ЕС 2024/2847 о горизонтальных требованиях к кибербезопасности продукции с цифровыми элементами — вступил в силу 10 декабря 2024 года.

При этом требования вводятся поэтапно:

• с 11 сентября 2026 года начинают действовать обязанности по уведомлению об активно эксплуатируемых уязвимостях и серьезных инцидентах безопасности;
• с 11 декабря 2027 года начинают применяться основные требования CRA к проектированию, разработке, производству, оценке соответствия, технической документации и сопровождению продукции.

Следовательно, с сентября 2026 года производитель не обязан сообщать регулятору о каждом найденном программном дефекте.

Обязательному уведомлению подлежат прежде всего две категории событий:

1. Активно эксплуатируемая уязвимость — уязвимость, в отношении которой имеются надежные доказательства использования злоумышленником без разрешения владельца системы.
2. Серьезный инцидент, оказывающий влияние на безопасность продукта, в том числе на доступность, подлинность, целостность или конфиденциальность данных и функций.

Это принципиальное различие.

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

Именно это для многих компаний окажется сложнее, чем сама отправка уведомления.

---

Что такое Cyber Resilience Act

Cyber Resilience Act — попытка Европейского союза изменить сам подход к безопасности цифровой продукции.

Раньше кибербезопасность нередко воспринималась как дополнительная функция:

• есть бюджет — добавим защищенную загрузку;
• есть требование заказчика — реализуем шифрование;
• обнаружили ошибку — выпустим обновление;
• не обнаружили — будем считать, что устройство безопасно.

CRA исходит из другой логики:

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

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

Это означает, что объектом оценки может стать не только печатная плата.

Современный электронный продукт часто представляет собой целую систему:

$\text{аппаратная часть} + \text{прошивка} + \text{загрузчик} + \text{мобильное приложение} + \text{облачный сервис} + \text{механизм обновления}.$

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

---

Какие устройства могут попасть под действие CRA

На практике CRA способен затронуть широкий круг продукции:

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

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

Подключение к интернету не является единственным критерием

Распространенная ошибка — считать, что CRA касается только IoT-устройств, имеющих прямой доступ в интернет.

Формулировка регламента шире.

Устройство может не иметь Ethernet, Wi-Fi или сотового модема, но при этом обмениваться данными через:

• USB;
• Bluetooth;
• CAN;
• RS-485;
• Modbus;
• карту памяти;
• сервисный порт;
• подключенный компьютер;
• промышленную сеть;
• внешний шлюз.

Такое устройство также может иметь цифровые элементы и участвовать в обработке данных.

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

---

Кто считается производителем

CRA использует функциональное, а не только заводское понимание производителя.

Производителем признается физическое или юридическое лицо, которое разрабатывает или изготавливает продукт, заказывает его разработку либо производство и выводит его на рынок под своим именем или товарным знаком. Это возможно как за плату, так и бесплатно или посредством другой модели монетизации.

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

Рассмотрим пример.

Компания заказывает в Китае готовый сетевой шлюз, меняет корпус, устанавливает собственную прошивку и продает изделие под своей торговой маркой.

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

То же относится к моделям:

• OEM;
• ODM;
• white label;
• контрактной разработке;
• выпуску продукции под торговой маркой заказчика.

Фраза «мы только заказали эту плату» не является полноценной стратегией управления ответственностью.

---

Почему CRA касается производителей за пределами Европейского союза

Ключевым фактором является не место регистрации разработчика, а предоставление продукции на рынке ЕС.

Российская, китайская, американская или индийская компания может столкнуться с требованиями CRA, если ее продукция:

• продается непосредственно пользователям в Европейском союзе;
• поставляется европейскому дистрибьютору;
• входит в состав оборудования европейского производителя;
• реализуется под собственной торговой маркой через импортера;
• распространяется как коммерческий программный продукт на рынке ЕС.

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

Поэтому CRA будет воздействовать на производителей за пределами ЕС не только через государственный контроль, но и через договоры с европейскими партнерами.

Импортеры и дистрибьюторы начнут запрашивать:

• описание архитектуры безопасности;
• сведения о периоде поддержки;
• порядок получения обновлений;
• контакты для сообщений об уязвимостях;
• перечень программных компонентов;
• доказательства испытаний;
• процедуру реагирования на инциденты;
• обязательства по выпуску исправлений;
• распределение ответственности между сторонами.

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

---

Три даты, которые должен знать производитель

10 декабря 2024 года

Cyber Resilience Act вступил в силу.

Это не означает, что с этой даты вся продаваемая техника обязана соответствовать полному набору требований. Был установлен переходный период.

11 сентября 2026 года

Начинают применяться обязанности по уведомлению:

• об активно эксплуатируемых уязвимостях;
• о серьезных инцидентах, влияющих на безопасность продукта.

Важно, что эти обязанности распространяются и на продукты с цифровыми элементами, уже предоставленные на рынке ЕС до начала применения основных положений CRA.

Иными словами, нельзя исходить из логики:

«Наше устройство выпущено в 2024 году, поэтому нас это не касается».

Если продукт продолжает использоваться, а производитель узнает об активной эксплуатации его уязвимости после начала действия правил отчетности, ситуация может попасть под требования CRA.

11 декабря 2027 года

Начинают применяться основные требования регламента, включая:

• безопасность при проектировании и разработке;
• анализ киберрисков;
• управление уязвимостями;
• техническую документацию;
• оценку соответствия;
• декларирование соответствия;
• маркировку CE;
• сопровождение продукта;
• предоставление пользователю информации о безопасной эксплуатации.

---

Что именно придется сообщать с 11 сентября 2026 года

1. Активно эксплуатируемые уязвимости

Сам факт наличия уязвимости еще не означает, что она активно эксплуатируется.

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

Такими признаками могут быть:

• подтвержденные журналы несанкционированного доступа;
• образец вредоносного программного обеспечения;
• опубликованный и реально используемый эксплойт;
• данные от заказчиков;
• сообщения исследователей;
• информация национального центра реагирования;
• сведения от поставщика уязвимого компонента;
• результаты расследования инцидента.

Но производитель не может оценить эти признаки, если у него отсутствуют:

• контакты для приема сообщений;
• журналирование событий;
• команда реагирования;
• перечень используемых компонентов;
• сведения о версиях прошивки;
• возможность идентифицировать затронутые партии.

2. Серьезные инциденты безопасности

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

• доступность функций;
• подлинность данных или участников обмена;
• целостность данных и программного обеспечения;
• конфиденциальность информации.

Например:

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

---

Как будет выглядеть процедура уведомления

Европейская комиссия и ENISA предусматривают трехэтапную схему.

Первый этап — раннее предупреждение

Срок:

$T_1 \leq 24\ \text{часов}$

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

• что произошло;
• какой продукт затронут;
• имеются ли признаки злоумышленной эксплуатации;
• может ли событие иметь трансграничные последствия;
• требуется ли срочное взаимодействие.

Второй этап — основное уведомление

Срок:
$T_2 \leq 72\ \text{часов}$ с момента осведомленности производителя. Основное уведомление должно содержать более полную информацию и первоначальную оценку события:

• характер уязвимости или инцидента;
• затронутые продукты и версии;
• предполагаемую степень воздействия;
• известные способы эксплуатации;
• предпринятые временные меры;
• доступные способы снижения риска;
• состояние расследования.

Третий этап — итоговый отчет

Для активно эксплуатируемой уязвимости итоговый отчет подается не позднее 14 дней после того, как корректирующая или компенсирующая мера становится доступной. Для серьезного инцидента итоговый отчет предоставляется в течение месяца после основного уведомления.

Куда направляется информация

Уведомления должны передаваться через единую платформу CRA Single Reporting Platform, создаваемую и обслуживаемую ENISA. Она станет единой точкой подачи: производителю не потребуется отдельно направлять одинаковые материалы множеству национальных органов. Уведомление поступит соответствующей группе реагирования на компьютерные инциденты — CSIRT — и ENISA, после чего информация может быть распространена между компетентными органами государств, где продукт представлен на рынке. Платформа должна быть готова к 11 сентября 2026 года.

---

Почему срок 24 часа меняет всю компанию

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

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

Если компания начинает искать ответы только после получения сообщения, 24 часа превращаются в критически короткий срок. Представим структуру электронного изделия:
$P = H + F + B + L_1 + L_2 + C + A,$

где:

• (H) — аппаратная часть;
• (F) — основная прошивка;
• (B) — загрузчик;
• ($L_1$) и ($L_2$) — сторонние библиотеки;
• (C) — облачный сервис;
• (A) — пользовательское приложение.

В одной из библиотек обнаруживается активно эксплуатируемая уязвимость.

Производителю необходимо быстро определить:

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

Без заранее сформированного реестра компонентов ответить на это за несколько часов почти невозможно.

---

Главная перемена: безопасность становится свойством изделия

В классическом проекте требования часто формулируются так:

• напряжение питания — 24 В;
• число дискретных входов — 16;
• интерфейс — Ethernet;
• рабочая температура — от −40 до +70 °C;
• срок службы — 10 лет.

Кибербезопасность при этом может быть описана одной строкой:

«Предусмотреть пароль для доступа к настройкам».

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

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

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

«Сначала разведем силовую плату, а потом подумаем об изоляционных расстояниях».

---

Почему обновление прошивки становится обязательной частью архитектуры

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

1. Отозвать устройства.
2. Отправить специалиста к каждому объекту.
3. Оставить уязвимость неисправленной.

Поэтому механизм обновления должен проектироваться одновременно с аппаратной платформой.

Безопасное обновление требует целой системы

Недостаточно дать пользователю возможность записать новый бинарный файл.

Необходимо обеспечить:

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

Упрощенная цепочка доверия выглядит так:
$\text{Корневой ключ} \rightarrow \text{загрузчик} \rightarrow \text{проверенная прошивка} \rightarrow \text{проверенная конфигурация}.$

Если хотя бы один элемент цепочки можно незаметно заменить, доверие к системе разрушается.

Обновление тоже может быть источником атаки

Плохо спроектированный сервер обновлений иногда опаснее отсутствия обновлений.

Если злоумышленник получает доступ к ключу подписи или инфраструктуре распространения, он может доставить вредоносную прошивку сразу множеству устройств.

Поэтому производителю необходимо защищать:

• ключи подписи;
• систему сборки;
• сервер обновлений;
• учетные записи разработчиков;
• процедуру выпуска релиза;
• каналы передачи;
• резервные копии;
• журналы действий.

Безопасность продукта начинается не на устройстве. Она начинается в инфраструктуре разработки.

---

Пароль по умолчанию больше нельзя считать нормой

Одной из самых опасных традиций массовой электроники являются одинаковые заводские учетные данные:

• admin/admin;
• root/12345;
• service/service;
• скрытый инженерный пароль;
• общий сервисный ключ для всей серии.

Такое решение удобно на производстве и в сервисе, но создает системную уязвимость.

Компрометация одного пароля дает доступ к тысячам устройств.

Безопасная модель может включать:

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

Но уникальные данные необходимо:

• сгенерировать;
• безопасно записать;
• связать с серийным номером;
• защитить от утечки;
• передать пользователю;
• восстановить при необходимости;
• отозвать при компрометации.

Это уже задача не только программиста, но и производства, логистики, службы поддержки и информационной безопасности.

---

Отладочные интерфейсы превращаются в часть модели угроз

На прототипе разработчику необходим полный доступ:

• SWD;
• JTAG;
• UART;
• USB DFU;
• загрузка через ROM;
• диагностическая консоль;
• тестовые точки.

На серийном изделии те же интерфейсы могут позволить:

• считать прошивку;
• извлечь ключи;
• изменить память;
• отключить проверку подписи;
• обойти авторизацию;
• получить административную консоль;
• клонировать устройство.

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

Поэтому при разработке необходимо определить:

• какие интерфейсы остаются в серийном изделии;
• как они блокируются;
• возможна ли обратная активация;
• требуется ли аутентификация сервиса;
• как будет выполняться ремонт;
• что произойдет при замене основной платы;
• где хранятся производственные ключи;
• можно ли считать память после включения защиты.

Безопасность и ремонтопригодность необходимо проектировать совместно.

---

Уязвимость может находиться не в вашем коде

Современная прошивка редко создается полностью с нуля.

В нее входят:

• ядро операционной системы;
• TCP/IP-стек;
• файловая система;
• криптографическая библиотека;
• веб-сервер;
• USB-стек;
• драйверы;
• загрузчик;
• код производителя микроконтроллера;
• открытые компоненты;
• коммерческие библиотеки.

Даже небольшой контроллер может содержать десятки программных компонентов.

Уязвимость в одном из них способна затронуть сотни моделей устройств разных производителей.

Главный вопрос после публикации уязвимости

Необходимо быстро ответить:

«Используем ли мы этот компонент, в каких продуктах и в каких версиях?»

Если перечень зависимостей хранится в памяти одного программиста, ответ может занять недели.

Поэтому CRA требует более формального управления составом программного обеспечения, включая подготовку Software Bill of Materials — SBOM.

SBOM представляет собой машиночитаемый перечень программных компонентов и зависимостей. В рамках CRA он должен охватывать по меньшей мере зависимости верхнего уровня и входить в техническую документацию; обязанности не означают, что такой перечень обязательно должен публиковаться для всех пользователей.

Пример упрощенной структуры:

Компонент	Версия	Назначение	Источник	Лицензия	Известные уязвимости
FreeRTOS	10.6.1	Операционная система	открытый код	MIT	проверяется
lwIP	2.1.3	TCP/IP	открытый код	BSD	проверяется
mbedTLS	3.5.2	Криптография	открытый код	Apache 2.0	проверяется
Bootloader X	1.4	Обновление	собственный код	закрытая	внутренний аудит
Web UI	2.8	Управление	собственный код	закрытая	внутренний аудит

Но SBOM полезен только тогда, когда он связан с реальными выпусками продукции.

Необходимо знать:

• в какой сборке присутствовал компонент;
• какие серийные номера получили эту сборку;
• обновлялось ли устройство после поставки;
• используется ли уязвимая функция;
• доступна ли она в типовой конфигурации.

Сам по себе Excel-файл со списком библиотек не обеспечивает безопасность.

---

Аппаратная спецификация тоже должна стать управляемой

Термин SBOM относится прежде всего к программному составу, но для производителя электроники важна и аппаратная прослеживаемость.

Одна модель устройства может выпускаться с разными:

• микроконтроллерами;
• сетевыми контроллерами;
• модулями Wi-Fi;
• загрузчиками;
• типами памяти;
• аппаратными ревизиями;
• настройками конфигурационных битов.

Замена компонента из-за дефицита может изменить профиль безопасности.

Например, новый Wi-Fi-модуль содержит:

• другую версию встроенного ПО;
• собственную облачную службу;
• сервисный интерфейс;
• иной механизм обновления;
• ранее неизвестную зависимость.

Функционально изделие остается тем же. С точки зрения кибербезопасности появляется новая цепочка поставок и новый набор рисков.

Поэтому управление изменениями должно включать не только проверку:

«Подходит ли компонент по выводам и характеристикам?»

Необходимо спрашивать:

«Как изменится поверхность атаки и кто будет сопровождать встроенное программное обеспечение этого компонента?»

---

Что такое период поддержки

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

Это меняет экономику проекта.

Раньше производитель мог рассчитать цену изделия из:

• разработки;
• компонентов;
• производства;
• испытаний;
• логистики;
• гарантии.

Теперь необходимо учитывать будущие расходы:

$C_{\text{разработка}} + C_{\text{производство}} + C_{\text{сертификация}} + C_{\text{мониторинг}} + C_{\text{обновления}} + C_{\text{реагирование}}.$

Если продукт поддерживается много лет, компании потребуется:

• хранить исходный код;
• сохранять среду сборки;
• контролировать ключи подписи;
• отслеживать уязвимости компонентов;
• выпускать обновления;
• тестировать исправления;
• сохранять совместимость;
• информировать пользователей;
• поддерживать специалистов, знающих архитектуру.

Продажа устройства больше не завершает проект.

Она запускает период ответственности.

---

Почему «после гарантии» больше не означает «не наша проблема»

Гарантия обычно связана с исправностью изделия и договорными обязательствами продавца.

Период кибербезопасностной поддержки — другое понятие.

Устройство может быть полностью исправным:

• включаться;
• измерять;
• передавать данные;
• управлять оборудованием.

Но его программное обеспечение может содержать критическую уязвимость.

Замена такого устройства не всегда нужна. Возможно, достаточно обновления.

Однако обновление должен кто-то:

• разработать;
• проверить;
• подписать;
• распространить;
• документировать.

Таким образом, производитель должен заранее решить, сколько лет он способен сопровождать продукт и какие ресурсы для этого потребуются.

---

Практический пример: уязвимость промышленного контроллера

Предположим, компания выпускает контроллер удаленного ввода-вывода.

Он содержит:

• микроконтроллер;
• Ethernet;
• Modbus TCP;
• веб-интерфейс настройки;
• механизм обновления;
• облачную службу мониторинга.

В веб-сервере используется сторонняя библиотека версии 4.2.

Исследователь сообщает, что специально сформированный HTTP-запрос вызывает переполнение памяти и позволяет выполнить произвольный код.

Вариант компании без системы управления уязвимостями

1. Письмо попадает в общий отдел поддержки.
2. Поддержка не понимает его серьезности.
3. Через два дня сообщение пересылают программисту.
4. Программист не знает, в каких версиях использовалась библиотека.
5. Исходный код старой прошивки хранится на компьютере бывшего сотрудника.
6. Неизвестно, сколько устройств доступно из интернета.
7. Механизм удаленного обновления отсутствует.
8. Единственный способ исправления — выезд к заказчику.
9. Юридический отдел узнает о проблеме через неделю.
10. Публичное описание атаки уже распространяется.

Вариант подготовленного производителя

1. Сообщение поступает на выделенный адрес безопасности.
2. Ответственный регистрирует событие и время получения.
3. Команда проверяет достоверность информации.
4. SBOM показывает все затронутые версии продукта.
5. Реестр поставок позволяет определить клиентов и серийные номера.
6. Инженеры временно рекомендуют отключить внешний доступ к веб-интерфейсу.
7. Запускается подготовка исправленной сборки.
8. Руководитель процесса принимает решение о необходимости уведомления.
9. В течение 24 часов передается раннее предупреждение.
10. Через 72 часа предоставляется первоначальная оценка.
11. Подписанное обновление проходит испытания и распространяется пользователям.
12. После появления корректирующей меры направляется итоговый отчет.

Разница между двумя компаниями заключается не только в квалификации программиста.

Разница — в наличии процесса.

---

Производителю потребуется собственная служба реагирования

Крупные компании создают Product Security Incident Response Team — PSIRT, команду реагирования на инциденты безопасности продукции.

Для небольшой организации это не обязательно должен быть отдельный штатный отдел.

Функции могут быть распределены между:

• главным конструктором;
• разработчиком прошивки;
• специалистом по информационной безопасности;
• руководителем качества;
• службой поддержки;
• юристом;
• директором по продукту.

Главное — заранее определить роли.

Минимальная схема процесса

Прием информации

Необходим публичный и постоянно контролируемый канал:

• специальный адрес электронной почты;
• форма на сайте;
• файл security.txt;
• защищенный способ передачи технических материалов.

Регистрация

Фиксируются:

• дата и время получения;
• источник;
• затронутый продукт;
• предполагаемая версия;
• описание;
• приложенные доказательства;
• контакт исследователя.

Техническая проверка

Инженеры пытаются:

• воспроизвести проблему;
• определить условия эксплуатации;
• оценить доступность уязвимого интерфейса;
• понять возможные последствия;
• установить затронутые версии.

Классификация

Определяется:

• является ли проблема уязвимостью;
• имеются ли признаки активной эксплуатации;
• произошел ли серьезный инцидент;
• требуется ли обязательное уведомление;
• какие временные меры доступны.

Исправление

Разрабатываются:

• обновление;
• конфигурационное изменение;
• временное ограничение функции;
• сетевое правило;
• инструкция пользователю;
• замена компонента.

Коммуникация

Компания взаимодействует:

• с компетентными органами;
• с пользователями;
• с импортерами;
• с дистрибьюторами;
• с интеграторами;
• с поставщиками компонентов;
• с исследователем.

---

Как подготовиться к 24-часовому сроку

1. Составить реестр продукции

Для каждого изделия необходимо зафиксировать:

• наименование;
• аппаратные ревизии;
• версии прошивки;
• загрузчик;
• программные зависимости;
• рынки поставки;
• импортеров;
• дистрибьюторов;
• период поддержки;
• механизм обновления;
• ответственного за продукт.

2. Назначить владельца процесса

Фраза «этим занимается IT-отдел» недостаточна.

IT-отдел обычно отвечает за корпоративную инфраструктуру:

• компьютеры;
• серверы;
• почту;
• учетные записи.

CRA относится к безопасности выпускаемой продукции.

Необходим человек, имеющий полномочия:

• созвать техническую команду;
• получить данные от отдела продаж;
• связаться с руководством;
• запустить процедуру уведомления;
• координировать выпуск исправления.

3. Подготовить шаблон первичного уведомления

В момент кризиса нельзя начинать с чистого листа.

Шаблон должен содержать поля:

• производитель;
• контактное лицо;
• продукт;
• версия;
• описание события;
• дата обнаружения;
• дата осведомленности;
• признаки эксплуатации;
• предварительная оценка;
• затронутые рынки;
• временные меры;
• состояние расследования.

4. Провести учебный инцидент

Полезно смоделировать ситуацию:

«Во вторник в 16:00 мы получили сообщение об активной эксплуатации библиотеки, установленной в трех моделях контроллеров».

Затем проверить:

• кто первым увидит сообщение;
• как быстро будет собрана команда;
• где находится SBOM;
• кто определит затронутые версии;
• кто имеет доступ к ключам подписи;
• кто свяжется с европейским импортером;
• кто утвердит текст уведомления;
• можно ли уложиться в 24 часа.

Такая тренировка почти неизбежно выявит организационные разрывы.

5. Проверить старые продукты

Обязанности по уведомлению с сентября 2026 года могут затрагивать и ранее представленные на рынке продукты. Поэтому анализ нельзя ограничивать новыми разработками.

Нужно определить:

• какие старые изделия все еще используются;
• какие из них поставлялись в ЕС;
• существуют ли исходные коды;
• можно ли воспроизвести сборку;
• кто знает архитектуру;
• возможно ли обновление;
• какие сторонние компоненты использованы;
• какие клиенты могут быть затронуты.

---

Какие документы понадобятся производителю

К 2027 году одного руководства пользователя будет недостаточно.

Полноценное досье продукта может включать:

• описание назначения и архитектуры;
• модель угроз;
• оценку киберрисков;
• перечень активов;
• описание интерфейсов;
• схему доверия;
• описание механизма загрузки;
• описание обновления;
• SBOM;
• сведения о сторонних компонентах;
• результаты анализа кода;
• результаты испытаний;
• перечень известных ограничений;
• процедуру управления уязвимостями;
• политику раскрытия уязвимостей;
• период поддержки;
• инструкции по безопасной установке;
• инструкции по безопасной эксплуатации;
• порядок завершения поддержки;
• план реагирования на инциденты;
• подтверждение оценки соответствия.

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

Это означает, что недостаточно фактически реализовать защиту.

Необходимо уметь объяснить:

• от какого риска она защищает;
• почему выбран именно этот механизм;
• как проверена его работа;
• какие остаточные риски остаются.

---

Цена несоответствия

CRA предусматривает значительные верхние пределы штрафов.

За нарушения существенных требований к кибербезопасности и ключевых обязанностей производителя максимальный уровень может достигать:
$15,000,000\ \text{евро}$ или $2{,}5$ %

общего мирового годового оборота предприятия за предыдущий финансовый год — в зависимости от применимого правила и того, какая величина окажется выше.

Для других категорий нарушений предусмотрены уровни до 10 миллионов евро или 2% оборота, а за предоставление неверной либо вводящей в заблуждение информации — до 5 миллионов евро или 1% оборота. Конкретное применение санкций осуществляется в рамках национальных систем государств ЕС. При этом штраф — не единственный риск.

Последствия могут включать:

• ограничение продажи;
• отзыв продукции;
• необходимость срочного обновления;
• приостановку поставок;
• потерю европейского импортера;
• претензии заказчиков;
• затраты на расследование;
• репутационный ущерб;
• пересмотр контрактов;
• удорожание страхования;
• потерю доверия интеграторов.

Для промышленной электроники особенно опасна ситуация, когда уязвимость становится известна после установки устройств на критических объектах.

---

Небольшим компаниям тоже придется готовиться

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

Маленькая компания сталкивается с теми же техническими вопросами:

• где хранится исходный код;
• кто отслеживает зависимости;
• как выпускаются обновления;
• кто принимает сообщения;
• как идентифицируются затронутые устройства;
• кто общается с партнерами.

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

Но малому бизнесу не обязательно сразу строить дорогостоящий центр кибербезопасности.

Начать можно с базовой дисциплины:

• единый репозиторий;
• воспроизводимая сборка;
• учет зависимостей;
• резервное копирование;
• назначенный ответственный;
• канал приема сообщений;
• шаблон реагирования;
• подписанные обновления;
• регулярная проверка компонентов.

---

Ошибки, которые могут дорого обойтись

«Устройство находится за роутером, поэтому оно безопасно»

Сетевая изоляция снижает риск, но не устраняет его.

Устройство может быть атаковано:

• из локальной сети;
• через скомпрометированный компьютер;
• через облачный сервис;
• через обновление;
• через сервисный ноутбук;
• через USB;
• через цепочку поставок.

«Мы используем библиотеку производителя чипа, значит, за нее отвечает он»

Производитель конечного продукта обязан оценивать влияние интегрируемых компонентов. CRA прямо требует должной осмотрительности при использовании сторонних компонентов.

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

«Никто не знает, что у нас есть эта уязвимость»

Это не защитная стратегия.

Информацию может получить:

• исследователь;
• заказчик;
• поставщик компонента;
• интегратор;
• национальный центр реагирования;
• оператор инфраструктуры;
• злоумышленник.

«Мы исправим проблему в следующей аппаратной ревизии»

У пользователей останутся ранее проданные устройства.

Если обновление невозможно, производителю придется искать компенсирующие меры или рассматривать замену продукции.

«Наш контроллер не хранит персональные данные»

Кибербезопасность не ограничивается персональными данными.

Компрометация промышленного устройства может повлиять на:

• технологический процесс;
• безопасность оборудования;
• доступность производства;
• целостность измерений;
• качество продукции;
• физическую безопасность людей.

---

Экспертное мнение Ассоциации разработчиков и конструкторов

Ассоциация разработчиков и конструкторов — АРК — рассматривает Cyber Resilience Act не просто как еще одно европейское требование к сертификации. Это признак фундаментального изменения самой профессии разработчика электроники.

Раньше производитель мог считать продукт завершенным после того, как:

• разработана схема;
• разведена печатная плата;
• написана прошивка;
• пройдены испытания;
• запущено производство.

Теперь продукт нельзя считать законченным, пока не определено:

• как обнаруживать его уязвимости;
• как устанавливать затронутые версии;
• как выпускать исправления;
• как доставлять их пользователям;
• кто будет выполнять эту работу через несколько лет;
• что произойдет при завершении поддержки.

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

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

Главная опасность — не штраф, а потеря способности сопровождать собственный продукт

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

В такой ситуации производитель формально владеет товарным знаком и конструкторской документацией, но не способен быстро и безопасно изменить свой продукт. Это и есть одна из наиболее серьезных форм технологической зависимости.

Безопасность должна начинаться с технического задания

Добавить защищенную загрузку в почти завершенное устройство часто невозможно без изменения:

• микроконтроллера;
• структуры памяти;
• загрузчика;
• производственного процесса;
• ключевой инфраструктуры;
• сервисной процедуры.

Поэтому требования к безопасности необходимо формировать до выбора элементной базы.

В техническом задании должны быть ответы:

• какой срок поддержки установлен;
• как будет обновляться прошивка;
• нужна ли удаленная установка;
• что происходит при отключении питания;
• как защищается откат;
• какие ключи используются;
• где они генерируются;
• как блокируются отладочные интерфейсы;
• какие журналы событий хранятся;
• как пользователь узнает об обновлении;
• что происходит после окончания поддержки.

CRA может стать стимулом для развития инженерной культуры

Новые требования создадут дополнительные расходы, особенно для небольших производителей. Однако они способны привести к положительным изменениям:

• появлению воспроизводимых сборок;
• дисциплине управления версиями;
• учету сторонних библиотек;
• развитию безопасных загрузчиков;
• защите производственных ключей;
• улучшению документации;
• более ответственному выбору компонентов;
• появлению команд сопровождения продукта.

АРК считает, что кибербезопасность не должна превращаться в формальное заполнение таблиц ради маркировки. Если оценка рисков выполняется только для отчета, а общий пароль администратора остается в десяти тысячах устройств, цель регулирования не достигнута. Настоящее соответствие начинается с инженерного понимания системы.

---

Что производителю следует сделать уже сейчас

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

Этап 1. Определить применимость

Необходимо установить:

• поставлялась ли продукция в ЕС;
• продолжает ли она быть доступной на рынке;
• кто считается производителем;
• кто является импортером;
• какие программные и аппаратные продукты входят в область анализа;
• имеются ли отраслевые исключения.

Этап 2. Провести инвентаризацию

Следует собрать:

• перечень продуктов;
• аппаратные ревизии;
• версии прошивок;
• сторонние компоненты;
• загрузчики;
• приложения;
• облачные службы;
• механизмы обновления;
• контакты партнеров.

Этап 3. Создать процесс приема сообщений

Нужны:

• контролируемый канал;
• назначенный ответственный;
• регистрация времени;
• порядок эскалации;
• защита конфиденциальной информации исследователя.

Этап 4. Подготовить процедуру 24/72 часа

Необходимо определить:

• кто оценивает техническую достоверность;
• кто принимает решение;
• кто готовит уведомление;
• кто его утверждает;
• кто взаимодействует с CSIRT, ENISA и партнерами;
• кто информирует клиентов.

Этап 5. Проверить способность выпускать обновления

Для каждого поддерживаемого продукта следует ответить:

• сохранился ли исходный код;
• воспроизводится ли сборка;
• доступны ли инструменты;
• действуют ли ключи;
• существует ли тестовое оборудование;
• можно ли безопасно доставить исправление.

Этап 6. Начать формирование SBOM

Даже до начала применения полного набора требований CRA перечень компонентов необходим для быстрой оценки инцидентов.

Этап 7. Провести учебную тревогу

Компания должна попытаться пройти полный сценарий за 24 часа.

Не теоретически, а с реальными:

• людьми;
• документами;
• версиями;
• ключами;
• контактами;
• шаблонами.

---

CRA меняет отношения между разработчиком и заказчиком

Для заказчика электронное устройство больше не должно оцениваться только по цене, числу функций и сроку поставки.

При закупке станет важно спрашивать:

• Как долго поддерживается продукт?
• Есть ли механизм безопасного обновления?
• Кто выпускает исправления?
• Можно ли обновить устройство без остановки производства?
• Как производитель сообщает об уязвимостях?
• Используются ли уникальные учетные данные?
• Есть ли перечень программных компонентов?
• Что произойдет после окончания поддержки?
• Можно ли эксплуатировать устройство в изолированной сети?
• Какие функции можно отключить?
• Как выполняется восстановление?

Дешевое устройство без поддержки может оказаться значительно дороже в течение жизненного цикла.

---

Заключение: эпоха «продали и забыли» заканчивается

С 11 сентября 2026 года европейский Cyber Resilience Act делает активно эксплуатируемую уязвимость и серьезный инцидент не только технической проблемой, но и событием, требующим формального реагирования производителя.

А с декабря 2027 года требования станут еще шире. Производителю придется доказывать, что он:

• анализирует киберриски;
• проектирует продукт с учетом угроз;
• контролирует сторонние компоненты;
• знает состав программного обеспечения;
• способен выпускать обновления;
• сопровождает продукт в установленный период;
• документирует принятые меры;
• реагирует на обнаруженные уязвимости.

Это меняет само представление о готовом электронном изделии.

Готовый продукт — это уже не только плата, корпус и прошивка.

Это также:

• система обновления;
• инфраструктура ключей;
• реестр компонентов;
• канал приема сообщений;
• команда реагирования;
• техническая документация;
• обязательства по сопровождению.

Главный вопрос, который теперь должен задать себе каждый производитель, звучит не так:

«Есть ли в нашем устройстве уязвимости?»

Уязвимости рано или поздно обнаруживаются почти в любой достаточно сложной системе.

Правильный вопрос:

«Сможем ли мы узнать о проблеме, определить затронутые устройства, защитить пользователей и выпустить исправление раньше, чем уязвимость превратится в массовую атаку?»

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

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

Об авторе

akme

Administrator

Просмотреть все записи