Почему многие безопасники избегают Open Source?

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

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

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

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

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

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

Или допустим, специалист по безопасности находит уязвимость нулевого дня или проводит обратную разработку исправления уязвимости и выявляет слабость. Если они выставляют ее публично, то, по сути, создают условия гонки, в которых хакеры спешат воспользоваться слабостью до того, как исправление будет выпущено и развернуто. Что, если злоумышленник точно знает, какую логику использует организация для обнаружения вредоносного поведения? Это может позволить ему находить пробелы и выбирать методы, которые обходят обнаружение.

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

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

Начнем с выбора популярного Open Source проекта. Например, возьмем проект, который активно используется в веб-разработке, такой как Express.js — популярный фреймворк для Node.js.

Используем инструмент для анализа зависимостей, например, npm audit или npm ls, чтобы получить список всех зависимостей проекта. Мы ищем менее популярные библиотеки, которые могут быть менее защищены и имеют меньше внимания со стороны сообщества. Например, библиотека some-less-popular-lib.

Выбираем библиотеку some-less-popular-lib, которая используется в проекте, но не имеет большого количества звезд или форков на GitHub, что может указывать на меньшую активность сообщества.

Из соображений безопасности не будем приводить более подробный пример во избежание потенциального злоупотребления этой информацией и для защиты пользователей от возможных угроз.

Ждем, когда авторы библиотеки примут наш pull request и выпустят новую версию библиотеки. Это может занять некоторое время, в зависимости от активности авторов.

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

Этот сценарий подчеркивает важность тщательной проверки и мониторинга зависимостей в Open Source проектах. Разработчики должны регулярно проверять обновления зависимостей и использовать инструменты для анализа безопасности, такие как npm audit, чтобы минимизировать риски.

Открытый исходный код помогает значительно снизить затраты на разработку ПО и повысить его прозрачность. Однако, если пользователи слепо верят что open source = security не анализируя все «за» и «против», то тем самым создают себе лишь ложное чувство безопасности.

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

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