Приет през декември, Законът за кибер устойчивост на Европейския съюз (CRA) въвежда набор от задължителни изисквания за сигурност за всички търговски продукти с цифрови елементи. Идеята е да се защитят гражданите от зловредни хакери чрез подобряване на сигурността както на хардуера, така и на софтуера на тези продукти.
Помислете за всички актуализации на Android смартфони, които не се инсталират от потребителите.
За производителите, законодателството носи сериозни финансови наказания, както за нарушения на сигурността, които причиняват вреда на потребителите, така и за неспособността да се разкрият възможните уязвимости.
Ами какво ако тези продукти използват библиотеки с отворен код, и какво ако тези библиотеки бъдат открити като виновни?
За по-голямата част, разработчиците на отворен код няма да бъдат директно подчинени на CRA, освен ако активно не печелят пари от своя софтуерен продукт. Разпространителите на софтуер, като доставчиците на Linux, обаче, могат да бъдат обект на закона и най-вероятно ще трябва да засилят целия си жизнен цикъл на разработка на софтуер.
И въпреки че CRA не касае директно отделните разработчици на софтуер с отворен код, ако техните проекти бъдат използвани в търговски програми, те могат да бъдат помолени да подобрят своите практики за сигурност, отбеляза Кристофър Робинсън, главен архитект на OpenSSF, индустриален съюз, който цели да подобри сигурността на софтуера с отворен код.
Робинсън говори с TNS по време на Open Source Summit Северна Америка на Фондацията за Линукс за този въпрос. На конференцията много от участниците от САЩ изглеждаха, че не знаят много за CRA, докато европейските участници го познаваха отлично — и много от тях се тревожеха за въздействието, което той ще има, и за своите собствени проекти (и без съмнение ще свидетелстват за тази загриженост и следващата седмица на Open Source Summit ЕС).
Много скоро хората ще бъдат много силно отговорни за всяка една CVE [обща уязвимост] във софтуера, който доставят,“ каза Андрю Луис, технически продуктов мениджър в ReversingLab, малко драматично, по време на лекция на Open Source Summit NA. „Очакват ни наистина лоши дни.“
Другите обаче са по-оптимистични относно CRA, дори и ако законът ще изисква някои предварителни усилия.
По време на разговор на Open Source Summit NA, ръководителят на сигурността и поверителността в Red Hat, Роман Жуков, отбеляза, че CRA има потенциала най-накрая да реши много от проблемите със сигурността, които дълго време тормозеха отворения код.
„Сега имаме отличен натиск, подпомогнати от CRA, за да гарантираме, че най-накрая ще може да се оправи сигурността за тези проекти, които не са разглеждали това достатъчно сериозно“, каза той.
Законодателството беше прието през декември 2024 г. От 11 септември 2026 г. производителите ще бъдат отговорни за докладване на известни уязвимости и експлойти. И пълният закон ще влезе в сила през декември 2027 г.
Производител, Стюард или Участник?
Отвореният код все още се доминира от индивидуални разработчици, които управляват проекти предимно за сметка на своето собствено време. И ЕС опитва да ги остави на мира.
Както отбеляза Жуков в своята реч, отвореният код е „извън обхвата“ на регулациите на CRA като цяло. Но той казва, „дяволът е в детайлите“.
Има ситуации, в които отделен разработчик може да бъде изправен пред съдебната зала, отбеляза той: ако поддържа проект, който някой друг продава, или ако таксува за услуги, свързани със софтуера.
«Това е изключително нюансирано», съгласи Робинсън. Можеш да вземаш пари за твоя проект, за да покриеш разходите на проекта и дори разходите си за живот. Обаче, след като собственикът на проекта започне да печели, той започва да поема отговорност и ще трябва да засили практиките си за сигурност и отчетност.
Законът описва няколко различни роли, всяка с отделно правно задължение. Едната е производителят — или доставчикът — който носи основна правна отговорност за продукта. Има също така и управители, които са организации като OpenSSF или Фондация Linux. И накрая, има и сътрудници.
„Но накрая, ако вземате повече пари, отколкото властите смятат, че трябва, евентуално могат да ви преместят в категорията на производителите, и има потенциално много тежки наказания“, каза Робинсън.
Един производител има дълъг списък с задължения към ЕС. Точно както потребителските уреди имат сертификации от организации като Underwriters Laboratory, така и софтуерно-зависимите продукти на производителите ще идват с гаранции за безопасност.
Заради изискванията за съобщаване, производителите ще бъдат принудени да прилагат практики за разработка със сигурност по дизайн (ако все още не са го направили), развитие на жизнения цикъл на софтуера и управление на уязвимостите.
Отговорност и разходи
Ако злонамерен хакер пробие акаунт чрез уязвимост в софтуерната платформа на устройството и достъпи до банкова сметка или лични данни, производителят ще бъде държан отговорен.
Според регулациите, ако една компания е наясно, че един от продуктите ѝ е бил експлоатиран, тя трябва да предостави уведомление до комисията в рамките на 24 часа след откриването. Компанията трябва също така да предостави на потребителя или пач, или съвет, който подробно обяснява как най-добре да се защитава от атаката. Пълна кръпка трябва да бъде предоставена в рамките на три седмици, а също така трябва да бъде представен постмортем анализ.
За всяко нарушение, щетите могат да достигнат до 2.5% от общия глобален приход на производителя за същата година.
Има също и 1% санкция за неспазване на задължението да се предоставя вярна информация за уязвимост или за предоставяне на фалшива информация.
„Има много документация, която комисията ще поиска, като SBOMs [софтуерни билети на материали] и оценки на риска,“ каза Робинсън. Много текущи проекти не следват това ниво на отчетност, добави той. OpenSSF предлага безплатен виртуален клас с продължителност 90 минути, който цели да обучи разработчиците по закона (LFEL 1001).
Така че тези софтуерни разработчици, които предоставят библиотеки, добавки и приложения за цифрови компоненти, ще трябва да „подсилят сигурността си“, предполага се от самите производители, с допълнителна инженерна поддръжка.
Отворените източници на сигурност като OpenSSL и OpenSSH ще трябва да докладват за уязвимости по-бързо и да предоставят повече документация за тях.
„Зная, че комисията наистина би искала всички да управляват софтуера и продуктите си по същия начин, по който го правят автомобилните производители, просто заради множеството изисквания и фактът, че безопасността е най-важната грижа“, каза той.
За разпространителите
Комерсиално ориентираните разпространители на софтуер с отворен код като Red Hat и Canonical са в „странно положение“ във връзка с CRA, каза Робъртсън. Те могат да влязат в ролята както на производител, така и на стюард. Например, Red Hat е и двете, тъй като предлага Red Hat Enterprise Linux като услуга, но също така поддържа безплатната дистрибуция Fedora.
„Така че, в зависимост от проблема, те ще имат на разположение и двете роли“, каза Робинсън, използвайки каламбур. „Но предвид къде е проблемът, те ще носят една или друга шапка. Законът е много яснен, че можете да имате само една роля при даден инцидент — или сте производител, или сте стюард.“
Така че търговските дистрибутори като Red Hat ще трябва да инвестират, както много вече правят, в екипи от инженери, които работят на по-високи ниво, за да са сигурни, че софтуерните зависимости са подсигурени и документирани.
Попълването на някои от тези формуляри може да бъде ново за някои разработчици.
Производителите по-специално ще трябва да представят добре документирани оценки на риска и модели за заплахи, които описват как ще се използва продуктът, как може да бъде злоупотребено с него и какви действия са предприели за да смекчат тази конкретна заплаха.
„Повечето компании за софтуер нямат този вид стриктност и дисциплина в своята разработка, и ще трябва да я придобият, защото европейците ще поискат“, каза Робинсън.
За отделните разработчици, OpenSSF е предоставил основен списък от 41 практики, които трябва да изпълнят, за да запазят своите проекти сигурни, в основата за сигурността на проекти с открит код. Препоръките са разделени на три нива на зрялост. Ниво едно, индивидуалните разработчици трябва да могат „да се справят с минимални усилия“, каза Робинсън. Повечето от тях се отнасят до документация и конфигурация. Следващите нива са насочени към по-големи екипи.
Базовата основа се развива въз основа на други насоки за сигурност, като тези за PCI и HIPAA, където е приложимо, и голяма част от процесите по отчитане и дори отстраняване на проблеми могат да бъдат автоматизирани с времето.