Срок в 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 года. Эта последовательность может дать производителям возможность изучить системы, поддерживающие идентификацию уязвимостей, информацию о поставщиках и видимость программного обеспечения на уровне продукта. Поскольку подключенные продукты включают программное обеспечение из все более сложных цепочек поставок, готовность к регулированию может все больше зависеть от качества и актуальности информации, стоящей за инвентарем программного обеспечения организации. Появляющаяся проблема может заключаться в том, чтобы поддерживать надежное понимание программного обеспечения, которое остается связанным с продуктом на протяжении всего его жизненного цикла.