Linux и ПО с открытым исходным кодом в следующем году будут популярны как никогда, но самые большие изменения произойдут в том, как они будут защищены, пишет на портале ZDNet обозреватель Стивен Воан-Николс.
Linux — повсюду. На нем работают все облака, даже Microsoft Azure. На нем работают все 500 суперкомпьютеров из Топ-500. Черт возьми, даже настольный Linux растет, если верить сайту Pornhub, который утверждает, что число пользователей Linux выросло на 28%, в то время как число пользователей Windows сократилось на 3%.
ПО категории Open Source (OSS) также растет семимильными шагами. Согласно Gartner «2021 Hype Cycle for Open-Source Software», к 2025 г. более 70% предприятий увеличат свои расходы на OSS по сравнению с текущими расходами на ИТ. Кроме того, предпочтительной моделью потребления OSS станет SaaS — благодаря своей способности обеспечить лучшую операционную простоту, безопасность и масштабируемость.
Кроме того, в 2022 г., по прогнозам аналитической компании, более 70% новых внутренних приложений будут разрабатываться на базах данных категории Open Source, а 50% существующих проприетарных реляционных баз данных будут преобразованы или будут находиться в процессе преобразования. А ведь базы являются основной частью корпоративного ПО.
Я склонен верить этим цифрам. Я слежу за Linux и OSS с самого первого дня. Куда бы я ни пошел, все, с кем я разговариваю, признают, что эта пара управляет вселенной ПО. Но с большой властью приходит и большая ответственность, что хорошо известно Человеку-пауку. И, как недавно узнали многие разработчики, когда были обнаружены многочисленные уязвимости в безопасности открытой библиотеки log4j2 для протоколирования Apache Java, также приходит большая головная боль.
Проблемы с log4j2 серьезны настолько, насколько это вообще возможно. По шкале National Vulnerability Database (NVD) они оценивается как 10.0 CVSSv3, что совершенно ужасно.
Настоящая проблема не столько в самом Open Source. В методологии и безопасности открытого исходного кода нет ничего магического. Ошибки безопасности все равно могут попасть в код. Закон Линуса гласит, что при достаточном количестве глаз все ошибки неглубокие. Но если следит недостаточно разработчиков, в системе безопасности останутся незамеченные уязвимости. Согласно закону Шнайера, «безопасность — это процесс, а не продукт», что указывает на необходимость постоянной бдительности для обеспечения безопасности любого ПО.
Тем не менее, настоящая проблема с log4j заключается в том, как Java скрывает то, какие библиотеки использует ее код и двоичные файлы в многочисленных вариантах Java Archive (JAR). Результат? Вы можете использовать уязвимую версию log4j и не знать об этом, пока уязвимость не будет задействована.
«Одна из проблем, которую представляет собой уязвимость log4j, — это ее фактическое обнаружение. Java-приложения и зависимости обычно имеют некий формат упаковки, который упрощает распространение и запуск, но может затруднить поиск того, что находится внутри этих пакетов», — объяснил Джош Брессерс, вице-президент по безопасности компании Anchore.
К счастью, существуют сканеры log4j, которые могут помочь вам обнаружить дефектные используемые библиотеки. Но они не идеальны.
За неразберихой с log4j скрывается другая проблема: как узнать, какие Open Source-компоненты использует ваше ПО? Например, log4j2 используется с 2014 г. Вы не можете ожидать, что кто-то вспомнит, использовал ли он ту первую версию в какой-то программе, которую вы применяете до сих пор.
Ответ заключается в том, что в последние годы сообщество Open Source начало серьезно относиться к этому вопросу, подтверждением чему служит создание спецификации ПО (Software Bills of Materials, SBOM). SBOM точно описывает, какие программные библиотеки, процедуры и другой код были использованы в любой программе. Вооружившись этим, вы можете изучить, какие версии компонентов используются в вашей программе.
Как объяснил Дэвид Уилер, директор Linux Foundation по безопасности цепочки поставок Open Source, используя SBOM и проверенные воспроизводимые сборки, вы можете быть уверены, что знаете, что есть что в ваших программах. Таким образом, если в каком-либо компоненте обнаружится брешь в безопасности, вы сможете просто залатать ее, а не искать, как маньяк, любой возможный проблемный код, прежде чем его удастся исправить.
«Воспроизводимая сборка, — объясняет Уилер, — это такая сборка, которая всегда дает одинаковые результаты при одинаковых входных данных, так что результаты сборки могут быть проверены. Проверенная воспроизводимая сборка предполагает процесс, в котором независимые организации производят сборку из исходного кода и проверяют, что результаты сборки получены из заявленного исходного кода».
Для этого вам и вашим разработчикам необходимо отслеживать свои программы в SBOM, используя формат Software Package Data Exchange (SPDX) от Linux Foundation. Затем, для дальнейшей гарантии того, что ваш код действительно является тем, за что себя выдает, вам необходимо нотариально заверить и верифицировать ваш SBOM с помощью таких служб, как Codenotary Community Attestation Service и Tidelift Catalogs.
Все это легко сказать. Сделать это сложно. В 2022 г. практически все разработчики Open Source будут тратить много времени на проверку своего кода на наличие проблем, а затем на создание SBOM на основе SPDX. Этого будут требовать пользователи, обеспокоенные катастрофами типа Solarwind и проблемами безопасности log4j.
В то же время разработчики Linux работают над дальнейшей защитой операционной системы, делая Rust вторым языком Linux. Почему? Потому что, в отличие от Cи, основного языка Linux, Rust гораздо более безопасен. В частности, Rust гораздо безопаснее, чем Cи, при обработке ошибок памяти.
«Rust полностью безопасен для памяти», — утверждает Райан Левик, главный специалист Microsoft по поддержке облачных разработчиков. Это очень важно, поскольку, как сообщили на Linux Security Summit 2019 разработчики ядра Linux Алекс Гейнор и Джеффри Томас, почти две трети дыр в безопасности ядра Linux связаны с проблемами безопасности памяти. А откуда они берутся? Из-за проблем, присущих языкам Cи и C++.
Теперь Linux будет переписан на языке Rust. Конечно, не в этом десятилетии, а в
Как сказал мне Линус Торвальдс, хотя он «никоим образом не настаивает на Rust», он «открыт для него, учитывая обещанные преимущества и возможность избежать некоторых подводных камней безопасности». Тем не менее, заключил он, «я также знаю, что иногда обещания не выполняются».
Посмотрим, что из этого получится. Независимо от того, как пойдут конкретные дела, одно я знаю наверняка. Мы увидим, что в 2022 г. обеспечение безопасности кода станет главной проблемой для разработчиков Linux и Open Source. Учитывая их важность, иначе быть не может.
