У открытого исходного кода нет проблем с безопасностью. У него есть проблемы с распространением. Известный пресвитерианский священник и писатель Фрэнк Крейн говорил: “Вы можете быть обмануты, если будете доверять слишком сильно, но вы будете жить в муках, если будете доверять недостаточно”. Это, конечно, сказано не об открытом коде. Но это отличный способ подвести итог сегодняшнему разрыву между тем, как на самом деле используется открытый исходный код, и шаблонами нулевого доверия, которые предприятия пытаются кодифицировать в своей практике DevSecOps.

Каждое исследование, которое я вижу, предполагает, что от 90% до 98% программного обеспечения в мире имеет открытый исходный код. Мы все берем код, написанный другими людьми — стоим на плечах гигантов — и создаем и модифицируем весь этот код, безоговорочно доверяя каждому автору, сопровождающему и соавтору, который был до нас. Еще до того, как мы начнем писать наш код, мы верим, что базовый открытый исходный код был написан надежно. Затем, когда мы его используем, мы верим, что авторы не были злонамеренными, и что код не был изменен до того, как мы его установили. Это противоположность нулевому доверию. Это максимальное доверие.

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

Программное обеспечение с открытым исходным кодом безопасно

В первые дни критики открытого исходного кода вызывали много страха, неуверенности и сомнений в его безопасности. Их аргумент заключался в том, что исходный код проприетарного программного обеспечения защищен от посторонних глаз и, следовательно, более безопасен, чем открытый исходный код, который был легко доступен любому. Но открытый исходный код доказал, что прозрачность исходного кода дает положительный эффект. Сетевой эффект "много глаз " быстрее выявляет уязвимости и создает гораздо более быстрые циклы исправления. Результаты говорят сами за себя: 90% известных эксплуатируемых уязвимостей (в списке CVE, который ведет CISA) являются проприетарным программным обеспечением, несмотря на тот факт, что около 97% всего программного обеспечения имеет открытый исходный код.

При наличии серьезной уязвимости слишком легко подорвать общее состояние безопасности с открытым исходным кодом. На самом деле, многие из этих наиболее известных уязвимостей демонстрируют мощь безопасности с открытым исходным кодом. Log4shell, например, был наихудшим сценарием для уязвимости OSS по масштабу и уровню видимости - это была одна из наиболее широко используемых библиотек на одном из наиболее широко используемых языков программирования. Log4j был запущен даже на марсоходе. Технически это была первая межгалактическая уязвимость OSS! Уязвимость Log4shell была простой в использовании, невероятно распространенной и имела серьезные последствия. Разработчики смогли ее исправить и заменить везде в считанные дни. Это была крупная победа для системы безопасности с открытым исходным кодом на уровне поддержки, а не провал.

И это достижение должно быть широко признано. Сравните это время раскрытия информации и исправления, составляющее пару дней, с программами раскрытия информации производителей встроенного ПО или облачных провайдеров, которым в лучшем случае требуется 30, 60, даже 90 дней, чтобы внедрить исправления для чего-то подобного. Однако предприятия запаздывают с принятием необходимых мер по устранению уязвимости. Согласно недавнему отчету Veracode, более чем каждое третье, или 38%, приложений, работающих под управлением Log4j, по-прежнему используют уязвимые версии программы.

Но открытый исходный код требует доверия

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

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

Инструменты развертывания OSS переросли модели доверия

Но сегодня большая часть потребления программного обеспечения происходит вне дистрибутивов. Сами менеджеры пакетов на языках программирования — npm (JavaScript), pip (Python), Ruby Gems (Ruby), composer (PHP) — выглядят и ощущаются как менеджеры пакетов дистрибутива Linux, но работают немного по-другому. По сути, они предлагают нулевое курирование — любой может загрузить пакет и имитировать разработчика языка. И как вы узнаете, чему вы доверяете, когда при установке одного пакета часто устанавливаются пакеты от десятков других случайных людей в Интернете?

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

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

Однако Docker - не единственный игрок в этой сети доверия к облачному программному обеспечению; все становится сложнее. Поверх Docker есть слой, который обычно используется в среде Kubernetes. Helm позволяет упаковать множество образов Docker и конфигураций. Это пакет из пакетов. Так что, если вы, например, установите Helm chart для Prometheus, вы, скорее всего, также получите кучу других изображений из случайных личных проектов. Вы можете быть уверены, что получаете Prometheus от сопровождающих Prometheus, потому что artifact hub показывает, что он пришел от проверенного издателя, но Prometheus часто имеет зависимости, которые исходят не от проверенных издателей.

Официальный репозиторий Helm Charts, поддерживаемый первоначальными создателями Helm, был продуманной попыткой кодифицировать доверие к этим изображениям. У него был потенциал привнести в облачные нативные приложения тот же тип контроля безопасности, который предоставляется дистрибутивами Linux. Но, к сожалению, это оказалось слишком сложно масштабировать, и потребовалась более федеративная модель, такая как менеджеры пакетов языка программирования, где каждый проект поддерживает свои собственные диаграммы управления.

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

Обеспечение безопасности программного обеспечения с самого начала

Распространение программного обеспечения кардинально отличается от того, что было 20 лет назад, когда вы покупали программное обеспечение в термоусадочной упаковке в таких магазинах, как CompUSA или Best Buy. Когда вы покупали коробку с программным обеспечением, вы точно знали, что получаете. Вы знали, что оно пришло от того, кому предназначалось, и что в него никто не вмешивался. По мере того, как распространение программного обеспечения перешло с компакт-дисков в Интернет, дистрибутивы Linux оказались удивительно успешными в обеспечении доверия.

Когда Log4j и SolarWinds выявили некоторые бреши, которые используют новые атаки на цепочки поставок программного обеспечения, команды начали блокировать системы сборки, используя такие фреймворки, как SSDF и SLSA, и проверять подписи программного обеспечения, созданные Sigstore (сейчас метод подписи программного обеспечения по умолчанию используется Kubernetes и всеми основными реестрами языков программирования). Это прогресс.

Домен безопасности с открытым исходным кодом сложен. Мы говорим о моделях доверия десятилетней давности по сравнению с 372 миллионами репозиториев только на GitHub! По-прежнему существует серьезный разрыв между известными CVE и разработчиками, которые невольно переустанавливают их с помощью переходных зависимостей. По-прежнему существует целый класс уязвимостей, которые полностью находятся за пределами дистрибутивов Linux и, следовательно, не обнаруживаются сканерами безопасности. Потребителям программного обеспечения достаточно сложно понять, когда они запускают вредоносные программные пакеты, не говоря уже о том, чтобы быть достаточно проворными, чтобы быстро исправлять их обновлениями, когда они доступны.

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

Мы собираемся начать слышать, как команды безопасности согласовывают свои ожидания в отношении безопасности инфраструктуры приложений с концепциями нулевого доверия и больше не принимают кучу ошибок в своих дистрибутивах и образах, которые могут привести к появлению трещин и лазеек для переходных зависимостей. Мы увидим команды безопасности, которые хотят приблизиться к ядру с помощью таких технологий, как eBPF и Cilium, и использовать принудительное применение политик безопасности во время выполнения, которые могут обеспечить такие проекты, как Tetragon. И мы увидим, что эта изоляция ускорится благодаря примерам использования искусственного интеллекта, которые требуют от предприятий доверять еще большему количеству фреймворков с еще большим количеством переходных зависимостей, включая специализированные архитектуры графических процессоров и все более тонкие "черные ходы".

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

Автор статьи на сайте InfoWorld: Дэн Лоренц, генеральный директор и соучредитель Chainguard