Риски и преимущества экосистемы Open Source

ПО с открытым исходным кодом подпитывает цифровой мир, но как предприятия могут управлять его рисками? Эту тему обсуждают опрошенные порталом InformationWeek эксперты.

Обнаруженный в начале этого года бэкдор в ПО для сжатия данных XZ Utils вызвал шквал дискуссий о рисках ПО с открытым исходным кодом. Устранить этот риск не так просто, даже если руководство предприятия решит отказаться от использования открытого ПО. На самом деле, это практически невозможно.

«Подавляющее большинство языков программирования (и их базовых инструментов) — с открытым исходным кодом, а те, которые не являются таковыми, вымирают. Без сомнения, технологии Open Source — это тот фундамент, на котором построен цифровой мир», — говорит Квази Нафиул Ислам, специалист по взаимодействию с разработчиками компании Sonar, разработчика открытого ПО для непрерывного контроля качества кода.

В рабочем документе Гарвардской школы бизнеса «Ценность программного обеспечения с открытым исходным кодом» говорится, что ценность такого ПО со стороны спроса составляет 8,8 трлн. долл. — ошеломляющая цифра, которая ясно определяет то, насколько неотъемлемой частью современного мира является открытое ПО.

Как выглядит современная зависимость от ПО с открытым исходным кодом, и как руководители предприятий могут сбалансировать риски и выгоды, связанные с этим?

Использование Open Source сегодня

Трудно найти корпоративный технологический стек, который бы в той или иной степени не опирался на открытый код. По данным Linux Foundation, проникновения открытого кода в вертикальные программные стеки составляет от 20 до 85%. Более 90% веб-серверов и подключенных к Интернету устройств работают под управлением Linux, одной из самых известных и используемых ОС с открытым исходным кодом. И Linux — лишь одна из частей огромного мира Open Source, в котором есть как масштабные проекты с тысячами участников, так и небольшие проекты, запускаемые и поддерживаемые всего несколькими разработчиками.

В мире ПО с открытым исходным кодом каждый может увидеть код и внести в него свой вклад, улучшив его функциональность.

«Когда программисты могут делиться своей работой и развивать существующие проекты, это способствует развитию культуры непрерывного совершенствования и коллективного решения проблем, — говорит Ислам. — Инициативы Open Source также демократизируют технологии, снижая барьер входа для отдельных людей и организаций».

ПО с открытым исходным кодом — это коллективная сила людей по всему миру, использующих свои навыки для решения общих задач, и на этой коллективной силе строятся компании.

«По сути, сказать: „О, мы просто создадим свой собственный языковой фреймворк. У нас будут собственные пакеты, и все будет построено не на открытом коде“, — значит поставить себе невыполнимую задачу», — говорит Найджел Дуглас, старший специалист по взаимодействию с разработчиками компании Sysdig, специализирующейся на облачной безопасности.

Люди в сообществе Open Source

Кто же эти люди, создающие ПО с открытым исходным кодом? Многие из них — индивидуальные разработчики, которые используют свои навыки, чтобы внести вклад в проект, которым они увлечены; это труд любви. «Возможно, вы никогда не сможете нанять их на работу, но они готовы уделять свое время, потому что это то, что они считают крутым и интересным», — говорит Тим Маки, руководитель отдела стратегии рисков в цепочке поставок ПО софтверной компании Synopsys.

Некоторые из этих людей могут превратить свое увлечение в карьеру. Сет Майкл Ларсон начал работать с открытым исходным кодом в 2016 г. Его интересовали Интернет и сетевые технологии, которые в то время он не имел возможности изучить на своей работе. «В итоге я дослужился до ведущего разработчика одного из самых скачиваемых пакетов Python — urllib3», — делится он.

Продолжая идти по этому пути, Ларсон подал заявку и получил должность разработчика-резидента по безопасности в Python Software Foundation. Open Source-фонды, подобные этому, часто работают за счет внешнего финансирования. Alpha-Omega, ассоциированный проект Open Source Security Foundation (OpenSSF), финансируется технологическими гигантами Microsoft, Google и Amazon. В 2022 г. Alpha-Omega выделил 800 тыс. долл. на поддержку Python Software Foundation и Eclipse Foundation.

Крупные предприятия могут нанимать целые команды людей для участия в Open Source-проектах. «Некоторые крупные технологические вендоры (AWS, Google и др.) наняли людей, которые много работали с открытыми проектами. Эти люди получили возможность продолжать свою работу, получая зарплату за сотрудничество с сообществами, в которых они состоят», — говорит Пол Хокинс, CISO компании CipherStash, специализирующейся на шифровании данных.

Мейнтейнеры определяют, какие изменения можно вносить в конкретный Open Source-проект. «Человек, который переходит на уровень мейнтенера, проходит фундаментальную проверку на основе качества кода, который он вносит», — объясняет Маки.

Несмотря на то, что существуют пути, позволяющие стать оплачиваемым участником Open Source-проектов, многие разработчики в сообществе предоставляют свои навыки и время бесплатно. В отчете Tidelift «2023 State of the Open Source Maintainer Report» говорится, что 60% мейнтейнеров — это неоплачиваемые энтузиасты.

«Большого вознаграждения мейнтейнеру не полагается, если только проект не становится довольно крупным и не превращается в основополагающий. Как правило, в проектах есть небольшая кнопка „пожертвовать“, но это все», — говорит Ислам.

Широкое поле деятельности сообщества Open Source — вклад оценивается только по заслугам — означает, что даже студенты могут участвовать в проекте в качестве части своего образования.

Риски Open Source

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

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

Хотя совместная работа сообщества Open Source-разработчиков является неоспоримым преимуществом, она также может привлечь злоумышленников. «У злоумышленников также будет доступ к этому коду, и они смогут понять его, — говорит Амит Малик, директор по исследованиям угроз Uptycs, платформs защиты облачных приложений. — Они могут определить уязвимости в коде и использовать их для компрометации машин».

Хотя субъекты угроз постоянно ищут способы использования уязвимостей, открытый кодом всегда доступен для тщательного изучения. «Это означает, что за кодом следит множество людей, что повышает вероятность обнаружения проблем», — говорит Хокинс.

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

«Мы должны признать, что ОС строятся на основе большого количества различных пакетных зависимостей, и в этом есть элемент риска», — говорит Дуглас.

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

«Как CISO, я вижу, что самый большой риск заключается в том, что организации не уделяют должного внимания тому, как они используют открытое ПО, — говорит Хокинс. — Очень выгодно строить на основе этих замечательных проектов, но когда мы это делаем, нам нужно убедиться, что мы понимаем наши зависимости. Проведение оценки Open Source-компонентов, как и компонентов, разработанных внутри компании, является ключевым моментом для точного понимания нашего уровня безопасности».

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

Инцидент с XZ Utils и уязвимости открытого кода

Повсеместное распространение ПО с открытым исходным кодом означает, что уязвимости могут иметь широкомасштабные последствия. Инцидент с XZ Utils — хороший пример потенциальных последствий уязвимости в широко используемом компоненте с открытым кодом.

Главный участник инцидента потратил два года на то, чтобы внедриться в сообщество Open Source-разработчиков, и в итоге занял должность мейнтейнера. Благодаря этому он смог внедрить вредоносный код в две версии ПО XZ Utils, которое используется во многих дистрибутивах Linux. Если бы версии с этим бэкдором попали в широкое распространение, они могли бы способствовать значительному несанкционированному доступу к системам.

Хотя этот инцидент вызвал широкую тревогу по поводу рисков, связанных с открытым исходным кодом, в некотором смысле он также стал демонстрацией стойкости сообщества Open Source. «Это был успех для Open Source, потому что благодаря тому, что инцидент получил широкую огласку, лучшие в своих областях исследователи и аналитики по вопросам безопасности смогли в считанные часы принять участие в его разрешении», — отмечает Ларсон.

Бэкдор XZ Utils был пойман до того, как смог нанести серьезный ущерб, но это не значит, что нечто подобное не произойдет в будущем, причем с бóльшим успехом для злоумышленников.

«Нечто подобное XZ... в конце концов произойдет в той или иной степени. Мы не знаем, когда и как это произойдет», — говорит Малик.

Тысячи уязвимостей, будь то ошибка в коде или злой умысел, появляются в Open Source-пространстве каждый год. Используются ли эти уязвимости на самом деле — другой вопрос.

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

Уязвимости могут дать понять, как много может зависеть от очень небольшого количества людей. Ислам указывает на уязвимость Heartbleed, обнаруженную десять лет назад: «Уязвимость Heartbleed ... была вызвана использованием уязвимой версии OpenSSL, библиотеки, которая применяется для защиты большей части интернет-трафика. Хотя проект поддерживался группой волонтеров, над ним работал только один оплачиваемый сотрудник на полный рабочий день», — объясняет он.

После появления ошибки Heartbleed фонд Linux Foundation запустил инициативу Core Infrastructure Initiative с целью обеспечить поддержку безопасности для Open Source-проектов. Сегодня OpenSSF является лидером в обеспечении безопасности экосистемы Open Source.

Будущее Open-Source

Итак, отказаться от ПО с открытым исходным кодом не представляется возможным, и риск является частью сделки. Для предприятий эта реальность требует управления рисками. И эта необходимость только возрастает, как и зависимость от открытого ПО. «По мере перехода к облакам и высокодинамичным средам такого рода наша зависимость от открытого ПО становится еще выше, чем в прошлом», — говорит Дуглас.

Если руководители предприятий изменят свое отношение к ПО с открытым исходным кодом, они смогут лучше использовать его преимущества и одновременно снизить риски.

Предприятиям не нужно платить за использование открытого ПО, но это не значит, что его следует считать полностью бесплатным. «Посмотрите на стоимость владения, и вы увидите, что есть определенные затраты, связанные с управлением уязвимостями, — говорит Маки. — Есть определенные затраты, связанные с обеспечением того, чтобы функциональность оставалась верной той цели, для которой она была изначально приобретена».

Чтобы эффективно управлять уязвимостями Open Source, корпоративные команды должны понимать, какие компоненты с открытым исходным кодом они используют. Эту задачу легче сказать, чем выполнить.

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

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

«Open-Source Software Foundation Score Card — это специальный инструмент для проверки, насколько активен проект и, например, какие средства контроля существуют в отношении обзора кода, защиты ветвей, обнаружения уязвимостей и бинарных эффектов», — говорит Дуглас.

Если предприятие хочет добиться изменений в Open Source-проекте, сделать это не так просто, как в случае с вендором, используя договорное влияние.

«Руководители предприятий должны понимать, что управление Open Source — это не то же самое, что управление отношениями с поставщиками в мире коммерческого ПО. Здесь это просто не работает, — говорит Маки. — Руководители предприятий должны думать о том, „Как я буду управлять этим в своей ситуации?“, а не „Как я могу распространить свой нынешний коммерческий образ мышления на Open Source и склонить Open Source к коммерческому образу мышления?“».

Предприятия кровно заинтересованы в надежной и безопасной экосистеме Open Source, что предполагает, что они должны вносить свой вклад в развитие этой экосистемы. «Реальное решение заключается в том, чтобы сказать: „Вот компоненты с открытым исходным кодом, от которых зависит моя организация. Вот те, которые являются критически важными и без которых я просто не смогу работать“, а затем найти способы внести свой вклад в успех этого ПО», — говорит Маки.

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