Решение кризиса SBOM с помощью компонентов WebAssembly

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

SBOM: Признание стоимости бесплатного

Мы все знакомы с печально известными уязвимостями, такими как уязвимость Log4shell в Log4j. Чтобы представить ущерб, который он нанес в контексте, операции были остановлены в 40% глобальных компаний, когда брешь в системе безопасности позволила киберпреступникам заразить критически важные системы одной дозой вредоносного кода. Учитывая, что средняя стоимость устранения одной уязвимости Log4j составляет, по данным IBM, 4,62 миллиона долларов, а для ее устранения требуется 12% операционных ресурсов, последствия огромны.

Несмотря на общеотраслевые усилия по разработке политик, методов, инструментов и обучения безопасности с открытым исходным кодом, возглавляемые Open Source Software Security Foundation (OpenSSF), исследования показывают, что более 70% компаний остаются уязвимыми для Log4shell. Это показывает, насколько распространенными и трудно искоренимыми могут быть уязвимости.

Даже в «нормальном» рабочем состоянии разработчики раздавлены требованиями соответствия и операционными трудностями разработки приложений. Недавнее внутреннее исследование Deloitte показало, что разработчики тратят 80% своего времени на управление операциями и обслуживанием приложений. И что они поддерживают? Общий открытый исходный код, который составляет 95% или более типичного приложения. Хотя загрузка наших приложений с помощью библиотек с открытым исходным кодом ускоряет и упрощает разработку приложений, это происходит за счет поддержки этих компонентов.

Новые вычисления не застрахованы

Новые парадигмы вычислений — например, контейнеры — не застрахованы. Отчет Sysdig о безопасности и использовании Cloud-Native за 2023 год показывает, что отсутствие надлежащих политик безопасности способствует росту числа уязвимостей, связанных с неправильной конфигурацией. В отчете утверждается, что 87 % образов контейнеров, работающих в рабочей среде, имеют критические уязвимости или уязвимости высокой степени серьезности. увеличивать на прошлый год.

Даже в Rust (язык, ориентированный на безопасность) есть уязвимости в популярных библиотеках, таких как Hyper, который лежит в основе множества фреймворков Rust. Согласно JFrog, 2579 проектов, перечисленных в репозитории пакетов Rust, crates.io, зависят от Hyper, который был загружен через 67 миллионов раз. Уязвимость Hyper преобразует входящее тело HTTP в множество байтов, что приводит к сбою микросервисов и приложений. Как разработчики, мы могли бы совершенно не знать об этом. Если один и тот же код выполняется в 20 000 приложений, для предприятий это становится логистическим кошмаром, когда приходится поддерживать его в масштабе.

NFRs, неудобная правда

90 % всех унаследованных уязвимостей находятся в нефункциональных требованиях (NFR), которые, в свою очередь, составляют 95 % содержимого большинства приложений. NFR — это набор спецификаций, определяющих рабочие возможности, атрибуты и ограничения приложения. Их иногда называют «шаблонным» кодом — стандартным материалом, который импортируется снова и снова. Проблема в том, что приложения наследуют уязвимости своих импортированных библиотек.

NFR также являются огромной тратой ресурсов. Организации тратят от 60% до 70% времени разработки на обслуживание и эксплуатацию приложений, а на предоставление основных функций времени не хватает. По мере того, как современные предприятия становятся все более распределенными — подумайте о мобильных устройствах, нативных веб-приложениях, нескольких облаках и периферийных устройствах, — мы реорганизуем приложения, чтобы они работали дальше от ядра (где находятся данные и пользователи). По мере того, как мы обслуживаем и внедряем эти новые платформы, мы объединяем нашу существующую бизнес-логику с большим количеством NFR, и наше бремя NFR продолжает расти.

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

Хотя некоторые уязвимости можно систематически исправлять, большинство из них поддерживается отдельно для каждого приложения. Какое решение? Мы не можем вернуться и переписать каждую библиотеку. Ответ заключается в том, чтобы найти способ полностью абстрагировать NFR от опыта разработки. Если мы уменьшим тесную связь конкретных NFR с конкретными приложениями, мы упростим управление уязвимостями. Компонентная модель WebAssembly (Wasm) предназначена именно для этого.

Абстрагирование уязвимостей с помощью WebAssembly

космический

За последние 20 лет мы стали свидетелями восходящих инноваций, которые сняли большую часть бремени обслуживания приложений с конкретных приложений. Исторически сложилось так, что приложения разрабатывались и создавались вместе с аппаратным обеспечением — определенным именованным сервером в стойке. Постепенно мы продолжаем абстрагироваться от этих нижележащих слоев, избавляясь от сложности, удаляя и объединяя задачи, традиционно выполняемые для каждого отдельного приложения. У нас есть модульные виртуальные машины, центры обработки данных, операционные системы и платформы для оркестровки.

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

Жизнь корпоративных разработчиков полна разочаровывающих задач соответствия. Поддержание прикладного уровня в приложении за приложением — огромная нагрузка. WebAssembly, наконец, приносит столь необходимое облегчение разработчикам, которые борются с постоянными сложностями обслуживания приложений. Ознакомьтесь с недавней записью в блоге Кевина Хоффмана о вычислениях с нулевым доверием в Wasm и wasmCloud, чтобы узнать больше.

Наконец, компонентная модель WebAssembly приносит облегчение разработчикам, предоставляя абстракции для общих NFR — веб-серверов, баз данных, ведения журналов и очередей сообщений. Вместо того, чтобы встраиваться в каждое приложение во время компиляции, самая последняя версия этих абстракций может быть подключена во время выполнения. Эта простая абстракция переносит огромный объем текущего обслуживания на платформу, где ее можно автоматизировать.

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

Это огромный шаг вперед по сравнению с ручными процессами, которые мы используем сегодня в обслуживании. Посмотрите, как Брукс Таунсенд и Бэйли Хейс описывают, как wasmCloud и платформа Cosmonic устраняют уязвимости на уровне компонентов.

Доработка модели компонентов WebAssembly

Контейнеры открыли возможность разделить монолит на микросервисы, чтобы мы могли работать с отдельным микросервисом, не затрагивая все остальное. Wasm выводит эту модель на новый уровень, разделяя приложение на отдельные компоненты. Компонентная модель — это реальный метод извлечения, изменения и рефакторинга отдельных компонентов в приложении без воздействия на остальные компоненты вокруг него.

Почему это важно? Компонентная модель устранит сильно связанные NFR там, где обычно находятся уязвимости, устраняя тесную связь приложений с конкретными приложениями. В своей недавней статье для InfoWorld Бейли Хейс (директор технического руководящего комитета Bytecode Alliance и Cosmonic) описывает мир, в котором разработчики могут «выбирать части своего приложения, реализованные на разных языках, в качестве различных ценностных предложений». По мере того, как библиотеки компонентов Wasm начнут обретать форму, разработчики всех видов увидят в них самый большой в мире ящик «Лего».

То, что остается, — это небольшие фрагменты бизнес-логики, которые не страдают от встроенных уязвимостей, которые мы обычно находим в огромном количестве кода, лежащего в основе большинства приложений. Ценность для разработчиков в том, что они пишут только верно кода, а приложения становятся на 95 % меньше, чем ранние облачные приложения, что приводит к уменьшению на 95 % унаследованных уязвимостей.

CNCF wasmCloud — первая среда выполнения приложений, поддерживающая компонентную модель WebAssembly. Он предлагает своего рода подход Zero Trust, безопасный по умолчанию, который позволяет устранить уязвимости цепочки поставок и оставить эту распространенную проблему в истории.

Лиам Рэндалл — генеральный директор Cosmonic и председатель CNCF Cloud Native Wasm Day.

—

New Tech Forum представляет собой площадку для изучения и обсуждения новых корпоративных технологий с беспрецедентной глубиной и широтой. Выбор субъективен и основан на выборе технологий, которые мы считаем важными и представляющими наибольший интерес для читателей InfoWorld. InfoWorld не принимает маркетинговые материалы для публикации и оставляет за собой право редактировать весь предоставленный контент. Присылайте все запросы на newtechforum@infoworld.com.