Срок в 24 часа для CRA меняет видимость цепочки поставок программного обеспечения

      TL;DRС 11 сентября Законодательство ЕС о киберустойчивости потребует от производителей уведомлять регулирующие органы в течение 24 часов после того, как они узнают, что уязвимость в их продукте активно эксплуатируется. Для компаний, чьи продукты содержат программное обеспечение от нескольких поставщиков, узким местом является не наличие SBOM, а знание о том, точно ли он отражает исходный код. Аарон Брансон из FossID утверждает, что анализ исходного кода предоставляет уровень проверки, который превращает документы SBOM в надежную информацию о цепочке поставок. Согласно анализу, опубликованному The Hacker News, производители продуктов с цифровыми элементами, продаваемых в Европейском Союзе, столкнутся с дедлайном 11 сентября по Закону о киберустойчивости (CRA), чтобы уведомить регулирующие органы в течение 24 часов после того, как они узнают, что уязвимость активно эксплуатируется, с более полным отчетом, ожидаемым в течение 72 часов. Для руководителей производств 24-часовое окно может привлечь больше внимания к видимости цепочки поставок программного обеспечения. Сложные продукты могут содержать проприетарное программное обеспечение, приложения, разработанные поставщиками, коммерческие пакеты, программное обеспечение микроконтроллеров и библиотеки с открытым исходным кодом, с зависимостями, охватывающими несколько уровней. Производитель может поддерживать множество отношений с поставщиками, имея при этом ограниченное представление о программном обеспечении, встроенном в отдельные компоненты. В соответствии с CRA соответствующий продукт может охватывать полный готовый продукт, создавая необходимость соединить информацию от многочисленных поставщиков в единый инвентарь программного обеспечения. Производители автомобилей, медицинских устройств, аэрокосмической и потребительской электроники могут столкнуться с особенно сложными версиями этой проблемы. Счета материалов программного обеспечения, или SBOM, предоставляют важную основу для организации этой информации. Согласно IBM, SBOM предоставляет читаемый машиной инвентарь компонентов программного обеспечения, библиотек, модулей и зависимостей, помогая организациям понять программное обеспечение, включенное в продукты и системы. IBM также описывает более широкое принятие практик SBOM в различных секторах, поскольку требования регуляторов и проблемы цепочки поставок программного обеспечения расширились. Однако для крупных производителей файлы поставщиков могут поступать в разных форматах и с различными уровнями детализации. Таким образом, набор документов может стать трудным для согласования на уровне продукта, особенно когда основное программное обеспечение изменяется после того, как SBOM был произведен. Это различие может стать особенно важным, когда отчетность по уязвимостям является временно чувствительной. Анализ The Hacker News по CRA утверждает, что организациям может быть сложнее всего выполнить требование 11 сентября, когда они не могут быстро установить, какое программное обеспечение присутствует в конкретном продукте или когда уязвимость впервые стала известна. Электронная таблица или архив электронной почты могут документировать состав программного обеспечения в определенный момент, в то время как последующие релизы, патчи, изменения зависимостей или вновь выявленные компоненты могут изменить картину. Кредит: Аарон Брансон Это та среда, в которой FossID, компания по анализу состава программного обеспечения, сосредоточенная на интеллекте исходного кода и прозрачности цепочки поставок программного обеспечения, развила свою роль. Директор по росту Аарон Брансон рассматривает основную проблему через надежность информации, поступающей к производителям. «SBOM полезен только в той мере, в какой организация может доверять информации внутри него», - утверждает он. «Для компаний, получающих программное обеспечение от многочисленных поставщиков, это доверие требует дополнительного уровня проверки в точке, где информация от поставщика попадает в предприятие». Анализ исходного кода направлен на предоставление этого уровня, исследуя само программное обеспечение, чтобы идентифицировать компоненты, зависимости, лицензии и уязвимости. Технология FossID может сканировать код и идентифицировать компоненты с открытым исходным кодом и сторонние компоненты, включая более мелкие фрагменты кода и зависимости, которые могут быть трудны для установления только на основе заявленной информации о пакете. По словам Брансона, это создает важное различие между получением SBOM и проверкой того, соответствует ли SBOM основному программному обеспечению. Отношения с поставщиками могут добавить еще один уровень к проблеме видимости. Для крупных производителей полезность SBOM может частично зависеть от того, может ли информация от разных поставщиков быть оценена последовательно и объединена в общий реестр. Это область, где анализ состава программного обеспечения может сыграть более широкую роль. Информация, предоставленная поставщиком, может быть проверена по сравнению с самим программным обеспечением, что помогает отличить документ, который был представлен, от информации, которая была достаточно проверена. Брансон утверждает, что это различие может стать все более важным, поскольку регуляторная ответственность охватывает сложные цепочки зависимостей программного обеспечения. Работа FossID находится в рамках более широких усилий по улучшению использования информации о программном обеспечении поставщиков для инженерных, безопасностных и комплаенс-команд, ответственных за готовый продукт. Сложность может увеличиваться, когда программное обеспечение поставщика содержит зависимости от дополнительных поставщиков и проектов с открытым исходным кодом. Производитель может получать информацию о компоненте, не имея того же уровня видимости в программное обеспечение под ним. Это может создать более широкий вопрос о том, как производители могут установить доверие к информации о программном обеспечении, которая поступает извне их собственных инженерных команд. «Наша работа в области анализа исходного кода имеет отношение к этому вопросу, потому что она исследует состав программного обеспечения на уровне кода, предоставляя еще один способ оценки информации, предоставленной через более широкую экосистему», - объясняет Брансон. «Но более крупная проблема заключается в том, что производителям могут понадобиться процессы, которые позволят проверять информацию о программном обеспечении через несколько уровней ответственности». По словам Брансона, FossID обсуждала эту более широкую проблему с отраслевыми аналитиками, поскольку организации переходят от простого создания SBOM к их интеграции в текущие процессы цепочки поставок программного обеспечения. Кэти Нортон, старший менеджер по исследованиям в IDC, считает гибкость важной частью этого перехода. «Когда предприятия начинают использовать SBOM, им нужны процессы, которые могут учитывать различия в поставщиках, требованиях регуляторов и внутреннем обзоре», - утверждает Нортон. «Проблема заключается в поддержке этих вариаций, не накладывая один и тот же рабочий процесс на каждую организацию». Брансон рассматривает это как изменение в самой цели управления SBOM. «Вопрос смещается от ‘Есть ли у нас SBOM?’ к ‘Можем ли мы постоянно проверять цепочку поставок программного обеспечения, которую представляет SBOM?’», - утверждает он. Это различие помещает анализ состава программного обеспечения в более широкий операционный процесс, включающий инженерные, безопасностные, закупочные и регуляторные команды. SBOM может служить в качестве записи, в то время как анализ исходного кода может предоставить способ проверки этой записи по сравнению с программным обеспечением, из которого она была получена. В конечном итоге требование 11 сентября может представлять собой ранний этап в более широкой эволюции управления программным обеспечением. The Hacker News отмечает, что обязательства по отчетности CRA приходят до более широких инженерных требований регулирования, которые должны вступить в силу в декабре 2027 года. Эта последовательность может дать производителям возможность изучить системы, поддерживающие идентификацию уязвимостей, информацию о поставщиках и видимость программного обеспечения на уровне продукта. Поскольку подключенные продукты включают программное обеспечение из все более сложных цепочек поставок, готовность к регулированию может все больше зависеть от качества и актуальности информации, стоящей за инвентарем программного обеспечения организации. Появляющаяся проблема может заключаться в том, чтобы поддерживать надежное понимание программного обеспечения, которое остается связанным с продуктом на протяжении всего его жизненного цикла.