24-часовой дедлайн по Закону о киберустойчивости (CRA) меняет уровень прозрачности цепочки поставок программного обеспечения

Согласно анализу, опубликованному изданием The Hacker News, производители продуктов с цифровыми элементами, продаваемых в Европейском союзе, столкнутся с дедлайном 11 сентября в рамках Закона о киберустойчивости (CRA). Он требует уведомлять регуляторов в течение 24 часов после получения сведений об активной эксплуатации уязвимости, а более подробный отчет должен быть предоставлен в течение 72 часов. Для руководителей производственных предприятий этот 24-часовой интервал может привлечь повышенное внимание к прозрачности цепочки поставок программного обеспечения. Сложные продукты могут содержать проприетарное ПО, приложения от сторонних разработчиков, коммерческие пакеты, ПО для микроконтроллеров и открытые библиотеки, причем зависимости распространяются на несколько уровней вглубь. Производитель может поддерживать многочисленные отношения с поставщиками, обладая при этом лишь ограниченным пониманием того, какое именно программное обеспечение встроено в отдельные компоненты.

Согласно CRA, соответствующий продукт может охватывать всё изделие целиком, что создает необходимость объединять информацию от многочисленных поставщиков в единую и согласованную опись программного обеспечения. Производители автомобилей, медицинского оборудования, аэрокосмической техники и бытовой электроники могут столкнуться с особенно сложными проявлениями этой проблемы.

Спецификации состава программного обеспечения (Software Bills of Materials, или SBOM) служат важной основой для упорядочения этой информации. По данным IBM, SBOM представляет собой машиночитаемый перечень программных компонентов, библиотек, модулей и зависимостей, помогая организациям понимать, какое ПО входит в состав продуктов и систем. В IBM также отмечают более широкое внедрение практик SBOM в различных секторах по мере ужесточения нормативных требований и роста озабоченности состоянием цепочек поставок ПО. Однако для крупных производителей файлы от поставщиков могут поступать в разных форматах и с разной степенью детализации. В результате набор таких документов становится трудно привести к единому знаменателю на уровне готового продукта, особенно если лежащее в основе ПО меняется уже после создания SBOM.

Это различие может приобрести особое значение, когда вопросы отчетности об уязвимостях критичны ко времени. В анализе CRA от The Hacker News утверждается, что организациям будет сложнее всего выполнить требование от 11 сентября в тех случаях, когда они не могут быстро установить, какое именно ПО присутствует в конкретном продукте или когда именно уязвимость была обнаружена впервые. Электронная таблица или архив электронной почты могут зафиксировать состав ПО в определенный момент времени, в то время как последующие релизы, патчи, изменение зависимостей или вновь выявленные компоненты могут изменить общую картину.

Именно в таких условиях развивает свою деятельность FossID — компания по анализу состава программного обеспечения, специализирующаяся на разведке исходного кода и прозрачности цепочки поставок ПО. Директор по развитию бизнеса (Chief Growth Officer) Аарон Брэнсон рассматривает лежащую в основе проблему сквозь призму надежности информации, поступающей к производителям. «SBOM полезна ровно настолько, насколько организация уверена в содержащейся в ней информации,» — заявляет он. «Для компаний, получающих ПО от многочисленных поставщиков, эта уверенность требует дополнительного уровня проверки в той точке, где информация от поставщика попадает на предприятие.»

Анализ исходного кода призван обеспечить этот уровень за счет изучения самого программного обеспечения с целью выявления компонентов, зависимостей, лицензий и уязвимостей. Технология FossID позволяет сканировать код и идентифицировать компоненты с открытым исходным кодом и сторонние компоненты, включая более мелкие фрагменты кода и зависимости, которые сложно обнаружить только на основе заявленных сведений о пакетах. По словам Брэнсона, это создает важное различие между простым получением SBOM и проверкой того, насколько эта SBOM соответствует реальному программному обеспечению.

Отношения с поставщиками могут добавить еще один уровень сложности к задаче обеспечения видимости. Для крупных производителей полезность SBOM может отчасти зависеть от того, можно ли последовательно оценивать информацию от разных поставщиков и сводить ее в единый реестр. Это область, в которой анализ состава программного обеспечения может сыграть более весомую роль. Информация, предоставленная поставщиком, может быть сопоставлена с самим ПО, что помогает отделить формально поданный документ от информации, прошедшей достаточную валидацию.

Брэнсон утверждает, что это различие может приобретать все большую важность по мере того, как ответственность перед регуляторами распространяется на сложные цепочки программных зависимостей. Работа FossID является частью более масштабных усилий по повышению практической пригодности данных о программном обеспечении поставщиков для инженерных команд, специалистов по безопасности и отделам комплаенса, отвечающим за готовый продукт.

Сложность может возрастать, когда ПО поставщика содержит зависимости от других вендоров и проектов с открытым исходным кодом. Производитель может получить информацию о компоненте, не имея при этом аналогичного уровня видимости в отношении программного обеспечения, находящегося под ним. Это порождает более масштабный вопрос о том, как производители могут обрести уверенность в информации о ПО, которая поступает извне, за пределами их собственных инженерных команд.

«Наша работа в области анализа исходного кода имеет отношение к этому вопросу, поскольку она исследует состав ПО на уровне кода, предоставляя еще один инструмент для оценки информации, поставляемой через более широкую экосистему,» — поясняет Брэнсон. «Но более масштабная проблема заключается в том, что производителям могут потребоваться процессы, позволяющие верифицировать информацию о ПО на нескольких уровнях ответственности.» По словам Брэнсона, FossID обсуждала эту общую проблему с отраслевыми аналитиками по мере того, как организации переходят от простого создания SBOM к их интеграции в непрерывные процессы управления цепочкой поставок программного обеспечения.

Кэти Нортон (Katie Norton), старший менеджер по исследованиям в IDC, считает гибкость важной частью этого перехода. «По мере того как предприятия внедряют SBOM в операционную деятельность, им нужны процессы, способные учитывать различия между поставщиками, нормативными требованиями и внутренними процедурами проверки,» — отмечает Нортон. «Задача заключается в том, чтобы поддерживать эти вариации, не навязывая один и тому же рабочий процесс каждой организации.»

Брэнсон видит в этом изменение самой сути управления SBOM. «Вопрос меняется: от «Есть ли у нас SBOM?» до «Можем ли мы непрерывно верифицировать цепочку поставок ПО, которую представляет собой эта SBOM?»» — заявляет он. Такой подход переводит анализ состава программного обеспечения в разряд более широких операционных процессов, затрагивающих инженерные, охранные, закупочные и регуляторные подразделения. SBOM может служить учетной записью, в то время как анализ исходного кода выступает средством проверки этой записи на соответствие программному обеспечению, из которого она была получена.

В конечном счете требование от 11 сентября может стать ранней вехой в более масштабной эволюции управления программным обеспечением (software governance). The Hacker News отмечает, что обязательства по отчетности в рамках CRA вступают в силу раньше более широких инженерных требований регулятора, которые запланированы к применению в декабре 2027 года. Такая последовательность может дать производителям возможность проверить системы, обеспечивающие выявление уязвимостей, сбор информации о поставщиках и видимость ПО на уровне продуктов.

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