Программы с открытым исходным кодом что это

Конспект презентации партнёра Andreessen Horowitz Питера Левина.

4798 просмотров

На графике ниже видно, что за последние 30 лет основано около 200 компаний, в основе которых лежит открытый исходный код.

В совокупности эти предприятия привлекли более $10 млрд капитала, при этом стоимость сделок за последние десять лет выросла. Три четверти компаний и 80% привлечённого капитала появились после 2005 года. Левин считает, что это только начало.

В 2008 году, когда Sun Microsystems приобрела MySQL за $1 млрд, Левин был убеждён: это потолок для любой компании с открытым исходным кодом. Но Cloudera, MongoDB, Mulesoft, Elastic и GitHub стали частью многомиллиардных сделок и вышли на биржу.

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

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

В чем смысл open source?

История открытого исходного кода
Исходный код 0.0 — эпоха «бесплатных программ»

Специалисты и любители стали разрабатывать код и делиться им бесплатно в середине 1970-х годов; философия того времени: программами надо делиться.

Левин работал в Фонде открытых программ Массачусетского технологического института, где, по его словам, не было зарплаты, а деньги сотрудники получали в виде исследовательских грантов.

Исходный код 1.0 — эпоха поддержки и услуг

С появлением Linux в 1991 году открытый исходный код доказал свою важность и оказался лучшим и более быстрым способом разработки основных программных технологий. Тогда же компании начали первые эксперименты по извлечению прибыли из открытого кода.

В 1998 году появились первые бизнес-модели (Red Hat, MySQL), которые предоставляли платную поддержку и различные услуги, оставляя программное обеспечение бесплатным. Однако гиганты вроде Red Hat и Microsoft давали понять, что открытый исходный код не станет таким же экономически выгодным, как закрытый.

Исходный код 2.0 — облачные программы и открытые технологии

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

Пользователю всё равно, открытый код лежит в основе программы или нет, считает Левин. Это привело к экономическому уравниванию компаний с закрытым и открытым исходным кодом.

Если в 2001 году генеральный директор Microsoft Стив Балмер называл открытый код «злокачественной опухолью», то теперь компания сама использует технологии открытого исходного кода и вкладывается в развитие подобных проектов.

Благотворный цикл открытого кода

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

ТОП ПРОГРАММ с открытым кодом, о которых ты не знал

Однако полностью потенциал открытого исходного кода раскрывается тогда, когда технологические инновации сочетаются с бизнес-инновациями. Без таких бизнес-моделей, как платная поддержка, Open Core и SaaS, открытый код не стал бы популярным.

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

От чего зависит успех бизнеса

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

1. Соответствие проекта сообществу . Проект должен создать вокруг себя сообщество разработчиков, которые активно участвуют в создании базы открытого исходного кода. Соответствие можно изменить звёздами GitHub, коммитами, запросами на включение кода или ростом числа участников.
2. Соответствие продукта рынку . Программное обеспечение должно быть привлекательным для пользователя. Это измеряется количеством загрузок и использованием.
3. Соответствие стоимости продукта рынку . Клиенты должны хотеть платить за ваше предложение. Успех здесь измеряется доходом.

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

Соответствие продукта сообществу

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

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

Соответствие продукта рынку

Когда у проекта появляются руководитель и активная группа соавторов, следующий шаг — соответствие продукта рынку. Руководитель должен понимать, какую проблему решает их программа, кому необходимо решение и какие альтернативы есть на рынке.

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

Работая над соответствием продукта рынку, важно подумать, как обеспечить ценность продукта, за которую пользователь будет готов платить. Здесь автор отмечает одну распространённую ошибку: иногда продукт становится слишком хорошим.

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

Соответствие стоимости продукта рынку

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

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

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

Это не исчерпывающий список, но вот для каких функциональностей компании смогли определить рыночную стоимость продукта:

• Обеспечение надёжности, эксплуатационной готовности и безопасности продукта.
• Инструменты и дополнения.
• Определение качественной работы.
• Контрольные испытания.
• Сервисное обслуживание.

Выбор бизнес-модели
Модель «Поддержка и услуги»

Модель эпохи «Исходный код 1.0», и компания Red Hat здесь достигла невероятных масштабов и прочно заняла долю рынка. Если компания решит пойти по этому пути, то, считает автор, конкуренции с Red Hat не избежать.

Модель Open Core

Для локального программного обеспечения. Левин предупреждает о возможном возникновении проблемы с отчуждением сообщества при определении того, какие функции принадлежат к какому коду, открытому или проприетарному. Главная ловушка — сообщество решает, что ему не нравится проприетарная сторона кода, и оно разрабатывает собственный новый проект с той же кодовой базой.

SaaS-модель

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

Облако и конкурентное преимущество

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

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

Сам код, считает Левин, — не конкурентное преимущество. Главное — сообщество и подход компании к развитию. Независимые фирмы с открытым исходным кодом имеют три основных конкурентных преимущества:

1. Корпоративные клиенты не хотят зависеть от поставщика.
2. Они хотят покупать у тех людей, которые написали код.
3. Крупные компании не имеют того опыта, который есть у компаний с открытым кодом.

Три этих пункта вместе становятся конкурентным преимуществом компании, и именно поэтому общедоступные облака не вытеснили компании с открытым исходным кодом.

Далее Левин рассматривает, как выстроить организацию на основе трёх столпов, упомянутых выше.

Выход на рынок и воронка продаж

Левин рассматривает путь от создания кода до выхода компании на рынок с помощью воронки продаж со своими особенностями. Он выделяет четыре стадии:

1. Управление сообществом разработчиков повышает осведомлённость и интерес к вашему продукту.
2. Эффективное управление продуктом ведёт к созданию базы пользователей.
3. Появление потенциальных клиентов и развитие бизнеса позволяет оценить намерение пользователей определить потенциальную стоимость и возможность продаж.
4. Самообслуживание и продажа услуг обеспечивают и повышают ценность платного продукта или услуги.

Стадия первая: осведомлённость и интерес — управление сообществом разработчиков

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

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

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

В качестве примера автор приводит собственную компанию XenSource. Показатели загрузок были неточными, потому что включали в себя множество начатых, но не завершённых загрузок.

Стадия вторая: рассмотрение — управление продуктом

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

Что касается самого продукта, необходима аналитика, которая поможет понять пользователей и предсказать, сколько из них превратятся в покупателей.

Это сложный процесс, предупреждает автор, и оптимальная грань между бесплатным и платным определяется методом проб и ошибок. Для многих создателей открытого исходного кода этот эксперимент с продуктом бесконечный, и успех выхода на рынок зависит от постоянной обратной связи.

Стадия третья: оценка и намерение — привлечение клиентов и развитие бизнеса

Первая часть этой стадии — исходящий маркетинг, который должен отдавать приоритет кампаниям, ориентированным на конкретные сегменты рынка.

Обратив внимание на пользователей, вы узнаете, какие профессионалы и отделы используют продукт, их интересы. Затем исходящий маркетинг нацеливается на разработчиков или ИТ-специалистов, которым ваш продукт покажется ценным.

Далее идёт работа по развитию продаж. Представители отдела продаж должны проявлять интерес к пользователям, тому, что они делают с продуктом.

Привлекаемых клиентов можно разделить на группы, ответив на два вопроса:

1. Какую организацию представляет разработчик или пользователь.
2. Использует ли пользователь ваш проект для чего-то, связанного с более крупной корпоративной целью.

Источник: vc.ru

ПО с открытым исходным кодом: почему сегодня это особенно опасно и как защититься?

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

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

Директор Центра Solar appScreener компании «Ростелеком-Солар» Даниил Чернов рассказал, какие сюрпризы таит Open Source и что делать разработчикам и ИБ-специалистам, чтобы минимизировать киберриски от его использования.

Что такое Open Source?

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

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

Возросшие риски

Главная опасность популярных решений с открытым исходным кодом связана с тем, что разработчики широко применяют их внутри других приложений. Уязвимость в том или ином бесплатном компоненте может привести к серьезным угрозам информационной безопасности по всему миру. Достаточно вспомнить недавнюю историю с Apache Log4j – библиотекой, которая используется миллионами корпоративных приложений и Java-серверами. Обнаруженная уязвимость позволяла злоумышленникам выполнить произвольный код на сервере или устройстве, чтобы похитить данные или внедрить вредоносную программу. Еще раньше, в 2014 году, серьезная уязвимость Heartbleed была найдена в компоненте с открытым исходным кодом OpenSSL, которая использовалась практически на всех веб-сайтах, обрабатывающих платежи с помощью банковской карты.

Уязвимость в том или ином бесплатном компоненте может привести к серьезным угрозам информационной безопасности

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

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

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

Уход зарубежных вендоров ПО провоцирует рост спроса на Open Source

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

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

Как защититься?

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

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

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

В обоих случаях большое значение имеет минимизация количества ложных срабатываний. Если они будут частыми, использование инструмента анализа будет увеличить нагрузку как на разработчиков, так и на специалистов по информационной безопасности. Так, в статическом анализаторе кода Solar appScreener компании «Ростелеком-Солар» для минимизации количества ложных срабатываний и пропущенных уязвимостей используется запатентованная вендором технология Fuzzy Logic Engine. Она минимизирует количество ложных срабатываний, задействуя математический аппарат нечеткой логики и является технологическим ноу-хау.

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

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

Источник: www.tadviser.ru

Безопасность Open Source: современные тенденции

Популярность платформ контейнеризации и сам подход к разработке систем через микросервисы подняли новую волну спроса на решения Open Source. Вместе с этим начал всплывать и былой спор: что безопаснее — проприетарные решения или открытый код?

1. Введение
2. «Плюшки» за «жуков»
3. О безопасности Open Source
4. Преимущества и недостатки использования решений Open Source
5. О Software Composition Analyzers
6. Выводы

Введение

Подходы к информационной безопасности в мире ИТ со временем эволюционируют и развиваются. Вопросы цифровой безопасности уже не стоят на дальнем плане в приоритетах большинства компаний и продуктов. Репутационные риски стали не эфемерной угрозой, а реальным бизнес-инструментом. Вспомним, например, что после выявления системных проблем ИБ в своих микропроцессорах компания Intel заказала аналогичное исследование для процессоров AMD. Крупные корпорации активно вкладываются в программы Bug Bounty, а также развивают процессы управления информационной безопасностью и безопасной разработки.

Визионер мирового рынка DevSecOps компания Sonatype совместно с партнёрами выпустила очередной анализ рынка ПО с открытым кодом — State of the Software Supply Chain 2019 (SSSC). Согласно 5-му выпуску SSSC, сохраняются тенденции активного роста распространения Open Source. Растущий спрос на инновации ускорил внедрение автоматизированных конвейеров разработки ПО (development pipelines), одновременно поднимая на новые высоты распространение Open Source во всех экосистемах.

Исследователи отметили, что 95 % кода современных веб-приложений составляют компоненты, загруженные из npm-репозитория. Большинство команд программистов опрошенных компаний включает обновление зависимостей в свой ежедневный процесс разработки. Таким образом, количество включений уязвимого ПО в проекты постепенно снижается.

В исследовании рассматривается важный класс метрик — время обновления и исправления компонентов и зависимостей. Приводятся выводы, что своевременная плановая установка общих обновлений сокращает время на исправление найденных в продукте уязвимостей. То есть сокращение времени установки обновлений, не связанных с безопасностью — MTTU (Mean Time To Update), — снижает также время исправления уязвимостей в продукте — MTTR (Mean Time To Remediate). Для повышения общей защищённости эксперты рекомендуют всегда обновлять пакеты и их зависимости до актуальных версий.

Это подтверждается цитатой Джереми Лонга, основателя The OWASP Dependency Check: проект предполагает, что «только 25 % организаций сообщают об уязвимостях пользователям, и только 10 % уязвимостей зарегистрированы как Common Vulnerabilities and Exposures (CVE)». В качестве примера Лонг приводит уязвимость безопасности, обнаруженную в PrimeFaces — инфраструктуре пользовательского интерфейса Java.

Проект PrimeFaces узнал об уязвимости и устранил её в феврале 2016 года. В 2017 году этой уязвимости была назначена CVE (CVE-2017-1000486). Затем CVE была опубликована в национальном каталоге 3 января 2018 г. После публикации CVE криптомайнеры начали активно эксплуатировать уязвимые версии компонента. Разработчики, которые практиковали обновление до последних выпущенных версий PrimeFaces, подвергались меньшему риску, чем те их коллеги, которые полагались на публикацию CVE для запуска процесса по исправлению.

Рисунок 1. Инфографика основных выводов исследования State of the Software Supply Chain 2019

Если в цифрах, то основные выводы отчёта — следующие:

• Распространение компонентов Open Source в коммерческих и промышленных средах показало 75-процентный рост (рис. 2) — во многом благодаря распространению JavaScript и открытых репозиториев пакетов и библиотек, а также активному сообществу разработчиков и росту версионности как для исправления ошибок, так и для внедрения функциональности.

Рисунок 2. Динамика распространения компонентов Open Source в коммерческих и промышленных средах, 2017–2019 гг.

• Проекты, где обновление происходит регулярно, а не по обнародованию CVE и выходу соответствующего патча, показывают более защищённый статус продукта (рис. 3). В целом отмечен тренд на снижение использования уязвимых компонентов в проектах (рис. 4).

Рисунок 3. Сравнение среднего времени на обновление и установку программных исправлений продуктов Open Source

Рисунок 4. Динамика использования компонентов с известными уязвимостями

• Количество подтверждённых взломов открытого ПО по сравнению с 2014 годом выросло на 71 %. Однако в сравнении с 2018 годом имеется тренд на понижение, который, как предполагают эксперты, формируется благодаря внедрению процессов цифровой гигиены в содержании пакетов (Open Source Hygiene) (рис. 5).

Рисунок 5. Предполагаемые или подтверждённые взломы, связанные с открытым исходным кодом, в течение четырёх лет

«Плюшки» за «жуков»

С одной стороны, корпорации усиленно развивают защищённость своих проприетарных продуктов. Один только рост премии за найденные уязвимости — программы Bug Bounty — за последние годы свидетельствует о росте ценности информационной безопасности в глазах высшего управленческого состава ИТ-компаний. По данным платформы HackerOne, статистика премий и согласования вознаграждений в области обмена данными об уязвимостях к 2020 году уже подошла к отметке в 100 млн долларов США (рис. 6). С другой стороны, популярность проприетарных продуктов и низкая техническая квалификация их пользователей всё ещё предоставляют злоумышленникам широкие возможности.

Рисунок 6. Динамика вознаграждений Bug Bounty, полученных через платформу HackerOne

Но надо отметить, что программа Bug Bounty оказывает положительное влияние и на решения Open Source. Программы Bug Bounty открывают не только гиганты проприетарных решений, такие как Microsoft и Apple, но и те корпорации, чьим продуктом являются сервисы и микросервисы — например, Facebook или Google. Эти компании активно используют именно ПО с открытым кодом и собственные разработки. Таким образом, внимание сообщества этичных хакеров привлечено к решениям Open Source не только репутационными, но и финансовыми «плюшками».

Что касается устранения найденных уязвимостей — для ПО с открытым кодом вопросы репутации более важны, чем для крупных проприетарных гигантов. Активный (идейный) пользователь Apple не изменит платформу, несмотря на любые найденные в ней уязвимости, так как такая миграция для него является слишком трудоёмкой. С другой стороны, сменить одно открытое ПО на другое, более качественно обслуживаемое командой разработчиков — куда более простая задача. Поэтому оперативный патчинг для Open Source более важен. Если обратиться к примерам, то обнаруженная в этом году уязвимость ZeroLogon была обнародована в августе, тогда же вышел патч от Microsoft для этой уязвимости, и уже через месяц был опубликован патч от команды Samba, так как они используют этот же протокол (NetLogon) для сетевого общения с компонентами домена.

О безопасности Open Source

Организация Linux Foundation совместно с GitHub, Google, IBM, JPMorgan Chase, Microsoft, NCC Group, OWASP Foundation и Red Hat учредила новый совместный проект OpenSSF (Open Source Security Foundation), целью которого является повышение безопасности ПО с открытым кодом. OpenSSF продолжает развитие инициатив Core Infrastructure Initiative и Open Source Security Coalition и включает в свои функции:

• раскрытие информации об уязвимостях и распространение исправлений;
• разработку инструментов для обеспечения безопасности;
• разработку и публикацию лучших практик по ИБ при организации разработки;
• выявление угроз в открытом ПО, аудит и усиление ИБ критически важных открытых проектов;
• организацию идентификации и подтверждения личности разработчиков для исключения внесения нелегитимных изменений в код.

Это — новый проект, и все процессы пока находятся в инкубационном статусе. К проекту уже присоединились GitLab, HackerOne, Intel, Uber, VMware, ElevenPaths, Okta, Purdue, SAFECode, StackHawk и Trail of Bits.

Linux Foundation’s Core Infrastructure Initiative (CII) и Гарвардская лаборатория инноваций (Laboratory for Innovation Science at Harvard, LISH) в начале 2020 года выпустили вторую перепись важного ПО с открытым кодом (Census II of Open Source Software), в которой исследуются наиболее важные и часто используемые свободно распространяемые пакеты по вопросам ИБ. В том числе пропагандируется подход на основе гигиены доставки компонентов в свой код и их использования (Supply Chain Hygiene), которая подразумевает следующие принципы:

• использовать меньшее разнообразие компонентов;
• использовать только высококачественные компоненты, что означает отказ в крупных проектах от «сырых» компонентов в пользу стабильных, даже если последние уступают по функциональности;
• постоянно контролировать и информировать, какие компоненты используются и где.

Также существует ряд проектов, занимающихся регулярным исследованием уровня защищённости открытого ПО. Например, проект Coverity в сотрудничестве со Стэнфордским университетом, а ныне анализатор кода компании Synopsys — яркий пример предприятия по систематическим исследованиям Open Source и один из лидеров в данном сегменте. Компания проводит автоматическое обнаружение дефектов и критических типов ошибок в открытом ПО, уровень качества и безопасности в их идеологии измеряется ступенями. Ступени не имеют окончательного значения и могут изменяться по мере того, как Coverity выпускает новые инструменты. Ранги основаны на прогрессе исправления проблем, обнаруженных по результатам анализа, и степени сотрудничества разработчика ПО с Coverity. Ранги начинаются со ступени 0 и в настоящее время идут до ступени 2:

• Ступень 0. Проект был проанализирован инфраструктурой Coverity Scan, но ни один представитель сообщества ПО с открытым исходным кодом не сообщил о результатах.
• Ступень 1. Происходит сотрудничество между Coverity и командой разработчиков. ПО анализируется с помощью подмножества функций сканирования, чтобы не перегружать команду разработчиков.
• Ступень 2. Было проанализировано 11 проектов, получивших статус «Rung 2», в результате чего в первый год сканирования было достигнуто нулевое значение количества дефектов. Эти проекты — AMANDA, ntp, OpenPAM, OpenVPN, Overdose, Perl, PHP, Postfix, Python, Samba и tcl.

Ресурс Coverity открыт, и с его помощью можно проверить необходимый пакет Open Source на наличие опасных уязвимостей и уровень поддержки проекта разработчиками. Пример анализа для одного из пакетов bind приведён на рис. 7.

Рисунок 7. Анализ ПО bind через проект Synopsys Coverity

Есть несколько аналогичных проектов, занимающихся регулярным тестированием приложений и библиотек Open Source — например, PVS-Studio. Для веб-приложений существует сообщество Open Web Application Security Project (OWASP) — открытый проект по обеспечению их безопасности.

Преимущества и недостатки использования решений Open Source

Переход на использование решений Open Source, как и любая другая парадигма, имеет свои преимущества и недостатки (см. табл. 1).

Таблица 1. Преимущества и недостатки перехода на решения с открытым исходным кодом

Преимущества	Недостатки
Проприетарное ПО вынуждает пользователя принять тот уровень безопасности, который поставщик ПО готов предоставить, а также скорость выпуска исправлений и обновлений. Для проектов Open Source в области ИБ репутационные риски более высоки, поэтому уважающие себя проекты оперативно исправляют критически важные для ИБ уязвимости.	Нужны ещё более чёткие процессы по администрированию и — особенно — обновлению ПО, отслеживать обновления придётся самостоятельно. К тому же открытость кода, в том числе патчей, делает необходимость оперативного обновления ещё более острой. Хакеры тоже умеют читать код и могут понять из него, какую именно уязвимость он закрывает. Проприетарные решения обновляются автоматически или по оповещению от производителя, причём включая компоненты Open Source внутри системы.
Открытый код даёт возможность его самостоятельного анализа и доработки. При достаточно большом штате администраторов и разработчиков это — безусловный плюс.	Нет технической поддержки, особенно пользовательского уровня. В основном у проектов есть разработчики (мейнтейнеры) и сообщество, но это — не техническая поддержка, которая возможна с проприетарным ПО. Имеется небольшое количество проектов с платной поддержкой и аналогичными уровнями, как в проприетарных компаниях, например у некоторых версий платформы Linux.
В коде Open Source нет программных закладок, бэкдоров и другой скрытой функциональности. Нет жёсткой зависимости от платформы. Можно бесконечно масштабироваться без лицензионных ограничений. Вопрос — только в аппаратном обеспечении.	Наличие возможности анализа кода может дать ложное чувство безопасности. Если большое число аналитиков и пользователей ПО исследуют исходный код, это не гарантирует, что все недостатки безопасности будут обнаружены и исправлены.

О Software Composition Analyzers

Для осуществления мониторинга и определения потенциальных рисков для компонентов Open Source, используемых в проектах, существует класс решений Software Composition Analyzers — SCA. Основные функции, реализуемые SCA-провайдерами, включают в себя:

• контроль и уведомление на раннем этапе жизненного цикла ПО (SDLC) о рисках, связанных с безопасностью или лицензиями используемых компонентов Open Source и библиотек, и о методах их устранения;
• создание согласованных политик для разных бизнес-единиц и типов приложений;
• создание среды наглядности стратегических рисков для специалистов по безопасности и руководителей по информационной безопасности.

Компания Forrester произвела исследование основных SCA-поставщиков и определила 10 наиболее значимых из них в 2019 г. Это — Flexera, FOSSA, GitLab, JFrog, Snyk, Sonatype, Synopsys, Veracode, WhiteHat Security и WhiteSource. Исследователи проанализировали, оценили их и составили традиционную шкалу для помощи специалистам по безопасности в выборе подходящей платформы (рис. 8).

Рисунок 8. SCA-провайдеры: Forrester Wave, 2019 г.

Выводы

Если ваш продукт не является смежным с ИТ (а, например, сфокусирован на юридических услугах) и ваш ИТ-штат ограничен, решения Open Source, скорее всего, принесут вам больше проблем. Если вы — технологичная компания с собственным штатом разработчиков, то, скорее всего, вопрос о применении открытого ПО для вас уже не стоит — вы давно и успешно его используете. К тому же эти две идеологии неплохо совмещаются.

Для минимизации рисков в данном случае, как и в любой другой сфере, важна грамотная организация процессов, ИТ- и ИБ-гигиены, равно как и внедрение современных технических практик, включая интеграцию процесса обновления зависимостей в повседневную работу команды разработчиков (Update Hygiene), а также тщательный осознанный подбор включаемых в проект компонентов.

Источник: www.anti-malware.ru