Принятый в декабре, Закон о кибер -устойчивости Европейского Союза (CRA) представляет ряд обязательных требований безопасности для всех коммерческих продуктов с цифровыми элементами. Идея состоит в том, чтобы защитить граждан от злонамеренных хакеров, улучшая безопасность как оборудования, так и программного обеспечения этих продуктов.
Подумайте обо всех смартфонах Android, не обновленных.
Для производителей законодательство имеет некоторые довольно серьезные финансовые штрафы, как за нарушения безопасности, которые причиняют вред потребителям, так и за неспособность раскрывать возможные уязвимости.
Но что, если эти продукты используют библиотеки с открытым исходным кодом, и что, если эти библиотеки найдены в вину?
По большей части, разработчики с открытым исходным кодом не будут напрямую подвергаться CRA, если они не будут активно зарабатывать деньги на своем программном обеспечении. Однако дистрибьюторы программного обеспечения, такие как поставщики Linux, могут подчиняться закону, и, скорее всего, потребуется укреплять все жизненные циклы разработки программного обеспечения.
И хотя CRA не касается отдельных разработчиков с открытым исходным кодом напрямую, если их проекты используются в коммерческих торговых точках, их можно попросить ускорить их практику безопасности, отметил, что Кристофер Робинсон, главный архитектор OpenSSF, отраслевой консорциум, который направлен на повышение безопасности программного обеспечения с открытым исходным кодом.
Робинсон поговорил с TNS на саммите с открытым исходным кодом Linux в Северной Америке по этому вопросу. На конференции многие из участников сша, похоже, мало что знали о CRA, хотя европейские участники знали об этом — и многие беспокоились о том, какое влияние он оказал, и их собственные проекты (и, без сомнения, мы станем свидетелями этой проблемы на следующей неделе на Summit Eu Open Source).
«Довольно скоро люди будут нести ужасную ответственность за каждый CVE [common vulnerability and exposure] В программном обеспечении, которое они отправляют, — сказал Энди Льюис из ReversingLabs, несколько резко, в разговоре на саммите с открытым исходным кодом. «Наступают действительно действительно плохие дни».
Другие, однако, более оптимистичны в отношении CRA, даже если закон потребует некоторой авансовой работы.
Во время выступления на саммите с открытым исходным кодом, лидер безопасности и конфиденциальности Red Hat Роман Чжуков отметил, что CRA может наконец -то исправить многие проблемы безопасности, которые давно преследуют открытый исходный код.
«Теперь у нас есть отличный импульс, основанный на CRA, чтобы убедиться, что мы наконец -то сможем исправить безопасность для тех проектов, которые не изучали его должным образом», — сказал он.
Законодательство было принято в декабре 2024 года. Начиная с 11 сентября 2026 года, производители будут отвечать за сообщения о известных уязвимости и эксплуатации. И полный закон принимается в декабре 2027 года.
Производитель, стюард или участник?
В открытом исходном коде все еще доминируют отдельные разработчики, которые управляют проектами в основном в свое время. И ЕС пытался оставить их в покое.
Как отметил Чжуков в своем выступлении, открытый исходный код «не в целом» из правил CRA в целом. Но он говорит: «Дьявол в деталях».
Существуют сценарии, когда отдельный разработчик может быть введен в зал суда, он отметил: если они поддерживают проект, который кто -то другой продает, или если они взимают за услуги, связанные с программным обеспечением.
«Это супер нюансы», — согласился Робинсон. Вы можете взять деньги на свой проект, чтобы покрыть расходы и даже расходы на проживание. Однако, как только владелец проекта получает прибыль, он начнет брать на себя ответственность и потребуется увеличить свои процессы отчетности.
Закон описывает несколько разных ролей, каждая с отдельным юридическим обязательством. Одним из них является производитель — или поставщик, который в первую очередь ответственен за продукт. Есть также стюарды, которые являются такими организациями, как OpenSSF или Foundation Linux. И, наконец, есть участники.
«Но в конце концов, если вы возьмете больше денег, чем они думаете, они должны, они потенциально могут подтолкнуть вас к категории производителей, и потенциально будут очень резкие штрафы», — сказал Робинсон.
Производитель имеет длинный список обязательств перед ЕС. Точно так же, как потребительские приборы имеют сертификаты от лаборатории андеррайтеров, то же самое и программные продукты производители будут поставляться с гарантиями безопасности.
Из-за требований к отчетности производители будут вынуждены принять (если они еще этого не сделали) безопасные методы разработки, разработку программного обеспечения и практику управления уязвимостью.
Ответственность CRA для разработчиков, от разговора Романа Жукова.
Затраты на ответственность
Если злонамеренный хакер нарушает учетную запись благодаря уязвимости в программном стеке устройства и попадает в банковский счет или некоторые персональные данные, то производитель будет нести ответственность.
Согласно REGS, если компания знает, что одна из ее продуктов эксплуатируется, то она должна предоставить уведомление об комиссии в течение 24 часов после выяснения. Компания также должна предоставить пользователю либо исправление, либо консультативное подробное описание того, как лучше всего защитить себя от атаки. Полное исправление должно быть предоставлено в течение трех недель, а также должна быть предоставлена посмертная среда.
Для каждого нарушения ущерб может составлять до 2,5% от общего глобального дохода производителя за этот год.
Существует также штраф в 1% за то, что он не давал или раздал ложную информацию о уязвимости.
«Есть много документации, о которых просит Комиссия, например, SBOMS [software bills of materials] и оценки рисков », и многие текущие проекты не соответствуют этому уровню отчетности, сказал Робинсон. У OpenSSF есть бесплатный 90-минутный виртуальный класс, чтобы обучать разработчиков закону (LFEL 1001).
Таким образом, тем разработчикам программного обеспечения, которые предоставляют библиотеки, утилиты и приложения для цифровых компонентов, должны будут «получить повышение безопасности», предположительно, от самих производителей, с дополнительной инженерной поддержкой.
Проекты безопасности с открытым исходным кодом, такие как OpenSSL и OpenSSH, должны будут быстрее сообщать об уязвимости и предоставлять больше документации о них.
«Я знаю, что комиссии действительно понравится, если бы все управляют своим программным обеспечением, и их продукты, такие как производители автомобилей, просто потому, что существует так много требований, а безопасность — главная проблема», — сказал он.
Ответственность CRA для разработчиков, от разговора Романа Жукова.
О дистрибьюторах
По словам Робертсона, коммерчески ориентированные на коммерческие дистрибьюторы программного обеспечения с открытым исходным кодом, такие как Red Hat и Canonical, находятся в «странном месте» по отношению к CRA. Они могут попасть в роль либо производителя, либо стюарда. Например, Red Hat является оба, потому что она предлагает Red Hat Enterprise Linux в качестве услуги, но также поддерживает некоммерческое сообщество Fedora.
«Таким образом, в зависимости от того, в чем проблема, у них будет обе шляпы», — сказал Робинсон, уделяя каламбур. «Но, учитывая, где проблема, они будут носить один или другой. Закон очень ясно, что вы можете сыграть только одну роль в данном инциденте, поскольку вы либо производители, либо вы стюард».
Таким образом, коммерческим дистрибьюторам, таким как Red Hat, должны будут инвестировать, как это делали многие, в команды инженеров для работы вверх по течению, гарантируя обеспечение и документирование зависимостей.
Заполнение некоторых из этих форм может быть новым для некоторых разработчиков.
В частности, производителям потребуются хорошо документированные оценки риска и модели угроз, которые описывают, как будет использоваться продукт, как его можно использовать, и какие действия они предприняли для смягчения этой конкретной угрозы.
«Большинство [software] Компании не имеют такой строгости и дисциплины в разработке своего программного обеспечения, и им понадобится ее, потому что европейцы спросят », — сказал Робинсон.
Для отдельных разработчиков OpenSSF предоставил базовый список из 41 практики, которые им необходимы, чтобы обеспечить безопасность своих проектов в базовой линии безопасности проекта с открытым исходным кодом. Рекомендации разделены на три уровня зрелости. Первый уровень, отдельные разработчики должны «способны справиться с минимальным количеством усилий», сказал Робинсон. В основном это документация и конфигурация. Последующие уровни направлены на более крупные команды.
Базовая линия состоит из других руководящих принципов безопасности, например, для PCI и HIPAA, где это соответствует, а большая часть отчетности и даже процессов восстановления может быть автоматизирована с течением времени.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Joab Jackson является старшим редактором нового стека, охватывающего облачные нативные вычисления и системы системы. Он сообщил об инфраструктуре и развитии ИТ в течение более 30 лет, в том числе в IDG и государственных компьютерных новостях. До этого он … читал больше от Джоаба Джексона
