Линукс повсюду. Это то, что запускают все облака, даже Microsoft Azure. Это то, что заставляет работать все 500 суперкомпьютеров из 500 лучших. Черт возьми, даже настольный Linux растет, если вы можете верить Pornhub, утверждающий, что количество пользователей Linux выросло на 28%, а пользователи Windows снизились на 3%.

Программное обеспечение с открытым исходным кодом также растет не по дням, а по часам. В соответствии с Цикл хайпа Gartner в отношении ПО с открытым исходным кодом (OSS) до 2021 г.: «К 2025 году более 70% предприятий увеличат свои ИТ-расходы на OSS по сравнению с их текущими ИТ-расходами. Кроме того, к 2025 году программное обеспечение как услуга (SaaS) станет предпочтительной моделью потребления для OSS из-за его возможностей. для обеспечения большей простоты эксплуатации, безопасности и масштабируемости «.

Размышляя о базах данных, о базовом программном обеспечении для предприятий, Gartner прогнозирует, что более 70% новых собственных приложений будут разрабатываться на базе данных с открытым исходным кодом. Одновременно 50% существующих экземпляров проприетарных реляционных баз данных будут преобразованы или конвертируются в СУБД с открытым исходным кодом.

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

Но Человек-паук знает, что с большой силой приходит и большая ответственность. И, как недавно выяснили многие разработчики, когда было обнаружено несколько уязвимостей безопасности в библиотеке с открытым исходным кодом для ведения журналов Apache Java log4j2, это также приносит большие головные боли.

Проблемы с log4j2 настолько серьезны, насколько это возможно. По шкале Национальной базы данных уязвимостей (NVD) он получил 10,0 CVSSv3, что совершенно ужасно.

Его настоящая проблема не столько в самом открытом исходном коде. Есть ничего волшебного в методологии открытого исходного кода и безопасности. Ошибки безопасности все еще могут ввести код. Закон Линуса это то, что при достаточном внимании, все ошибки мелкие. Но, если разработчиков не будет искать, уязвимости в системе безопасности все равно останутся незамеченными. Как то, что я сейчас называю законом Шнайера, «Безопасность — это процесс, а не продукт, «указывает на необходимость постоянной бдительности для защиты всего программного обеспечения.

Тем не менее, настоящая головная боль с log4j заключается в том, как Java скрывает, какие библиотеки используются в ее исходном коде и двоичных файлах во многих Архив Java (JAR) вариации. Результат? Возможно, вы используете уязвимую версию log4j и не знаете, пока она не была взломана.

Как Джош Брессерс, АнкореВице-президент по безопасности недавно объяснил: «Одна из проблем, связанных с уязвимостью log4j, — это ее фактическое обнаружение. Java-приложения и зависимости обычно имеют какой-то пакетный формат, который делает распространение и запуск очень простым, но он может упростить понимание что внутри этих программных пакетов сложно «.

К счастью, существуют сканеры log4j, которые могут помочь вам обнаружить используемые дефектные библиотеки log4j. Но они не идеальны.

За беспорядком log4j стоит еще одна проблема: «Как узнать, какие компоненты с открытым исходным кодом использует ваше программное обеспечение?» Например, log4j2 используется с 2014 года. Вы не можете ожидать, что кто-то вспомнит, использовали ли они эту первую версию в какой-то программе, которую вы все еще используете.

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

Как сказал Дэвид А. Уиллер, Linux FoundationДиректор по безопасности цепочки поставок с открытым исходным кодом объяснил, используя SBOM и проверенные воспроизводимые сборки, вы можете быть уверены, что знаете, что к чему в ваших программах. Таким образом, если в компоненте обнаружена дыра в безопасности, вы можете просто исправить ее, а не искать, как маньяк, любой возможный проблемный код, прежде чем иметь возможность ее исправить.

«Воспроизводимая сборка», между прочим, объясняет Уиллер, — это «та, которая всегда дает одни и те же выходные данные при одинаковых входных данных, так что результаты сборки могут быть проверены. Проверенная воспроизводимая сборка — это процесс, при котором независимые организации создают сборку из исходного кода. и убедитесь, что полученные результаты получены из заявленного исходного кода «.

Для этого вам и вашим разработчикам необходимо отслеживать свои программы в SBOM с помощью Linux Foundation Формат обмена данными программных пакетов (SPDX). Затем, чтобы еще больше гарантировать, что ваш код действительно является тем, за что он претендует, вам необходимо нотариально заверить и подтвердить свой SBOM с помощью таких служб, как Служба аттестации коденотарного сообщества и каталоги Tidelift.

Все это легко сказать. Делать это тяжело. В 2022 году почти все разработчики с открытым исходным кодом будут тратить много времени на проверку своего кода на наличие проблем, а затем на создание SBOM на основе SPDX. Пользователи, обеспокоенные катастрофами типа Solarwind и проблемами безопасности log4j, будут требовать этого.

В то же время разработчики Linux работают над дальнейшей защитой операционной системы, сделав Rust Linux вторым языком. Почему? Потому что, в отличие от C, основного языка Linux, Rust намного безопаснее. В частности, Rust намного безопаснее C при обработке ошибок памяти.

Как пояснил Райан Левик, главный защитник облачных разработчиков Microsoft: «Rust полностью безопасен для памяти. «Это очень важно, поскольку, как отметили разработчики ядра Linux Алекс Гейнор и Джеффри Томас на Саммите по безопасности Linux 2019 года, почти две трети дыр в безопасности ядра Linux происходят из-за проблем с безопасностью памяти. И откуда они берутся? Проблемы, присущие C и C ++.

Теперь Linux переписывают на Rust. По крайней мере, не в этом десятилетии, посоветуйтесь со мной еще раз в 2030-х, но в будущем на Rust будет написано много драйверов для Linux и другой код.

Как сказал мне Линус Торвальдс, хотя он «никоим образом не« настаивает »на Rust», он «открыт для этого, учитывая обещанные преимущества и избегая некоторых ловушек безопасности. Тем не менее, он заключил:« Я также знаю, что иногда обещания не сбываются. . »

Посмотрим, как это все получится. Независимо от того, как обстоят дела в деталях, одно я знаю наверняка. Мы увидим, что защита кода станет главной проблемой для разработчиков Linux и открытого исходного кода в 2022 году. И то, и другое стало слишком важным, чтобы все могло пойти по-другому.