Создатели системы управления лицензиями White Source собрали показательную статистику, демонстрирующую, что больше 2/3 софтверных проектов используют открытые программные компоненты. Однако, к сожалению, многие из них давно устарели и содержат уязвимости.
White Source - система управления лицензиями, рассчитанная в первую очередь на продукты Open Source. Разработчики системы, одноименная компания White Source Software, предлагает своим клиентам активное оповещение о выходе новых версий библиотек и фреймворков, чтобы помочь им поддерживать безопасность и вовремя исправлять уязвимости в своем ПО.
По данным, собранным компанией, около 85% проектов, использующих её систему, содержат в себе устаревшие Open Source-компоненты, для которых доказано наличие угроз безопасности. Причем 14% проектов не обновляют их даже после предупреждения, отмечает команда White Source.
С точки зрения безопасности, программное обеспечение с открытым кодом беспрепятственно доступно хакерам, которые могут анализировать его код и выявлять уязвимости. Затем эти уязвимости оперативно устраняются сообществом, однако выход обновлений безопасности оповещает других злоумышленников об их наличии, что создает риск для пользователей приложений, которые не получают своевременных «заплаток».
White Source - не первые, кто бьёт тревогу в связи с потенциальным риском от использования открытых компонентов. В марте 2012 г. аналогичным заявлением всколыхнули сообщество компании Sonatype и Aspect Security, подсчитавшие, что 80% приложений, применяющихся в крупном бизнесе, используют уязвимые технологии с открытым кодом. Среди таковых оказались довольно популярные фреймворки, такие как Spring MVC или Struts.
Компании порекомендовали и возможное решение проблемы: модули автоматического оповещения об обновлениях в рамках самого открытого компонента (для пользователей), или какого-либо инструмента управления проектом (для самих разработчиков). В мире коммерческого ПО такое оповещение о новых версиях и исправлениях является обычным делом - любому пользователю Windows знакомы патчи, обновления сервис-паков и даже мероприятия вроде Microsoft Patch Tuesday, когда продукты редмондского гиганта по всему миру получают обновления безопасности.
В мире Open Source, в свою очередь, управление обновлениями не вполне обеспечено чисто технически, заявляют White Source. Причина халатности в обновлениях достаточно банальна - у разработчиков не хватает ни мотивации, ни инструментов, чтобы постоянно отслеживать обновления компонентов своего ПО. Известно, что инструменты отслеживания обновлений компонентов в своём арсенале имеют только 32% Open Source-проектов.
White Source Software представила первый специализированный продукт для решения проблемы, поднятой Aspect Security и Sonatype. Компания интегрировала в свою систему управления лицензиями модуль автоматических оповещений об обновлении открытых компонентов. Модуль настраивается индивидуально для каждого проекта и каждого клиента, что избавляет разработчиков от необходимости фильтровать оповещения, не относящиеся к компонентам, которыми они не пользуются.
Услуга уже пользуется достаточной популярностью среди клиентов White Source и постепенно выходит за рамки клиентской базы одной фирмы. Генеральный директор White Source Software Реми Сасс (Remi Sass) рассказал, что система White Source уже интегрирована с целым рядом инструментов управления разработкой, пользователи которых заинтересованы в том, чтобы получать подобные оповещения. Среди них - Apache Maven и Ant, Jenkins, JetBrains TeamCity, Red Hat OpenShift и JFrog Artifactory.
Знаем-знаем кто эти пасквили заказывает. Можно подумать, что закрытые компоненты неуязвимы. ;) Просто в свободном софте быстрее ошибки находят, а дальше уже личное дело разработчика конечной программы следить за безопасностью или нет.
>> Знаем-знаем кто эти пасквили заказывает. Можно подумать, что закрытые компоненты неуязвимы. ;) Просто в свободном софте быстрее ошибки находят, а дальше уже личное дело разработчика конечной программы следить за безопасностью или нет.
Так или иначе, но у проприетарных разработчиков отношение к безопасности куда более серьёзное. Я уже многократно упоминал мелкогмягкий Secure Development Lifecycle, который они сами (и другие) используют для разработки более безопасного ПО. В это время на сайте GNU, несмотря на наличие статей про стиль оформления кода, ничего про правила написания _безопасного кода_ нет вообще.
К тому же, вы забываете, что уязвимости в коде ищут не только его же разработчики, но и сторонние эксперты. А это уже от свободности/несвободности кода не зависит.
В идеале, нужно взять, достать некоторое количество как свободных, так и несвободных, продуктов, найти количество ошибок в каждом и сравнить, кто именно пишет более качественный код -- свободные разработчики или несвободные.
«К тому же, вы забываете, что уязвимости в коде ищут не только его же разработчики, но и сторонние эксперты. А это уже от свободности/несвободности кода не зависит.»
— Не считаете свою мысль противоречивой?
Как будут сторонние эксперты искать уязвимости в коде, если этот самый код недоступен?
Сильно заинтересованные в поиске уязвимостей "сторонние эксперты", конечно и дизассемблировать смогут что угодно. И пользователь виндовса получит очередную "педофилию" во весь экран, с требованием денег. Или его комп по-тихому пополнит ряды очередного много-тыщщекомпового виндозного бот-нета.
А легальным экспертам по безопасности, вообще-то, по лицензиям микрософта даже дизассемблировать запрещено — этих экспертов и засудят в первую очередь.
Кода нет, дизассемблировать нельзя. О каких "сторонних экспертах" речь – совершенно не понятно!
Да, микрософт может ещё пару человек нанять, или даже десять. Но это принципиально ничего не меняет.
>> Как будут сторонние эксперты искать уязвимости в коде, если этот самый код недоступен?
Да, через то самое дизассемблирование. Хотя, кроме него, тоже есть методы обнаружения дыр. Например, фаззинг -- отправка всякой сомнительной информации на вход с надеждой обнаружить некорректное поведение на выходе.
>> А легальным экспертам по безопасности, вообще-то, по лицензиям микрософта даже дизассемблировать запрещено — этих экспертов и засудят в первую очередь.
Это когда эксперта по безопасности судили за нахождение (и информирование разработчиков о) уязвимости в продукте? Это же в первую очередь выгодно разработчикам, которые узнают о том, где они допустили уязвимость.
К тому же, чтобы разработчик мог взять и успешно засудить эксперта, разработчику нужно будет доказать, что уязвимость эксперт нашёл именно через дизассемблирование кода, что практически невозможно.
Этот участок лицензионных соглашений предназначен в основном для того, чтобы другие компании не сдирали алгоритмы с дизассемблированного кода, где факт дизассемблирования можно реально доказать в суде (через схожесть кода, например).
Отправить комментарий