Подготовка процесса работы производителя с уязвимостями по CRA: приём сообщений, свидетельства и отсчёт сроков уведомлений

Цель

Состояние на 25 октября 2026 года. Подготовить процесс работы производителя с уязвимостями так, чтобы во время инцидента можно было получить свидетельства, сведения об ответственности за продукты и сроки уведомлений. При обновлении процесса заново проверяйте статью 14, приложение I и актуальные инструкции ENISA по SRP. Это предлагаемый порядок подготовки, а не заявление о том, что организация прошла оценку соответствия.

Обязанность уведомлять по статье 14 действует с 11 сентября 2026 года. Статья 71 устанавливает 11 декабря 2027 года для более широкого круга требований, включая обязанности по работе с уязвимостями из приложения I. Подготовка к этим будущим обязанностям может помогать с уведомлениями уже сейчас, но даты их применения необходимо различать. Рекомендации Еврокомиссии по уведомлениям.

Предварительные условия

Определите соответствующие продукты производителя, инженерные команды, отвечающие за них, ответственного за уведомления и его заместителя. Обеспечьте запись об инциденте с ограниченным доступом, доступ к информации о выпусках и компонентах, а также канал связи с затронутыми пользователями. Это предлагаемые организационные меры. Подтвердите выбор подходящей координирующей CSIRT по статье 14(7), а не выбирайте её лишь из-за удобного языка общения.

Шаги

1. Закрепите приём сообщений за конкретным ответственным. Подготовьте политику координированного раскрытия уязвимостей и контакт для сообщений, описанные в приложении I, части II. Необязательный файл security.txt по RFC 9116 может указать исследователям, где их найти: используйте HTTPS по адресу /.well-known/security.txt, включите обязательные поля Contact и Expires и дайте ссылку на политику через Policy. Поддерживайте актуальность файла и адресов, на которые он ссылается. RFC 9116, разделы 2, 3 и 5.

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

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

4. Оценивайте установленные законом основания по отдельности. Согласно статье 3(42), активная эксплуатация требует надёжных свидетельств того, что злоумышленник использовал уязвимость без разрешения владельца системы. Сопоставляйте серьёзные инциденты с обоими критериями статьи 14(5). Фиксируйте свидетельства и неразрешённые вопросы; одна оценка серьёзности не доказывает активную эксплуатацию. Шаги 1, 3 и 4 опираются на регламент.

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

6. Подготовьте доступ к платформе и связь. ENISA требует персональные учётные записи EU Login с многофакторной аутентификацией. В октябрьском FAQ рекомендуется начинать регистрацию в SRP, когда возникает необходимость в уведомлении; доступ к EU Login подготовьте заранее. Поддерживайте связь с затронутыми пользователями параллельно с уведомлением органов власти. FAQ ENISA по SRP, вопрос 9.

7. Проведите внутреннюю репетицию. Используйте вымышленный случай с продуктом и черновики отчётов вне действующей платформы уведомлений. Поручите заместителю найти свидетельства, восстановить сроки и объяснить выбор получателя. Зафиксируйте недостающие данные и после их дополнения повторите неудавшуюся передачу обязанностей.

Ожидаемый результат

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

Ограничения и основание проверки

Результаты репетиции или практического применения не заявляются. Предложение объединяет регламент, рекомендации Еврокомиссии, FAQ ENISA, обновлённый 15 октября 2026 года, и RFC 9116. Ни опубликованный файл с контактами, ни успешная репетиция не доказывают соответствия требованиям; охват продуктов и спорные оценки оснований по-прежнему требуют квалифицированного рассмотрения.