Back to Articles

Cyber Resilience Act: 11 септември 2026 е вистински рок

Повеќето уредби на ЕУ ви даваат датум на усогласеност и период на прилагодување во кој сите тивко се организираат. Cyber Resilience Act прави нешто друго. Неговата прва цврста обврска е часовник за пријава од 24 часа и тргнува на 11 септември 2026.

Часовник од 24 часа не може да се воведува постепено. Или процесот постои тој ден, или го пропуштате рокот.

Што е CRA

Уредбата (ЕУ) 2024/2847 поставува барања за сајбер безбедност за производи со дигитални елементи ставени на пазарот на ЕУ. Тој израз опфаќа многу повеќе отколку што првично се претпоставува: секој софтверски или хардверски производ и неговите решенија за далечинска обработка податоци, чија предвидена или разумно предвидлива употреба вклучува директна или индиректна податочна врска.

Поврзаните уреди се опфатени. Исто и најголемиот дел од комерцијалниот софтвер, оперативните системи, прелистувачите, мобилните апликации, фирмверот и компонентите во други производи.

Уредбата беше објавена во ноември 2024 и се применува во фази:

  • 11 јуни 2026: обврски на телата за оценување на сообразност.
  • 11 септември 2026: обврски за пријавување активно искористени ранливости и сериозни инциденти.
  • 11 декември 2027: целосна примена, вклучувајќи суштински барања за сајбер безбедност, CE ознака, техничка документација и список на софтверски состојки.

Средниот датум е оној по кој треба да се планира, бидејќи стигнува прв и бидејќи зависи од способности што можеби ги немате.

Што се случува на 11 септември 2026

Од тој датум производителите мора да пријават:

Активно искористени ранливости во своите производи со дигитални елементи и

сериозни инциденти што влијаат на безбедноста на тие производи.

Пријавата оди преку единствената платформа за пријавување CRA, што ја води ENISA, до CSIRT определен во земјата членка на главното седиште на производителот, кој потоа споделува со други засегнати CSIRT и со ENISA.

Роковите:

  • Во рок од 24 часа од дознавањето: рано предупредување.
  • Во рок од 72 часа: целосна пријава, вклучувајќи преземени корективни или ублажувачки мерки.
  • Во рок од 14 дена откако корективна мерка ќе стане достапна: завршен извештај за активно искористена ранливост.
  • Во рок од еден месец: завршен извештај за сериозен инцидент.

Дваесет и четири часа од дознавањето, не од потврдата ниту од отстранувањето. Ако ранливост во компонента на вашиот производ се искористува во живо во сабота, часовникот отчукува во сабота.

Зошто ова е потешко отколку што изгледа

Самата обврска за пријава е формулар. Тешкотијата е во сè што треба да имате пред да можете да го пополните.

Мора да знаете што е во вашиот производ

За да пријавите дека ранливост во вашиот производ активно се искористува, мора да знаете дека ранливата компонента е во вашиот производ. За современа апликација со стотици транзитивни зависности, тоа не е нешто на што човек одговара по памет.

Затоа тимовите сега градат процеси за список на софтверски состојки, повеќе од година пред формалното барање за SBOM од декември 2027. SBOM не е целта. Целта е да можете да одговорите на прашањето „дали нè засега тоа?" во рок од неколку часа, а SBOM го прави прашањето одговорливо.

Непријатно е што ова важи и за производи испорачани пред години. Ако имате поддржани уреди на терен со фирмвер изграден во 2022 од дрво зависности што никој не го запишал, реконструкцијата е вистинска работа.

Мора да набљудувате

Дознавањето го стартува часовникот, а се очекува да биде активно, а не случајно. Тоа значи следење канали за ранливости, претплата на известувања за вашите компоненти, следење каталози на познати искористени ранливости и постоење канал преку кој безбедносните истражувачи можат да ве стигнат и да добијат одговор.

Мора да имате патека за одлучување

Некој мора да може да одлучи, во кое било време, дали инцидентот го надминува прагот и дали часовникот тргнал. Без именувана улога и патека за ескалација, првите часови одат на утврдување кој смее да ја донесе одлуката.

Зависностите без поддршка стануваат обврска

Ако компонента во вашиот производ повеќе не добива безбедносни ажурирања, обврската за пријава при искористување сепак е ваша, а немате поправка нагоре на која да укажете. Проверката на зависностите без поддршка е една од покорисните работи во подготвителниот период, бидејќи одговорот понекогаш наметнува миграција со сопствен рок.

Што носи целосната примена во декември 2027

Обврските од декември 2027 се поголемата програма и треба да се почнат многу порано.

Безбедност по дизајн и стандардно. Производите мора да бидат проектирани, развиени и произведени така што да обезбедат соодветно ниво на сајбер безбедност засновано на ризик. Без стандардни лозинки. Безбедна конфигурација веднаш. Минимизирање на нападната површина. Заштита на податоците при пренос и во мирување.

Постапување со ранливости. Документиран процес што опфаќа идентификација, поправка, тестирање, дистрибуција и објавување. Безбедносните ажурирања мора да се обезбедат без одлагање и бесплатно, за период на поддршка што го одразува очекуваниот век на производот, при што пет години е честа референца.

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

Техничка документација и оценување на сообразност. Повеќето производи се самооценуваат. Важните и критичните категории, кои вклучуваат менаџери на лозинки, VPN, оперативни системи и индустриски контролни системи, бараат учество на трето лице.

CE ознака. Дигиталниот еквивалент на физичката ознака, со која изјавувате сообразност.

Политика за координирано објавување ранливости. Објавена, со контакт точка што работи.

Кој е навистина во опсег

Неколку гранични случаи постојано се појавуваат.

Слободниот софтвер и софтверот со отворен код развиен надвор од комерцијална дејност во голема мера е надвор од опсегот. Уредбата воведува поим на старател на софтвер со отворен код со полесни обврски. Но ако комерцијализирате отворен код или го испорачувате во производ што го продавате, обврските за производ се ваши.

Софтверот како услуга обично е надвор од CRA и потпаѓа под NIS2, иако решенијата за далечинска обработка податоци што се составен дел од производ со дигитални елементи се влечат внатре. Ако вашиот уред за работа зависи од вашиот cloud заднински дел, тој заднински дел патува со производот.

Увозниците и дистрибутерите исто така носат обврски. Ако производ на трето лице го ставате на пазарот на ЕУ под свое име или знак, се третирате како производител.

Производите регулирани на друго место, како медицинските средства, возилата и воздухопловната опрема, се обработуваат во сопствени рамки.

Прашањата за опсегот навистина не се тривијални и тоа е местото каде еден час со правници штеди месеци погрешно насочено инженерство.

Што би направиле во преостанатото време

Ако сте во опсег и почнувате сега, овој редослед работи:

Прво, воспоставете попис на производи. Што навистина имате на пазарот на ЕУ? Вклучувајќи стари верзии сè уште на терен, варијанти под туѓ бренд и производи што ги дистрибуирате за некој друг. Тој список обично е подолг отколку што било кој очекува.

Второ, вградете генерирање SBOM во CI. Генерирајте SBOM при секој build, во CycloneDX или SPDX, чувајте го покрај артефактот на изданието и држете го пребарлив. Поентата е да можете да прашате „кои од нашите испорачани изданија ја содржат оваа библиотека?" и да добиете одговор за неколку минути.

Трето, поврзете следење на ранливости. Внесете ги SBOM податоците во скенер што ги следи известувањата и каталозите на познати искористени ранливости, а известувањата насочете ги кон канал што некој го чита.

Четврто, напишете прирачник за инциденти. Кој прогласува, кој проценува, кој пријавува, кој комуницира. Именувани луѓе, заменици и контакти надвор од работно време. Потоа вежбајте еднаш со лажно известување. На вежбата откривате дека лицето со пристапните податоци за платформата за пријава е на одмор.

Петто, објавете политика за објавување ранливости. Датотека security.txt, адреса што некој ја следи и објавено време на одговор. Тоа е попладне работа и разликата меѓу тоа за проблемот да дознаете од истражувач или од новинар.

Шесто, почнете ја работата за декември 2027. Безбедните стандардни поставки, механизмите за ажурирање, одлуките за периодот на поддршка и документацијата се архитектонски прашања, а не хартија. Производите што ги проектирате во 2026 ќе бидат на пазарот и во 2028.

Преклопувањето што никој не го користи

Меѓу CRA и другите режими постои значително дуплирање, а повеќето компании секој го третираат одделно, што е трошење.

SBOM изграден за CRA одговара на најголемиот дел од прашањата за синџирот на снабдување од NIS2. Прирачникот за инциденти се преклопува со раното предупредување од 24 часа од NIS2 и со пријавата на повреда во 72 часа од GDPR. Процесите за постапување со ранливости директно ги хранат безбедносните прашалници на клиентите и корпоративните набавки.

Изградете го ова еднаш како платформска способност. Алтернативата се три тима што градат три верзии на истиот попис ресурси.

Каде да побарате помош

Градиме и одржуваме софтвер за компании што продаваат во ЕУ, што сè повеќе значи градење видливост на синџирот на снабдување и инфраструктура за ажурирање што CRA ја претпоставува. Ако утврдувате дали сте во опсег, или го имате септемврискиот датум во календарот без никакво следење, јавете се на office@c9group.dev.

Нашата услуга за одржување наследени системи често е појдовна точка, бидејќи производите со најлоша видливост на зависности обично се најстарите. Пошироката регулаторна слика е во нашиот водич за дигитална усогласеност со ЕУ 2026.

Ние сме инженери, а не правници. Одлуките за опсег и класификација им припаѓаат на вашите правници, а ние градиме според одговорот што ќе го дадат.