В фокусе
Читать...
ГлавнаяРубрикиПрограммное обеспечениеLinux Foundation: самые важные компоненты Open Source и их проблемы
25.02.2020

Linux Foundation: самые важные компоненты Open Source и их проблемы

Проект Core Infrastructure Initiative (CII), который действует под эгидой некоммерческой организации Linux Foundation, выпустил отчет, в котором изучается вопрос интеграции компонентов Open Source со всей массой выпущенного ПО, рассматриваются их общие проблемы и уязвимости, сообщает портал ZDNet.

Как показал недавний опрос Red Hat, ПО на базе Open Source доминирует на предприятиях. На самом деле его влияние гораздо выше. По данным поставщика Open Source-платформы Nexus Sonatype, ПО с открытым кодом занимает от 80 до 90% всего рынка ПО. Об этом не все знают, но даже проприетарные программы, которые строятся на закрытых компонентах, все чаще привлекают наработки открытых проектов. CII и лаборатория инновационных наук Гарварда выпустили совместный отчет «Vulnerabilities in the Core, a preliminary report and Census II of open-source software», где перечислены наиболее часто встречающиеся в сторонних программах компоненты Open Source и присущие им слабые места.

Несмотря на то, что этот отчет является первым крупным исследованием такого рода, он не охватывает весь спектр открытого стека компонентов и его результаты можно назвать промежуточными. Тем не менее, в нем приводится методология, которая требуется для понимания и решения структурных проблем безопасности ПО, классифицируются самые востребованные компоненты свободного ПО с общедоступными (открытыми) исходными кодами (Free and Open-Source Software, FOSS) в корпоративных программах и проводится их анализ на предмет устойчивости к потенциальным атакам.

Помимо CII и LISH в проекте Census II приняли участие компании, которые занимаются обеспечением защиты приложений и структурным анализом кода (Software Composition Analysis, SCA), такие как Snyk и Synopsys Cybersecurity Research Center. Сопоставив имеющиеся в их распоряжении клиентские данные и данные, имеющиеся в распоряжении открытых источников, они определили более 200 наиболее популярных Open Source-проектов. Примечательно, что это не Apache, MySQL или Linux — фундаментально важные проекты, которые сразу приходят на ум, а небольшие программы, или так называемые строительные блоки, которые за редким исключением наполняют подавляющее большинство современных программ.

Они, как правило, небольшие, иногда менее ста строк кода, но жизненно необходимы. «FOSS долгое время считалось чем-то из разряда хобби, которым к тому же занимались любители. Однако теперь оно стало неотъемлемым компонентом современной экономики и является основой потребительских технологий, таких как смартфоны, автомобили, Интернет вещей и многочисленные элементы критической инфраструктуры. Понимание того, какие компоненты наиболее широко используются и являются наиболее уязвимыми, позволит нам создать здоровую экосистему и цифровую экономику», — отметил профессор Гарвардской школы бизнеса и содиректор проекта Census II Фрэнк Нэгл.

Речь идет о тех скрытых маленьких программах, которые, если не следить за ними, могут вызывать проблемы. Например, реальная проблема с уязвимостью Heartbleed была связана не со сравнительно известной программой для обеспечения безопасности OpenSSH, а с ее низкоуровневой криптографической библиотекой OpenSSL.

Конечный пользователь мало что знает об низкоуровневых программах — это скорее компетенция CIO или даже CTO. «Реальные пользователи Open Source — это разработчики, которые целенаправленно занимаются его поиском, а затем загружают и интегрируют его в прототипы проектов, над которыми они работают», — утверждает венчурный инвестор Майк Волпи. Затем эти компоненты срастаются с клиентской программой на глубинном уровне, который недоступен для пользователя. Многие из этих подпрограмм написаны на языке JavaScript. В значительной степени это объясняется тем, что они обладают крайне небольшим объемом кодовой базы — 112 строк кода и часто выполняют только одну функцию. Напротив, средний модуль Python в репозитории PyPI имеет более 2200 строк кода, поэтому JavaScript гораздо чаще выделяется на фоне Python при оценке зависимостей программы.

Самые популярные подпрограммы на базе JavaScript

  • Async. Служебный модуль, который предоставляет функции для работы с асинхронным JavaScript. Async устанавливается посредством npm install async и изначально был разработан для работы с Node.js, но его также можно запускать непосредственно в браузере;
  • Inherits. Этот пакет предназначен для унаследования одним конструктором методов прототипа другого конструктора (стандартная модель наследования в программной платформе Node.js), но также предоставляет альтернативную дружественную для браузера реализацию через поле браузера;
  • Isarray. Массив для устаревших версий браузеров и Node.js;
  • Kind-of. Этот модуль позволяет присвоить JavaScript собственный тип значений;
  • Lodash. Современная библиотека утилит JavaScript, обеспечивающая модульность, производительность и дополнительные возможности;
  • Minimist. Модуль, предназначенный для разбора параметров аргумента. Он представляет из себя синтаксический анализатор аргументов и переводит их в более легкие для использования ассоциативные массивы.
  • Natives. Пакет, предназначенный для вызова собственных JavaScript-модулей Node.js;
  • Qs. Библиотека для парсинга строки запроса и преобразования элементарных значений, объектов или массивов в строку в формате JavaScript Object Notation (JSON) с дополнительными функциями безопасности;
  • Readable-stream. Основные потоки в операциях ввода/вывода для передачи данных с одной программы в другую в Node.js;
  • String_decoder. Node-core string_decoder для пользовательских программ.

Самые популярные программные компоненты, в которых JavaScript не применяется

  • Com.fasterxml.jackson.core:jackson-core. Основная часть Jackson, процессора JSON, который предназначен для потоковой передачи API, а также основных общих абстракций;
  • Com.fasterxml.jackson.core: jackson-databind. Общий пакет привязки данных для Jackson (2.x); работает с потоковыми API;
  • Com.google.guava: guava. Основные библиотеки Google для Java;
  • Commons-codec. Это ПО от Apache поддерживает работу распространенных кодировщиков и декодировщиков, таких как Base64, Hex, Phonetic, и URL-запросов;
  • Commons-io. Это библиотека утилит, помогающих в разработке функций ввода-вывода;
  • Httpcomponents-client. Проект Apache HttpComponents представляет собой набор инструментов низкоуровневых компонентов Java, ориентированных на HTTP и связанные с ним протоколы;
  • Logback-core. Надежная, универсальная, быстрая и гибкая среда ведения журналов в среде Java;
  • Org.apache.commons: commons-lang3. Пакет служебных классов, которые обеспечивают поддержку работы с основными классами API Java и находятся в иерархии классов java.lang. Эта поддержка включает методы для обработки строк, чисел, дат, параллелизма, отражения объектов и многого другого;
  • Slf4j. Библиотека для протоколирования, ставящая своей целью предоставить максимально простой фасад для различных систем протоколирования на Java.

Исследователи пришли к выводу, что разработчик Open Source, которому нравится писать код в домашней обстановке, — это всего лишь миф. Впрочем, среди программистов есть немало людей, которым нравится работать дома, но многие из них — вовсе не затворники, а профессиональные и трудоустроенные программисты, вносящие основной вклад в самые популярные пакеты FOSS. Как показал анализ данных GitHub за 2017 г., некоторые из наиболее активных разработчиков участвовали в FOSS-проектах, зарегистрировавшись с э-почты как действующие сотрудники Microsoft, Google, IBM или Intel.

Исследователи также обнаружили несколько общих проблем с компонентами с открытым исходным кодом. Первая из них — трудноуловимая связь между названием программ и их функционалом. Отсутствие типовой схемы именования программных компонентов серьезно усложняет их отслеживание. Эта проблема хорошо известна. Национальный институт стандартов и технологий (NIST) и Национальное управление по телекоммуникациям и информации (NTIA) занимаются ее решением не один десяток лет. Linux Foundation и партнеры считают, что существует настоятельная необходимость в стандартизированной схеме именования программных компонентов. «До момента, когда она будет принята, стратегии обеспечения безопасности, прозрачности и т. д. будут носить ограниченный характер. Отсутствие четкой схемы позиционирования продуктов препятствует общению между организациями, которые принимают участи в цепочке поставок ПО или являются его потребителями, несет растущую угрозу перед лицом участившихся инцидентов кибербезопасности. Это реальная проблема», — говорится в заявлении организации.

Другая проблема, на которую не все обращают внимание, но она слишком часто встречается в сообществе Open Source, заключается в том, что программы привязаны к отдельным учетным записям разработчиков. Команда CII обнаружила, что семь из десяти наиболее часто используемых пакетов ПО выкладываются под индивидуальными учетными записями разработчиков. Что произойдет, если один из этих аккаунтов будет взломан? Узнает ли об этом вся цепочка поставок ПО? Взять, к примеру, случай, когда один из программистов удалил крошечную специализированную подпрограмму Node.js под названием «left-pad». Это вывело из строя тысячи программ JavaScript npm, поэтому об инциденте стало известно.

Но бывают инциденты о которых известно не так много. Имел место случай, когда хакер получил доступ к популярной JavaScript-библиотеке Event-Stream и внедрил в ее код бэкдор для кражи биткоинов. Сколько их было украдено — установить не удалось. Возможно, сумма ущерба так и останется неизвестной. Очевидно, что персональные учетные записи разработчиков нуждаются в большей защите. Программа CII по идентификации участников Open Source и Trust and Security Initiative, которую инициировал Linix Foundation, направлены на повышение уровня безопасности учетных записей разработчиков и повышение их ИБ-грамотности.

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

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

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

«Определение наиболее распространенных компонентов FOSS в экосистемах коммерческого ПО в сочетании с четким пониманием уровня его безопасности, знания жизни сообществ, которые его поддерживают — это первые и важнейшие шаги. Кроме того, коммерческие организации могут внести свой вклад, проводя внутренний анализ применения Open Source и активно взаимодействуя с соответствующими сообществами для обеспечения безопасности и долговечности компонентов от которых они зависят», — добавил главный стратег по безопасности Synopsys Cybersecurity Research Center Тим Макки.

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

Источник.

Версия для печати1241 просмотр.
Оцените статью по: