Популярность свободного программного обеспечения постоянно растет. Поэтому задача повышения безопасности ПО с открытым кодом остается едва ли не самой актуальной, когда речь заходит о распространении Open Source во всех экосистемах. Есть ли решение у этой задачи?
Основные проблемы безопасности компонентов с открытым исходным кодом?
Проблемы исходят из самой природы Open Source: зачастую разработка «на свой страх и риск» и открытость кода. Первое приводит к слабому качеству продукта (библиотеки, фреймворка), так как принцип снятия ответственности ускоряет выпуск релиза в ущерб времени/ресурсу на тестирование и багфикс. Второе приводит к отсутствию преград к поиску и использованию уязвимостей заинтересованными, включая злоумышленников. А в отсутствие замотивированного стейкхолдера/продакта исправление уязвимостей и повышение качества продукта может длиться месяцами, а может и вообще не выполняться.
К тому же возможны случаи умышленного регресса — недавно был громкий случай, когда создатель Open Source-библиотеки выпустил заведомо испорченный релиз с целью нанесения вреда использующим эту библиотеку коммерческим компаниям.
Какие из проблем, по вашему мнению, нужно решать в первую очередь?
Конечно, самая приоритетная задача — «тушение пожаров», т. е. оперативное исправление найденных уязвимостей. Но для этого их надо сначала найти, а затем оповестить использующие проекты о наличии и исправлении бага/дыры. Для этого существуют специальные инструменты: SonarQube, Dependency-Track и т. д. Пытаться исправлять остальные проблемы, на мой взгляд, быстро не получится — они противоречат самой природе Open Source. Это культура в команде разработки — ее быстро не поменять.
Ваши предложения по повышению уровня защищенности Open Source-компонентов?
Поможет повышение внимания к оценке качества создаваемого программного обеспечения на обоих фронтах: и при создании Open Source-компонента, и при его использовании. Для этого есть ряд инструментов и практик. Практики — это, конечно, различные виды тестирования: smoke, ручное, автоматическое, регресс, нагрузочное и прочее.
Сегодня из-за гонки за сроками часто забываются прописные истины обеспечения качества создаваемого программного обеспечения: тестирование не может занимать менее +/- 30 % трудоемкости разработки. Конечно, это ведет к увеличению команды, сроков, бюджетов. Быстрее провести минимальное неквалифицированное тестирование с помощью аналитиков или вообще разработчиков, однако при этом страдает качество.
Какие инструменты могут помочь в этом?
Помимо традиционных инструментов различного вида тестирования (Unit, Selenium/WebDriver, JMeter и т. д.) на помощь приходят продукты SAST/DAST/IAST/RASP (Dependency-Track, Clair, SonarQube). Крайне желательно встраивать эти проверки в обязательные шаги создания программного обеспечения. Например, мы всё чаще встречаем в крупных inhouse командах и компаниях-разработчиках появление конвейеров, в которых шаги анализа зависимостей на уязвимости являются обязательными и препятствуют, например, выкатке релиза на TEST/UAT.
Какие форматы взаимодействия IT-сообщества для решения данной проблемы вы считаете эффективными?
Помимо стандартных багтрекеров, считаю эффективным открытый диалог: конференции, митапы, круглые столы. На них разработчики Open Source-компонентов знакомятся ближе с требованиями бизнеса и получают прямую обратную связь. Обе стороны обмениваются болями, проблемами и их решениями. Это позволяет сблизить позиции и лучше понимать планы и потребности друг друга, в том числе по вопросам уязвимостей.