В 2022 году безопасность станет приоритетом номер один для Linux и разработчиков ПО с открытым исходным кодом.

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

Линукс есть везде. Это то, на чем работают все облака, даже 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 Archive (JAR). Результат? Возможно, вы используете уязвимую версию log4j и не узнаете об этом, пока она не будет использована.

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

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

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

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

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

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

Для этого вам и вашим разработчикам необходимо отслеживать ваши программы в SBOM, используя формат обмена данными пакетов программного обеспечения (SPDX) Linux Foundation. Затем, чтобы еще больше гарантировать, что ваш код действительно является тем, чем он себя называет, вам необходимо нотариально заверить и проверить свой SBOM с помощью таких служб, как Служба аттестации сообщества Codenotary и Каталоги 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-х годах). Но в будущем многие драйверы Linux и другой код будут написаны на Rust.

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

«Тем не менее, — заключил он, — я также знаю, что иногда обещания не сбываются».

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