USD 68 ЕВРО 76.76

Насколько безопасно ПО с открытым исходным кодом?

Аналитика

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

Если бы существовал приз за решение проблем, стоящих перед безопасностью систем с открытым исходным кодом, он бы достался Вернеру Коху, немецкому разработчику, который последние 18 лет трудился над тем, чтобы сохранить столп open source экосистемы — GNU Privacy Guard (GnuPG).

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

Тем не менее, Кох обнаружил, что с трудом сводит концы с концами в последние годы. По оценкам он собирал в среднем $25000 ежегодных пожертвований с 2001 года, но их не хватало, чтобы поддержать его усилия. Как сообщает Pro Publica, 53-летний Кох был близок к тому, чтобы бросить GnuPG, но, когда откровения Эдвард Сноудена потрясли мир, Кох решил сражаться дальше. «Я слишком большой идеалист», сказал он.

История имеет счастливый конец. После появления истории в ProPublica, доноры со всего мира бросились поддерживать Коха. Он легко собрал средства в размере $137000, которые запланировал на поддержку работы, и это позволило ему нанять частично занятого разработчика. Кох был удостоен единовременного пособия в размере $60000 от Linux Foundation’s Core Infrastructure Initiative. Facebook и компания онлайн-платежей Stripe пообещали по $50000 в год для проекта Коха.

Недостаточно финансируемыми проектами, такими, как был до недавнего времени GnuPG, являются многие экосистемы с открытым исходным кодом. Широкое повторное использование открытого кода способствует уменьшению разработок, но сам объем этого кода препятствует его проверке на предмет безопасности. Только недавно мы начали сталкиваться с проблемами, часто уже после нарушений безопасности, и это заставило индустрию действовать.

Пишу программы за еду
 

Условия, в которых работал Кох в течение многих лет — не редкость.

После того, как исследователь Google Нил Мета обнаружил Heartbleed, серьезную и удаленно эксплуатируемую уязвимость в компоненте OpenSSL, сообщество разработчиков было потрясено, узнав, что проект в значительной степени является ответственностью тех, кого Джим Землин, исполнительный директор Linux Foundation, назвал: «два парня по имени Стив». Доктор Стивен Хенсон и Стив Маркез были частично заняты в поддержке кода в актуальном состоянии, что компенсировалось несколькими тысячами долларов в год, поступаемых в виде добровольных взносов.

Технологические вендоры, которые полагаются на open source были быстро налетели и попытались навести порядок в проекте OpenSSL. Core Infrastructure Initiative, которая дала создателю GnuPG грант в размере $60000, была создана несколькими месяцами ранее, чтобы помочь финансировать работу Хенсона и другие проекты на OpenSSL. Финансовая поддержка предоставляется такими гигантами Кремниевой долины, как Amazon, Adobe, Cisco, Facebook и Google.

У семи нянек дитя без глазу

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

Однако благодаря шумихе в средствах массовой информации, Heartbleed, возможно, навсегда дискредитировал знаменитую пословицу Эрика Рэймонда о качестве ПО с открытым исходным кодом: «При достаточном количестве глаз все ошибки лежат на поверхности». Большинство специалистов по безопасности говорят, это понятие всегда имело больше желательный, чем описательный характер.

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

«Множество глаз» в случае открытого исходного кода, в основном скрывает слабость экосистемы open source, подразумевая атмосферу постоянной бдительности, которой никогда не существовало, говорит Билл Вайнберг, старший директор по стратегии open source в компании Black Duck Software.

«С Shellshock множество глаз не помогли», говорит Вейнберг, ссылаясь на критическую уязвимость, которая была обнаружена в коде для Bash в 2014 году. «Этот код считался также проверенным, но оказалось, что его никто не курировал, потому что все предполагали, что он уже был хорошо проверен».

В то время как мы могли бы предположить, что целостность открытого исходного кода является высокой, данные Sonatype свидетельствуют об обратном. Анализ компонентов с открытым исходным кодом в своем управляемом коде, проведенный компанией, обнаружил, что известные уязвимости в компонентах с открытым исходным кодом исправляются только в 41% случаев, написал Корман. Для проблем, которые были исправлены, среднее время их устранения заняло 390 дней.

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

Стоит серьезно относиться к безопасности на уровне кода

Каково же решение проблемы? К лучшему или худшему, ответ во многом, культурный, говорит Кэти Моузорис, главный сотрудник по вопросам политики в фирме HackerOne и бывший старший стратег безопасности в Microsoft. «Мы должны мыслить категориями безопасности. Это важно для любого проекта программного обеспечения — с открытым исходным кодом или нет».

Компания Музорис предлагает веб-платформу для координации раскрытия уязвимостей, в том числе в рамках программ поощрения за нахождение багов. Она отмечает, что HackerOne уже спонсирует нахождение багов в широком круге проектов с открытым исходным кодом, в том числе PHP, Ruby on Rails, Python и OpenSSL, обеспечивая компенсацию за отчеты об уязвимостях.

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

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

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

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

В случае Shellshock, например, проблема в коде восходит к 1989 году и имеет широкий спектр влияния — от веб-серверов на основе CGI (общего интерфейса шлюза) и почтовых серверов Qmail, до определенных клиентов DHCP. Атаки на уязвимости начались в течение нескольких часов после ее раскрытия.

Следовать за лидерами

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

Компании, выпускающие коммерческие версии Linux, как Canonical, Red Hat и Google уже вкладывают значительные средства в безопасность и целостность open source. Богатые, дружественные к с открытому исходному коду компании, такие как Netflix и Facebook направили значительные ресурсы на проекты, которые улучшают качество открытого исходного кода.

В Mozilla ответственность за безопасность разделена между тремя командами, говорит менеджер по разработке Джейсон Дуэл. Одна команда устанавливает приоритеты проблемам безопасности, когда их обнаруживают. Вторая команда делает «fuzzing» (методика тестирования, при которой на вход программы подаются невалидные, непредусмотренные или случайные данные), чтобы найти уязвимости, а третья команда разрабатывает такие функции обеспечения безопасности и конфиденциальности, как Mozilla Content Security Policy.

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

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

В Canonical, которая делает Ubuntu Linux, быстро растущая команда проверяет код безопасности, который в общей сложности составляет 35000 пакетов программного обеспечения, выпускаемых как часть Ubuntu через различные каналы, говорит Дастин Киркланд, продакт-менеджер по облачным решениям Canonical.

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

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

«С open source технологией, мы решаем — что лучше — принять ее или написать ответвление, а затем развивать и расширять его», говорит Киркланд, который является ветераном с 20-летним стажем в области открытого исходного кода и сопровождает дистрибуцию более, чем 20-ти проектов с открытым исходным кодом. Компания попала под огонь критики внутри open source сообщества, когда решила написать ответвление существующего открытого исходного кода, но Киркланд считает возможность создания ответвлений одной из сильных сторон open source.

«Мы не собираемся создавать собственные версии OpenSSL и GPG», говорит Киркланд. «Однако иметь альтернативные библиотеки шифрования очень важно. Должно быть разнообразие, особенно когда мы узнаем об уязвимости некоторых из этих компонентов».

Сейчас все пользуются открытым исходным кодом

Каким бы неудобным это не казалось, эксперты говорят, что нет пути назад. Вайнберг провел большую часть своей карьеры за тем, что он называет «защитник веры», противодействуя попыткам коммерческих поставщиков, таких как Microsoft, дискредитировать движение open source. Он говорит, что стена, которая когда-то отделяла «открытым исходный код» и «закрытый исходный код», давно снесена.

«Больше не существует такого понятия, как проприетарное программное обеспечение, потому что есть очень немного программного обеспечения без какой-либо зависимости от open source», сказал он. «Мир перешел к программному обеспечению, разрабатываемому сообществом — в той или иной форме».

«Я действительно думаю, что это общая ответственность», говорит Киркланд. «Если вы подумаете, насколько мы все зависим от большого количества программного обеспечения с открытым исходным кодом, то вы должны надеяться, что безопасность становится общей ответственностью и что ответственность не останется только за Linux Foundation и Red Hat».

Другими словами, мы можем скрежетать зубами и рвать волосы по поводу Heartbleed, но в 2015 году все компании, которые делают, используют или полагаются на программное обеспечение, де-факто являются open source софтверными компаниями, знают ли они это или нет. Это делает их частью проблемы и ее решения.