Привет! Меня зовут Руслан, я инженер в отделе развития процессов безопасности в YADRO. Сегодня поговорим об открытом исходном коде (open source). В мире современной разработки он используется практически в каждом приложении: open source-библиотеки, фреймворки и компоненты помогают ускорить разработку и сделать ее гораздо более удобной. 

Но есть проблема: каждая зависимость — это не только «плюшки», но и дополнительные риски. Если в open source, который вы используете, появится уязвимость, придется срочно ее устранять — и вряд ли на это уйдет пара минут. Еще есть юридические риски — например, автор open source может направить вам запрос на раскрытие той части кода, которую вы модифицировали, а для вас это может оказаться конфиденциальной информацией. В итоге предоставить часть кода вы не сможете, а другая сторона будет иметь полное право обратиться в суд.

Таких рисков как раз и помогает избежать анализ открытого исходного кода (Open Source Analysis, OSA). Давайте разбираться, что это такое и как его выполнять.

Open source — и риск, и благо

По данным отчета Census III of Free and Open Source Software, от 70 до 96% кода в современных приложениях — это open source-компоненты. Обычный сервис тянет за собой в проект сотни транзитивных зависимостей, о существовании которых разработчик может даже не догадываться. 

Из этого вытекают проблемы:

• Уязвимость, которая может быть в open source-библиотеке, становится уязвимостью вашего приложения. Пользователи доверяют вам свои данные и надеются на безопасность ваших сервисов. Они взаимодействуют с вашим приложением, а не напрямую с отдельной библиотекой. Когда происходит утечка данных или атака, именно вы несете репутационные и юридические риски. Добавьте к этому возможные финансовые потери и разнообразие атак — от кражи данных до внедрения вредоносного кода и контроля над системой. А еще есть «спящие бомбы»: можно не знать об уязвимости годами, пока злоумышленники не найдут способ ее эксплуатировать. Продолжать пугать можно было бы долго, но давайте перейдем к следующему пункту.

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

• Вы можете случайно нарушить лицензионное соглашение. К сожалению, обычно лицензии на open source читают уже после того, как внесли библиотеку в продукт, или не читают вообще. Это грозит компании исковыми заявлениями в суд, последующими судебными процессами и возможными штрафами.

Как я уже писал выше, избежать этих проблем помогает Open Source Analysis. Считаю, он должен стать обычной практикой — дальше об этом и поговорим.

Сейчас в нашей команде открыты такие вакансии:

— архитектор по безопасности;

— инженер по информационной безопасности;

— DevSecOps-инженер.

Ждем ваших откликов!

Какие задачи решает Open Source Analysis

Начнем с базы. Open Source Analysis (OSA) — это анализ open source-компонентов, которые используются в приложении. Задача такого анализа — ответить на вопрос: «Какие риски мы наследуем, когда подключаем очередную библиотеку?». 

OSA фокусируется на нескольких аспектах: уязвимости, лицензии, актуальности и поддержке компонентов, рисках для цепочки поставок (Supply Chain). Часто применяется с композиционным анализом (SCA). Сочетание этих практик помогает комплексно оценить безопасность применения open source.

С какими конкретно задачами помогает OSA:

1. Найти уязвимости — инциденты, которые уже случались. С OSA вы своевременно выявляете уязвимости в открытых компонентах, которые могут привести к серьезным инцидентам.

В качестве примера предлагаю вспомнить Log4Shell (CVE-2021-44228) — одну из самых масштабных уязвимостей последних лет. Эта RCE-уязвимость (Remote Code Execution) позволяла злоумышленникам выполнять произвольный код на атакуемом сервере через простой текстовый запрос. Инциденты были зафиксированы по всему миру, а разработчикам пришлось выпускать экстренные патчи и отключать сервисы. После этого случая многие компании‑разработчики впервые задумались, а используют ли они Log4j в своих продуктах. Те, у кого уже был построен процесс OSA, смогли ответить на этот вопрос очень быстро. Другие потратили дни и недели.

2. Выявить атаки на цепочку поставок (Supply Chain Attacks). Это уже не теория, а практика: злоумышленники активно ими пользуются. Примеры:

• загрузка подмененных пакетов с публичных репозиториев (Dependency Confusion);

• компрометация аккаунтов мейнтейнеров проектов;

• внедрение вредоносного кода в обновления.

При помощи OSA можно выяснить, где находится источник зависимости и кто и как именно ее поддерживает. 

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

OSA позволяет планомерно принимать решения. Во время анализа проверяются лицензии open source-компонентов. Если будут найдены копилефтные лицензии, для таких open source-компонентов можно будет найти замену с более «дружелюбными» условиями.

С теорией понятно, но как такой анализ выглядит на практике?

Как проводится Open Source Analysis

Шаг первый: инвентаризация и SBOM. Задача — понять, какие именно компоненты используются в продукте. Для этого формируется Software Bill of Materials (SBOM). Анализируются manifest-файлы (package.json, pom.xml), lock-файлы (package-lock.json) и образы контейнеров. В результате вы получаете список прямых и транзитивных зависимостей с указанием их версий.

Шаг второй: поиск и оценка известных уязвимостей. Все зависимости сопоставляются с известными базами уязвимостей — например, БДУ ФСТЭК, NVD, CVE, GitHub Security Advisories. Если во время сканирования обнаруживается уязвимость, Application Security Engineer анализирует ее, определяет, может ли она эксплуатироваться злоумышленником, и отсеивает ложные срабатывания сканеров.

Шаг третий: анализ лицензий. В большинстве случаев в компаниях есть политика использования лицензий: разрешенные лицензии (MIT, BSD, Apache 2.0), условно разрешенные (LGPL), запрещенные (GPL/AGPL). OSA помогает выявить возможные конфликты и заставляет задуматься над тем, как законно использовать, распространять и модифицировать open source-компоненты в вашем проекте.

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

Шаг пятый: интеграция в CI/CD. Применение OSA в команде можно развивать:

• запускать автоматически при каждой сборке продукта;

• блокировать сборку продукта, если найдены уязвимости критического и высокого уровней;

• обеспечивать постоянный мониторинг и обновление уже имеющихся зависимостей.

Как итог, интеграция OSA в CI/CD позволяет автоматизировать ручные проверки и сэкономить рабочее время инженеров.

Провести анализ можно при помощи огромного количества инструментов — как коммерческих, так и open source. Среди них: OWASP Dependency‑Check, OWASP Dependency‑Track, Snyk, Trivy, Code Scoring, GitHub Dependabot / Security Advisories. Какой инструмент выбрать, зависит от уровня компании, зрелости процессов безопасной разработки, требований к лицензированию, выделенного бюджета и целей команды. Но чтобы начать применять эту практику, достаточно и open source-инструментов.

В качестве завершения подытожу, что OSA дает разработчику:

• прозрачность состава компонентов, которые используются в приложении;

• понимание потенциального вектора атаки на разрабатываемое приложение;

• возможность быстро среагировать на новые уязвимости;

• возможность управлять лицензионными рисками;

• высокий уровень безопасности разрабатываемого продукта.

Из перечисленного вытекают конкурентные преимущества: вы снижаете вероятность атак и простоя оборудования, к которому могли бы привести инциденты. Так что Open Source Analysis — это необходимая инженерная практика. Этот анализ помогает честно ответить себе на вопрос: «Насколько вы действительно контролируете то, из чего состоит ваш продукт?».

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