Чеклист за съответствие с Cyber Resilience Act (безплатен Excel)

Този чеклист за съответствие с Cyber Resilience Act превръща Регламент (ЕС) 2024/2847 в 24 конкретни проверки, които можете да проведете срещу един продукт. Това е безплатен Excel файл, направен за ръководителите по продуктова сигурност, CISO и мениджърите по съответствие, които трябва да покажат, че продуктите им с цифрови елементи отговарят на CRA, преди задълженията му да заработят. Вместо да препрочитате целия регламент, работите по списък, който се съпоставя със съществените изисквания по Annex I, задължението за софтуерна спецификация на материалите, координирания процес по обработване на уязвимости и сроковете за докладване към ENISA. Всеки ред ви казва как изглежда доброто изпълнение и къде живее доказателството. Свалете го по-долу, споделете го с инженеринга и го използвайте като гръбнак на прегледа си за готовност по CRA.

Какво покрива чеклистът за съответствие с Cyber Resilience Act

Файлът е един работен лист от 24 позиции, групирани в областите, които CRA наистина следи. Всеки ред носи едни и същи колони: изискването на разбираем език, как изглежда доброто изпълнение, доказателството, което го потвърждава, отговорник и поле за статус, което можете да зададете на Изпълнено, Частично или Пропуск. Тази структура означава, че чеклистът работи и като жив списък със задачи.

24-те позиции попадат в пет блока:

• Съществени изисквания за киберсигурност. Свойствата на продукта по Annex I, от сигурна конфигурация по подразбиране до защита на поверителността и целостта на данните, които продуктът обработва.
• Софтуерна спецификация на материалите. Изготвяне и поддържане на машинночетим SBOM, за да знаете вие и клиентите ви кои компоненти има вътре в продукта.
• Обработване на уязвимости. Координиран процес за идентифициране, документиране и отстраняване на уязвимости през целия период на поддръжка.
• Актуализации за сигурност. Доставяне на актуализации през определения период на поддръжка, така че известните уязвимости наистина да бъдат отстранени за потребителите.
• Докладване. Уведомяване на ENISA за активно експлоатирани уязвимости и тежки инциденти в рамките на изискваните срокове.

EU Cyber Resilience Act честно: какво наистина има значение

CRA (Регламент (ЕС) 2024/2847) е регулация на продукта. Той поставя изисквания за киберсигурност към продуктите с цифрови елементи, пускани на пазара в ЕС, и задълженията му се закачат за самия продукт, а корпоративната ви документация стои отделно. Точно това екипите бъркат най-често: контролите по CRA са свойства на продукта и се различават по същност от организационните процеси, затова стоят отделно от ISMS. Сертифициран периметър по ISO 27001 сам по себе си оставя свързаното устройство извън съответствие.

По същата причина е добре да сте скептични към всяко съпоставяне, което твърди, че съществуващите ви контроли от системата за управление вече покриват голяма част от CRA. Заемането на такова покритие изглежда ефективно и произвежда картина на готовност, която е просто невярна. Истинското припокриване е около обработването на уязвимости и докладването на инциденти, а навсякъде другаде е тънко.

Пет задължения носят тежестта:

1. Съществени изисквания. Всеки продукт трябва да отговаря на съществените изисквания за киберсигурност по Annex I, базовите свойства за сигурност, с които продуктът излиза.
2. Актуализации за сигурност. Производителите трябва да предоставят актуализации за сигурност през определен период на поддръжка, така че уязвимостите да продължават да се отстраняват, докато продуктът е в употреба. Това е задължението с ценоразпис отзад. Определянето на период на поддръжка е търговско решение също толкова, колкото и решение по сигурност, затова хората, които отговарят за пътната карта и за маржа, трябва да са в този разговор заедно с екипа по сигурност.
3. SBOM. Трябва да изготвите и поддържате софтуерна спецификация на материалите, така че компонентите вътре в продукта да са известни и проследими.
4. Обработване на уязвимости. Координиран процес по обработване на уязвимости трябва да идентифицира, документира и отстранява проблеми през същия този период на поддръжка.
5. Докладване. Активно експлоатираните уязвимости и тежките инциденти трябва да се докладват на ENISA.

Подредени по трудност, петте са неравномерни. SBOM е предимно инструментален проблем и приличен build пайплайн ви докарва до голяма част от целта за седмици. Съществените изисквания са инженерна програма, защото сигурните настройки по подразбиране и работещият механизъм за актуализация трябва да са проектирани отвътре, а част от вашите няма да са били. Процесът по обработване на уязвимости е скритата трудност: лесен за описване, тежък за реално поддържане с години, през всяка поддържана версия, с истински човек от другата страна на канала за приемане.

Календарът е частта, която повечето планове подценяват. Задълженията за докладване започват на 11 септември 2026 г., а основните задължения на производителите се прилагат от 11 декември 2027 г. Работете назад от тези две дати, вместо да третирате CRA като далечен проблем. На практика датата за докладване е по-стегнатата от двете, защото идва първа и защото изграждането на координирано разкриване, наблюдаван канал за приемане и договорено правило за това какво се брои за активно експлоатирано е организационна работа, която иска няколко екипа да променят поведението си. Това е по-бавно от написването на политика. Ако обмисляте инструменти, с които да носите това във времето, нашият преглед на софтуер за съответствие с CRA минава през вариантите; всичко останало на тази страница приема, че първо вършите работата по готовността сами.

Как да използвате чеклиста за съответствие с Cyber Resilience Act

1. Изберете един продукт. CRA работи продукт по продукт, затова стеснете обхвата на чеклиста до един продукт с цифрови елементи, преди да започнете. Изберете този, който е най-близо до издаване, дори когато друг изглежда по-лесен. Научавате повече, когато проведете чеклиста срещу нещо с реален краен срок зад него, а пропуските, които изваждате наяве, ще бъдат тези, които наистина ви струват.
2. Назначете отговорници. Дайте на всеки от 24-те реда поименен отговорник в инженеринга, сигурността или продукта. Нищо не помръдва без закачен човек.
3. Оценете всяка позиция. Отбележете всеки ред като Изпълнено, Частично или Пропуск и свържете доказателството до него: конфигурационна база, файла със SBOM, политиката по обработване на уязвимости, графика за актуализации.
4. Затворете пропуските спрямо датите. Подредете отстраняването така, че докладването на уязвимости и инциденти да е готово преди 11 септември 2026 г., а пълните задължения на производителя преди 11 декември 2027 г.
5. Преминавайте го отново преди всяко издание. Третирайте чеклиста като контролна точка при пускане и го проверявайте отново винаги когато продуктът се промени съществено.

Направете това автоматично във Venvera

Excel файлът е силна отправна точка, но електронната таблица остарява в мига, в който продуктът се промени. Във Venvera същите 24 проверки живеят в рамката CRA като проследявани контроли с отговорници, крайни срокове и доказателства, закачени към всеки един. Когато SBOM или политиката ви по обработване на уязвимости бъдат обновени, статусът на контрола го отразява, вместо тихо да се разминава с действителността във файл, който никой не отваря повторно. Тъй като свойствата на продукта по CRA стоят до другите ви задължения, доказателствата, които вече сте събрали, могат да се използват повторно там, където наистина важат, вместо да се събират два пъти. Venvera започва от 399 EUR на месец. Ръчният чеклист по-долу ви ориентира днес; платформата поддържа работата актуална след това.

Често задавани въпроси

Кога влиза в сила EU Cyber Resilience Act?

CRA влиза поетапно на две ключови дати. Задълженията за докладване започват на 11 септември 2026 г., а основните задължения на производителите се прилагат от 11 декември 2027 г. Планирайте готовността си за докладване на уязвимости и инциденти спрямо по-ранната дата, защото тогава уведомленията към ENISA стават дължими.

Заменя ли CRA стандарта ISO 27001 или моята ISMS?

Не. Контролите по CRA са свойства на продукта и се различават по същност от организационните процеси, затова стоят отделно от ISMS. Сертификатът по ISO 27001 описва как организацията ви управлява сигурността; CRA пита дали конкретен продукт отговаря на съществените изисквания по Annex I, доставя ли се със SBOM и има ли работещ процес по обработване на уязвимости.

Какво е SBOM и защо CRA го изисква?

Софтуерната спецификация на материалите е машинночетим опис на компонентите вътре във вашия продукт. CRA изисква производителите да изготвят и поддържат такъв, за да могат уязвимостите в компоненти на трети страни да бъдат откривани и отстранявани през целия период на поддръжка, вместо да останат невидими, докато не бъдат експлоатирани.

Кой трябва да спазва Cyber Resilience Act?

Производителите, които пускат продукти с цифрови елементи на пазара в ЕС. Те трябва да отговарят на съществените изисквания по Annex I, да предоставят актуализации за сигурност през период на поддръжка, да изготвят и поддържат SBOM, да провеждат координиран процес по обработване на уязвимости и да докладват активно експлоатирани уязвимости и тежки инциденти на ENISA.