почему программы с открытым исходным кодом могут быть опасными для шлюмберже
Юридические последствия использования открытого кода (Open Source)
Владислав Макаренко, CEO antwort LAW
Использование свободного или открытого кода при разработке нового программного обеспечения является распространенным, практически повсеместным явлением в современной IT индустрии. Такой код выгоден как разработчикам, так и заказчикам, поскольку значительно экономит время, силы и средства на разработку новых продуктов. При этом, использование свободного или открытого кода имеет свои юридические правила и последствия, которые могут существенно влиять на дальнейшую судьбу софта.Эта статья обязательна к прочтению всеми разработчиками и девелоперами, которые в своей работе используют открытый код, а также потенциальным заказчикам программного обеспечения.
Следует сразу отметить, что в данной статье мы будем рассматривать под открытым кодом (Open Source) большую группу свободных (Free Software) и открытых кодов (Open-Source Software) без разделения на отдельные подкатегории, т.к. для целей этой статьи такое разделение несущественно.
Любой открытый код доступен для просмотра, изучения использования или изменения, и, как правило, размещается в открытых публичных репозиториях вместе с информацией о возможном применении и условиях использования. Именно условия использования таких кодов представляют наибольший интерес с точки зрения права, поскольку авторы открытого кода не отказываются от своих прав, а предоставляют его другим на условиях открытых лицензий.
Существует большое разнообразие видов лицензий на открытый код, и различия между ними являются очень существенными. Тем не менее, в подавляющем большинстве случаев есть одно крайне важное требование всех лицензиатов – упоминание об использовании этого открытого кода (например, в формате Third Party Software Attribution Notice) и включение в текст конечной лицензии определенных условий.
Далее мы более детально поговорим про эти обязательства, и как правильно организовать работу с открытым кодом, поскольку последствия от невыполнения условий лицензии на открытый софт могут быть не менее серьезны, чем от нарушения условия любой другой лицензии.
Главным условием, которое позволит вам избежать последующих сложностей при использовании открытого кода, является скрупулёзный сбор информации про весь открытый код, используемый при работе над вашим софтом.Разумеется, реализовать это могут только сами разработчики, поскольку только они знают, какие именно открытые коды были использованы при работе над программным обеспечением. Если вы являетесь заказчиком софта, то в контрактах с разработчиками следует обязательно включать пункт о том, что разработчики должны передать вам информацию о всех открытых кодах, использованных ими в работе. Разумеется, такое обязательство должно сопровождаться описанием ответственности за его нарушение, иначе в нем теряется всякий смысл.
Как правило, такая информация передается в отдельном приложении к договору о разработке, и оформляется в виде таблицы с указанием названия открытого кода, ссылки на репозиторий, из которого такой код взят, и типа лицензии, на основании которой открытый код был размещен его автором.
Информация о названии лицензии, как и сам текст лицензии, в подавляющем большинстве случаем содержится в том же репозитории в виде текстового файла TXT или в формате Word. Само название файла может быть разным, но, как правило это классические названия Readme или License.
Идентифицировать весь открытый код, использованный в разработке вашего софта – важнейший этап, от которого зависит вся дальнейшая работа с производным кодом, т.е. тем самым софтом, который вы в итоге разработали или получили. Крупные IT компании даже проводят отдельную экспертизу кодов, чтобы убедиться в том, что был указан весь использованный открытый код и ничего не пропущено.
Ранее мы уже упоминали о том, что существует большие разнообразие лицензий на открытый код, и отличия между ними могут быть довольно существенными. Среди наиболее популярных можно выделить такие типы лицензий как MIT, BSD, Apache 2.0, GNU GPL и т.д. – их очень много.
Не вдаваясь в детали каждой отдельно-взятой лицензии, стоит выделить два основных вида таких лицензий — copyleft-лицензии и permissive-лицензии.
Поскольку большинство программ разрабатываются с целью их дальнейшего использования для получения выгоды, то их заказчикам стоит избегать использования copyleft-лицензий, и вот почему. Сopyleft-лицензии (например, лицензии GPL) предусматривают, что любой производный код (в частности, конечній код вашей программы) должен быть открытым для общественности на условиях GPL-лицензии, и при передаче прав на его использование необходимо прикладывать GPL-лицензию, уведомление об авторском праве и файл с открытым исходным кодом.
Таким образом, используя открытый код на основе copyleft-лицензии вы автоматически теряете возможность получить производный код в свое полное распоряжение и контролировать его последующее коммерческое использование.
Permissive-лицензии позволяют распространять производный код на условиях других лицензий, так что при разработке ПО они пользуются большей популярностью. В тоже время, использование открытого кода по Permissive-лицензии не означает отсутствие дополнительных требований, таких как упоминание ей автора и т.д.
Таким образом, сбор информации и анализ типов лицензий, используемых при разработке вашего софта, стоит проводить всем, кто использует открытый софт в своей работе, и для этого следует привлечь профессиональных юристов, которые смогут дать рекомендации по дальнейшему составлению конечной лицензии и использованию вашего софта.
Эксперты назвали небезопасный софт с открытым кодом
Несколько наиболее популярных компьютерных программ, созданных при помощи открытого кода (open source — программы, чей код доступен для изучения, просмотра и даже изменения; разработчики могут приспосабливать и заимствовать код для создания новой программы), содержат уязвимости, которые злоумышленники могут использовать для получения доступа к личным данным пользователей. К такому выводу пришли аналитики компании в сфере кибербезопасности «Ростелеком-Солар» в своем исследовании (есть у РБК).
Для сравнения уровня защищенности компания проверила приложения с открытым кодом в категориях «браузеры», «офисные пакеты», «графические редакторы», «текстовые редакторы», «программы восстановления данных», «редакторы диаграмм», «программы расширенного поиска файлов и папок в Windows», «программы для очистки компьютера», «эмуляторы видеоигр», которые оказались в топе по количеству скачиваний мобильных версий в Google Play. Часть исследуемых программ также есть в рейтинге лучшего софта с открытым кодом, составленном британским изданием Techradar.
В каком софте нашли больше всего уязвимостей и что из этого следует, разбирался РБК.
Критические уязвимости — пустые ключи шифрования, пустые пароли или конфиденциальные данные, размещенные в самом исходном коде, «Ростелеком-Солар» обнаружил в пяти из десяти проанализированных программ: Krita, Search Everything, Libre Office, Brave Browser и RetroArch. Эти уязвимости могут облегчить злоумышленникам доступ к конфиденциальным данным, хранящимся на компьютере пользователя в незашифрованном виде.
Наиболее слабые результаты показал эмулятор видеоигр RetroArch (0,8 балла из пяти возможных), у программы больше всего критических уязвимостей — 24. RetroArch позволяет запускать на платформе Android старые игры, которые были предназначены, например, для консолей PlayStation 1, Nintendo Entertainment System, GameBoy и др. Число пользователей этой программы не раскрывается, но по числу поисковых запросов за последние 12 месяцев она опережала другие аналогичные разработки, следует из данных Google Trends.
«Неожиданно слабыми» авторы исследования назвали результаты браузера с открытым кодом Brave Browser, созданного соучредителем компании Mozilla Project и создателем JavaScript Бренданом Эйхом. Как заявлено на сайте Brave Browser, он ориентирован на конфиденциальность и позволяет пользователям получать оплату в токенах Basic Attention (BAT) за просмотр рекламы. Аудитория браузера по состоянию на начало ноября этого года равнялась 20 млн активных пользователей в месяц и до 7 млн в день. В исследовании «Ростелеком-Солар» эта программа получила 1,3 балла: в просканированном ядре Brave Browser критические уязвимости в коде встречаются 15 раз, такой уровень защищенности считается ниже среднего по рынку. Подобное обстоятельство не позволяет считать это приложение безопасным для использования, резюмировали в «Ростелеком-Солар».
В чем конкретно заключаются уязвимости, в исследовании не уточняется из соображений безопасности. По словам представителя компании, ее технические специалисты направили результаты исследования в сообщество пользователей и разработчиков открытого ПО.
Лидером рейтинга защищенности приложений open source для компьютера стала программа для восстановления данных TestDisk & PhotoRec. Она не содержит критических уязвимостей в коде и имеет минимальное количество уязвимостей среднего уровня среди всех исследованных приложений. Чуть больше уязвимостей средней критичности содержит бесплатный аналог Adobe Photoshop приложение GIMP. Уровень защищенности обеих программ аналитики оценили в 4,2 балла. На третьем месте оказалось ПО для создания диаграмм Dia (аналог Microsoft Visio) с уровнем защищенности 4,1 балла. Приложение для очистки операционной системы BleachBit и блокнот для разработчиков Notepad++ также показали достаточный уровень защищенности — 3,9 и 3,7 балла соответственно.
На что влияет уязвимость open source
Аудитория софта с открытым кодом не раскрывается. Однако эксперты венчурной компании Accel прогнозировали, что в 2021 году объем использования подобных продуктов в компаниях вырастет на 77%. «В целом около 80% кода в мире не пишется разработчиками самостоятельно, а заимствуется из сторонних открытых библиотек, — объяснил директор центра решений безопасности ПО «Ростелеком-Солар» Даниил Чернов. — Соответственно, и уязвимости кочуют из приложения в приложение. В России, как и в других странах, сообщество любителей свободного ПО многочисленно, это настоящая философия». Он напомнил, что много отечественных программ для десктопов разрабатывается с открытым исходным кодом, уровень безопасности этого ПО разный. «Те же самые уязвимости могут содержаться и в отечественном пользовательском ПО для компьютеров», — сделал вывод эксперт.
Руководитель направления «Информационная безопасность» ИТ-компании КРОК Андрей Заикин отметил, что наличие уязвимостей в классических приложениях open source — одна из ключевых проблем информационной безопасности. Значительная их часть появляется за счет использования открытых библиотек кода. Однако Заикин уточнил, что, если в «открытом» коде есть, например, десять уязвимостей, это не значит, что они будут присутствовать в отечественных программах, созданных на его базе. Это возможно, только если разработчик использует изначальный код полностью в неизменном виде.
По словам заместителя директора по продуктам «Новых облачных технологий» (разработчик «МойОфис») Петра Щеглова, чтобы программный продукт был безопасным, требуется наличие в компании-разработчике центра компетенций, который целенаправленно занимается вопросами кибербезопасности. В ПО с открытым кодом критические уязвимости могут не устранять годами, а перечисленные в исследовании типы ошибок подходят для внедрения зловредных приложений в компьютеры пользователей, перехвата и/или передачи конфиденциальных данных злоумышленникам, указал он.
Гендиректор «Базальт СПО» (разработчик отечественных операционных систем на базе Linux) Алексей Смирнов говорит, что чаще всего пользователи подобных программ не знают, что используют «открытый» софт: «Люди просто используют программу, будь то Firefox или LibreOffice, а не изучают ее лицензию. Тем более что есть много бесплатно распространяемых, но вовсе не свободных программ, например Adobe Acrobat Reader». При этом он не согласен с мнением, что открытые исходные коды приложений увеличивают уязвимость свободного софта. «Свободность программы не означает, что вы можете поправить код программы, установленной на чужом компьютере. Более того, уязвимости совместными усилиями быстрее находятся и исправляются», — считает Смирнов.
Открытый исходный код может быть не только полезным, но и опасным
Сегодня многие компании, разрабатывающие программное обеспечение, спеша вывести новые продукты на рынок, в значительной степени полагаются на программные компоненты Java с открытым исходным кодом. Зачастую это означает, что они скачивают открытый исходный код из публичных репозиториев, на которых разработчики делятся своими компонентами с другими пользователями. Компания Sonatype, управляющая одним из крупнейших открытых репозиториев Central Repository, разместила для разработчиков следующее сообщение: «Ваши компоненты с открытым исходным кодом могут быть небезопасны».
Только в прошлом году крупные компании, работающие в сферах программного обеспечения (ПО) и финансовых услуг, загрузили почти четверть миллиона компонентов. Согласно Sonatype, около 15,000 (или 7.5%) из этих компонентов имели известные уязвимости.
По существу, софтверные компании, использующие эти репозитории без надлежащих процедур контроля, встраивают ошибки и прочие изъяны прямо в программы, которые они распространяют и продают клиентам. Если представить, что клиент покупает такую программу для управления промышленным оборудованием (ICS) или автоматизированного диспетчерского управления и сбора данных (SCADA), то дальнейший сценарий становится намного страшнее.
 |
| Разработчики, плохо проверившие открытый исходный код, скаченный ими с бесплатных репозиториев и используемый в их продуктах, могут принести в свои компаний такие проблемы, как уязвимость Heartbleed. |
По данным Sonatype все может быть намного хуже: многие софтверные компании, внедрившие уязвимости в свои продукты, из-за плохой практики проверок не смогут сказать, какое из их приложений затронуто известной ошибкой.
Компании, держащие репозитории с открытым исходным кодом, и в частности, Central Repository, проверку качества выкладываемых компонентов не производят, они просто размещают их. Разработчики открытого кода должны сами давать гарантию, что их компоненты не содержат ошибок. В противном случае разработчики конечного программного продукта должны удостовериться, что в приобретаемых ими компонентах нет уязвимостей.
Согласно Лиаму О’Мурчу (Liam O’Murchu), ведущему научному сотруднику по безопасности в Symantec, использование открытого ПО не является безрисковым, и разработчики должны принимать это во внимание.
«Сегодня существует множество уязвимостей, и их выявление зависит от того, как используется программное обеспечение, – сказал О’Мурчу изданию Design News. – Недавней серьезной уязвимостью в области открытого программного обеспечения была Heartbleed в OpenSSL. Heartbleed позволила злоумышленникам получать полный контроль над вычислительными машинами, на которых были установлены программы с этой ошибкой. Другие уязвимости позволяют взломщикам красть информацию, получать управление над зараженными машинами или выводить их из строя».
Одним из решений может быть всеобщий запрет на использование компонентов с открытым исходным кодом, но для многих разработчиков это просто непрактично. Некоторые элементы с открытым кодом применяются почти повсеместно из-за их полезности, специализации и из-за того, что их достаточно трудно переписать с нуля.
Конкуренция в отрасли программного обеспечения зачастую означает, что задержки в выпуске продукции или обновлении версии просто недопустимы. Ответственность разработчиков, использующих материалы с открытым исходным кодом, заключается в том, чтобы гарантировать, что встроенные в фирменные продукты компоненты чисты и не содержат уязвимостей, и что они создали простой и эффективный способ уведомления клиентов об обнаруженных проблемах.
«Разработчики должны быть осведомлены о том, какое открытое ПО они используют, и должны контролировать эти проекты для уведомлений об уязвимостях, – сказал О’Мурчу. – Они также должны иметь план, чтобы при обнаружении в этих проектах уязвимостей правильно среагировать и выпустить исправления или обновления».
Планы действий имеют решающее значение для создателей ICS и SCADA, позволяя им избегать повторения Heartbleed, которая затронула бизнес крупных компаний, таких как Siemens и Innominate, и привела к ряду опасных кибер-атак, направленных на системы управления, – считает агентство ICS-CERT, являющееся частью Департамента внутренней безопасности США. Когда крупные цели, такие как банки, быстро исправили уязвимости, хакеры обратили свои взоры на менее очевидные, но не менее заманчивые жертвы, и промышленные системы оставались уязвимыми спустя еще несколько недель.
Перевод: Mikhail R по заказу РадиоЛоцман
Открытый исходный код — благо или троянский конь?
Сразу хочется сузить рамки — разговор идет о продаже программного продукта (php+MySQL).
Вопрос — (про)давать ли исходный код?
Аргументы в пользу закрытого кода.
— Подавляющему большинству клиентов нужно чтобы продукт работал и исходный код не нужен.
— При закрытом коде проще осуществлять тех. поддержку — клиент своими руками не залезет куда не надо и не породит новых уникальных ошибок, в которых хрен разберешься.
— Сложнее стырить исходный код. А точнее его можно получить, но вот что-то серьезное переделать в этом «исходнике» сложно — максимум сломать защиту, внести незначительные правки.
— Есть некоторая надежда разработчика, что закрытый код спасет от перепродажи его продукта лихими людьми.
— Есть легкая надежда, что купят продукт, потому как «сломать» не смогут, либо «ломанный» побоятся использовать.
— Народ (наш народ 🙂 ) привык что если код открыт, значит бесплатно!
Аргументы в пользу открытого кода.
— Иногда клиенту просто хочется иметь возможность взглянуть на код. То есть не обязательно даже его иметь, но чтобы возможность такая была. Это могут быть параноики безопасности в хорошем смысле или просто борцы за какие-то права.
— Клиент имеет возможность внести правки, причем весьма серьезные. Вплоть до потери совместимости с последующими версиями продукта (хотя вот это возможно уже в минус).
— Нет проблем с дешифратором закрытого кода. Не секрет, что такие проблемы встречаются (отсутствие Зенда и иже с ним, какие-то локальные глюки т.д.).
— Есть возможность построить сообщество разработчиков купивших скажем девелоперскую лицензию с доступом к открытому коду.
Добавлю немного конкретики.
Вопрос «открытого кода» интересует в связи с «внутрифирменной» дискуссией по поводу развития одного из наших продуктов (CNCat). Мы проходили разные стадии (открытый код, Зенд) и сейчас осуществляем обфрускейтивание (замену названий переменных на бессмысленные) и легкую шифрацию. Когда мы давали продукт в открытом коде и давали его бесплатно — много кто тырил код и на его основе делали свои продукты без всяких ссылок на нас. Что было немного обидно и сейчас не хочется на этом обжечься опять.
Однако правильное позиционирование открытого кода (АПИ, поддержка, контроль и т.д.) может дать нам приток сторонних разработчиков новых фич, мощную обратную связь, отладку — в общем новый импульс.
Дык хочется получить какие-то дополнительные аргументы или мысли по данному вопросу. Как бы Вы повели себя как клиент, как разработчик (конечно желательно чтобы Вы им являлись, чтоб не голословно)? Может есть какие в мире устоявшиеся теории и доказанные практикой подходы (типа фри версия закрыта, купленная открыта)?
Безопасность Open Source: современные тенденции
Популярность платформ контейнеризации и сам подход к разработке систем через микросервисы подняли новую волну спроса на решения Open Source. Вместе с этим начал всплывать и былой спор: что безопаснее — проприетарные решения или открытый код?
Введение
Подходы к информационной безопасности в мире ИТ со временем эволюционируют и развиваются. Вопросы цифровой безопасности уже не стоят на дальнем плане в приоритетах большинства компаний и продуктов. Репутационные риски стали не эфемерной угрозой, а реальным бизнес-инструментом. Вспомним, например, что после выявления системных проблем ИБ в своих микропроцессорах компания 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
Если в цифрах, то основные выводы отчёта — следующие:
Рисунок 2. Динамика распространения компонентов Open Source в коммерческих и промышленных средах, 2017–2019 гг.
Рисунок 3. Сравнение среднего времени на обновление и установку программных исправлений продуктов Open Source
Рисунок 4. Динамика использования компонентов с известными уязвимостями
Рисунок 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:
Ресурс 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-провайдерами, включают в себя:
Компания 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), а также тщательный осознанный подбор включаемых в проект компонентов.