Проблемы зависимости: решение мировой проблемы безопасности программного обеспечения с открытым исходным кодом

20.05.2022
Без проведения необходимых реформ современное программное обеспечение обратится против своего создателя.

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

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

И список экономически важных и широко используемых компонентов с открытым исходным кодом – фреймворк глубокого обучения Google TensorFlow или его спонсируемый Facebook конкурент PyTorch, вездесущая библиотека шифрования OpenSSL или программное обеспечение для управления контейнерами Kubernetes – длинный, и он будет становиться еще длиннее. Военное и разведывательное сообщество также зависит от программного обеспечения с открытым исходным кодом: такие программы, как Palantir, стали ключевыми для контртеррористических операций, а программное обеспечение F-35 содержит миллионы строк открытого кода.

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

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

Дорога к зависимости

Традиционные отчеты о появлении повторно используемых программных компонентов часто относятся к 1960-м годам. Эксперты по программному обеспечению, такие как Дуглас Макилрой из Bell Laboratories, отметили огромные затраты на создание нового программного обеспечения. Чтобы упростить задачу, Макилрой призвал к созданию подотрасли «программных компонентов» для массового производства программных компонентов, которые могли бы широко применяться на машинах, пользователях и приложениях – или, другими словами, именно к тому, что предоставляет современное программное обеспечение с открытым исходным кодом.

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

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

Эффективность этой программной модели делает большую часть общества зависимой от программного обеспечения с открытым исходным кодом. Сторонники открытого исходного кода защищают текущую систему, ссылаясь на закон Линуса: «При достаточном количестве глаз все ошибки поверхностны». То есть, поскольку исходный код программного обеспечения можно проверить бесплатно, разработчики программного обеспечения, работающие и делящиеся кодом в Интернете, обнаружат проблемы до того, как они затронут общество, и, следовательно, общество не должно слишком беспокоиться о своей зависимости от программного обеспечения с открытым исходным кодом, потому что эта невидимая армия защитит его.

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

Event-Stream

История началась, когда разработчик Доминик Тарр передал права на публикацию пакета JavaScript с открытым исходным кодом под названием Event-Stream другому лицу, известному только под псевдонимом right9ctrl. Передача произошла на GitHub, популярной платформе для размещения кода, которую часто посещают десятки миллионов разработчиков программного обеспечения. Пользователь right9ctrl предложил поддерживать поток событий, который на тот момент загружался почти два миллиона раз в неделю.

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

Передача управления частью программного обеспечения с открытым исходным кодом другой стороне всегда происходит без каких-либо последствий. Но на этот раз произошел злонамеренный поворот. После того, как Тарр передал управление, right9ctrl добавил новый компонент, который пытался украсть биткойны с компьютера жертвы. Миллионы и миллионы компьютеров загрузили этот пакет вредоносного программного обеспечения, пока разработчик Джейден Серик не заметил аномалию в октябре 2018 года.

Event-Stream был только началом. В последние годы исследователи компьютерной безопасности обнаружили злоумышленников, использующих ряд новых методов. Некоторые имитируют самозахват доменных имен: обманом заставляют разработчиков программного обеспечения, которые ошибаются в написании имени пакета, загружать вредоносное ПО (dajngo или django). Другие атаки используют неверные настройки программных инструментов, которые обманом заставляют разработчиков загружать пакеты программ из неправильного реестра пакетов. За последнее десятилетие частота и сила этих атак увеличились. И эти подсчеты даже не включают, возможно, более многочисленные случаи непреднамеренных уязвимостей безопасности в программном обеспечении с открытым исходным кодом. Совсем недавно непреднамеренная уязвимость широко используемого пакета программного обеспечения log4j стала поводом для проведения саммита Белого дома по безопасности программного обеспечения с открытым исходным кодом. После обнаружения этой уязвимости один журналист с небольшим преувеличением назвал статью «Интернет в огне».

План из трех шагов

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

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

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

Проект Sigstore, созданный в сотрудничестве силами Linux FoundationGoogle и рядом других организаций, является одним из таких усилий, направленных на использование цифровых подписей, чтобы сделать цепочку поставок программного обеспечения с открытым исходным кодом прозрачной и поддающейся проверке. Эти технические подходы представляют собой цифровой эквивалент защиты от несанкционированного доступа. Команда разработчиков программного обеспечения Platform One Министерства обороны уже внедрила элементы Sigstore.

Кроме того, может помочь «обсерватория» цепочки поставок программного обеспечения, которая собирает, курирует и анализирует мировую цепочку поставок программного обеспечения с целью противодействия атакам. Обсерватория, потенциально управляемая консорциумом университетов, могла бы одновременно помочь измерить распространенность и серьезность компрометации программного обеспечения с открытым исходным кодом, предоставить исходные данные, которые позволяют обнаруживать, и количественно сравнивать эффективность различных решений. Набор данных Software Heritage содержит зародыши такой обсерватории.

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

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

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

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

Источник