Акт за киберустойчивост: въведете задълженията в разработката на продукти

Актът за киберустойчивост (CRA) въвежда задължения за киберсигурност в жизнения цикъл на обхванатите продукти с цифрови елементи. За CTO практическата задача е да свърже това, което инженерите изграждат, пускат и поддържат, с доказателствата, необходими за демонстриране на изпълнението на тези задължения.

Тази връзка трябва да работи на ниво продукт и версия. Политика за сигурност на ниво компания не обяснява дали конкретно издание има сигурни настройки по подразбиране, какви зависимости съдържа или как клиентите ще получат актуализация на сигурността. Тикет за уязвимост, маркиран като „поправен“, не установява кои поддържани версии остават изложени.

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

Определете границата на продукта, преди да възлагате контроли

CRA се отнася до продуктите с цифрови елементи в неговия обхват, включително обхванатия хардуер и софтуер. Той не е универсално правило за всяка SaaS услуга. Хоствана услуга и софтуер, разпространяван до клиенти, може да изискват различни анализи, а отдалечената обработка, която е неразделна част от продукта, също трябва да бъде разгледана.

Използвайте насоките на Европейската комисия за CRA като отправна точка, след което решете правните въпроси, специфични за продукта. Запишете заключението, вместо да разчитате на неформалното допускане на екипа.

За всеки продукт кандидат установете:

• Какво получават клиентите: хардуер, инсталиран софтуер, компоненти за изтегляне или комбинация.
• Кои функции за отдалечена обработка са необходими, за да може продуктът да изпълнява своите функции.
• Как продуктът се доставя на пазара на ЕС и кое юридическо лице го доставя.
• Вашата роля като икономически оператор: производител, вносител, дистрибутор или друга релевантна роля.
• Приложимите изключения, специфичното за продукта законодателство и съображенията относно отворения код.
• Категорията на продукта и произтичащите от нея изисквания за оценяване на съответствието.

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

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

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

Работете по актуалните дати за прилагане

Комисията посочва 11 септември 2026 г. за задълженията за докладване и 11 декември 2027 г. за основните изисквания на CRA. Към 7 октомври 2026 г. датата за докладване вече е отминала. Третирайте готовността за докладване като текущо оперативно изискване, а не като задача, отложена до подготовката за съответствие.

Поддържайте видими два работни потока:

Продуктите, доставени преди основната дата на прилагане, изискват внимание към преходните разпоредби и съществените изменения. Не приемайте, че по-стар продукт е без значение за докладването само защото първоначалното му издание предхожда декември 2027 г.

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

Превърнете изискванията за сигурност в критерии за проектиране и издаване

Съществените изисквания на CRA обхващат свойствата на сигурността на продукта и обработката на уязвимости. Тяхното внедряване трябва да следва оценката на риска за киберсигурността на продукта, а не универсален контролен списък, прилаган без архитектурен контекст.

Започнете с това как продуктът може да причини вреда. Опишете потребителите, средите за внедряване, изложените интерфейси, привилегированите операции, чувствителните данни и предвидимата неправилна употреба. Включете оперативните допускания на клиента: устройство, внедрено в индустриална мрежа, има различна експозиция и ограничения за възстановяване от настолна помощна програма.

Практическо упражнение по моделиране на заплахи може да подкрепи тази работа; насоките на OWASP за моделиране на заплахи предлагат утвърден подход. Резултатът трябва да свързва заплахите с конкретни изисквания, проектни решения и тестове.

Помислете как познатите изисквания стават проверими:

Това са практически примери за внедряване, а не заместител на приложимите изисквания. Определяйте релевантността и достатъчността чрез оценката на риска.

Добавете критерии за приемане по отношение на сигурността към работата по функциите. Нов административен API трябва да пристига с решения за удостоверяване, оторизация, обработка на входни данни и регистриране, а не с обещание, че отделът по сигурност ще го прегледа по-късно. Преразглеждайте модела на заплахите при добавяне на отдалечен интерфейс, привилегирован компонент или нова граница на доверие.

Одобрението на изданието трябва да идентифицира нерешените уязвимости, тяхната експлоатируемост, засегнатите конфигурации и третирането им. Прилагайте изискването на CRA продуктите да се предоставят на пазара без известни експлоатируеми уязвимости, като отчитате оценката на риска и приложимите съществени изисквания; записването или приемането на риск само по себе си не удовлетворява това изискване. Резултатът от скенер сам по себе си не може да вземе това решение: значение имат достижимостта, предпоставките и поведението на продукта. И обратно, ниската числена оценка за тежест не е достатъчна причина да се пренебрегне уязвимост, която има последици във вашия модел на внедряване.

Записът за изданието трябва да свързва одобрената ревизия на изходния код, артефакта от компилацията, регистъра на зависимостите, резултатите от тестовете и решението по сигурността. Така оценката става възпроизводима, когато клиент или орган по-късно попита за конкретна версия.

Направете проверката на компонентите част от процеса на компилиране

Компонентите от трети страни създават задължения, които не могат да бъдат изпълнени чрез препращане на известие за сигурност от доставчика нагоре по веригата. Трябва да разбирате какво сте пуснали, дали е засегнато и как можете да го поправите.

CRA включва изискване за спецификация на софтуерните компоненти (SBOM) в рамките на изискванията за обработка на уязвимости: в често използван, машинночетим формат, обхващащ поне зависимостите от най-високо ниво. Като практическа препоръка улавяйте по-дълбока информация за зависимостите навсякъде, където инструментите ви за компилиране могат да дават надеждни резултати. Транзитивните зависимости често определят експозицията.

SBOM е полезен само когато съответства на реален артефакт на продукта. Свържете го с идентификатора на изданието и компилацията и разграничете доставените компоненти от инструментите, използвани само при разработка. Включете фърмуер, пакети на операционната система, вградени библиотеки и търговски компоненти, когато е релевантно; експорт от мениджъра на пакети може да пропусне няколко от тях.

Изградете прегледа на компонентите около въпроси, които променят инженерните решения:

• Поддържан ли е компонентът и съвместим ли е поддържаният му жизнен цикъл с нашия?
• Можем ли своевременно да получаваме информация за уязвимости и актуализации на сигурността?
• Имаме ли достъп до изходния код, път за кръпки от доставчика или стратегия за замяна?
• Въвежда ли компонентът привилегировано изпълнение или нова външна връзка?
• Може ли продуктът все още да бъде поддържан, ако доставчикът спре да поддържа компонента?

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

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

Проектирайте периода на поддръжка и механизма за актуализации заедно

Поддръжката е инженерен ангажимент с търговски последици. CRA по правило изисква период на поддръжка от поне пет години, освен ако очакваният период на използване на продукта е по-кратък. Определяйте приложимия период по критериите на регламента, вместо да избирате произволна дата, която да пасва на пътната карта.

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

Преди да одобрите плана за поддръжка на продукта, попитайте дали можете:

• Да компилирате отново по-стари поддържани клонове с поддържани инструменти.
• Да създавате, удостоверявате и разпространявате сигурно актуализации на сигурността.
• Да тествате поправките на поддържания хардуер и в поддържаните конфигурации за внедряване.
• Да поддържате ключовете за подписване и да се възстановите безопасно при компрометиране на ключ.
• Да поддържате наличната за клиентите информация за актуализации и сигурност.
• Да обработвате зависимости, чиято поддръжка нагоре по веригата приключва преди вашата.

Актуализациите на сигурността по правило трябва да се предоставят безплатно през периода на поддръжка, при спазване на разпоредбите на регламента. Всяка актуализация на сигурността, издадена през този период, трябва да остане налична поне десет години след издаването ѝ или за остатъка от периода на поддръжка, в зависимост от това кой срок е по-дълъг. Планирайте поправките на сигурността отделно от разработката на функции, за да не се налага клиентите ненужно да приемат несвързани функционални промени.

Тествайте повече от успешния сценарий. Прекъсната инсталация, недостатъчно място за съхранение, изтекли идентификационни данни и неуспешна проверка могат да превърнат валидна кръпка в проблем с наличността. Решете кои механизми за възстановяване са необходими за рисковия профил на продукта.

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

Изградете наръчник за докладване, който издържа на несигурност

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

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

За потенциално подлежащи на докладване събития съберете:

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

Проверете поетапните срокове за уведомяване, изискванията за окончателен доклад, получателите и актуалната процедура за докладване в официалните източници. Активно експлоатираните уязвимости и тежките инциденти имат различни подробности за докладване; едно копирано поле за срок не е достатъчно.

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

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

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

Потвърдете класификацията, преди да изберете плана за оценяване

Класификацията на продукта влияе върху наличния път за оценяване на съответствието. Не приемайте, че всеки свързан продукт се нуждае от една и съща външна оценка или че всеки производител може да разчита на вътрешна оценка.

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

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

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

Поддържайте класификацията, избрания път и резултатите по съответствието свързани с техническата документация. Маркировката CE и ЕС декларацията за съответствие трябва да следват приложимия процес; те не заместват внедряването на основните изисквания.

Поддържайте пакет с доказателства, който може да обясни едно издание

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

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

Използвайте стабилни идентификатори, за да свързвате тези записи. Записът за уязвимост трябва да обяснява засегнатите версии, експозицията, третирането, изданието и необходимата комуникация. „Поправено“ без контекст за версията оставя доказателствата за продукта непълни.

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

Практически пример: дефект в зависимост на поддържано устройство

Разгледайте илюстративен производител, който доставя свързано с мрежа устройство в ЕС. Да приемем, че обхватът и класификацията му са прегледани, два клона на изданията остават поддържани, а за вградена библиотека е съобщено, че се експлоатира активно другаде.

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

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

Инженерите разработват временна смекчаваща мярка и коригирана компилация за всеки засегнат клон. Тестовете обхващат уязвимия път, нормалната работа и инсталирането на удостоверената актуализация. Ако един клон не може да използва кръпката от доставчика нагоре по веригата, екипът записва алтернативното ѝ третиране и остатъчния риск, вместо да маркира целия продукт като поправен.

Комуникацията с клиентите идентифицира засегнатите версии, незабавните защитни действия и начина за получаване на актуализацията. Моментът на разкриване се координира с приложимите изисквания за обработка на уязвимости и всички обосновани съображения за сигурност.

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

Започнете с един продукт и една пълна верига от доказателства

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

Secani може да подпомогне този работен процес с доказателства, като свързва изисквания, доказателства, собственици, задачи и решения от прегледи. Инженерните инструменти остават оперативните източници за компилациите, изданията и уязвимостите; работното пространство за съответствие свързва тези записи с приложимото задължение. Поддържайте човешкото одобрение изрично за съпоставките и заключенията и запазвайте проследимостта до източниците при използване на чернови, подпомогнати от AI.

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