Исходный код (Open Source) используется почти в каждом приложении. Open source-библиотеки, фреймворки и компоненты помогают ускорить разработку и сделать ее гораздо более удобной. Но есть проблема: каждая зависимость — это не только «плюшки», но и дополнительные риски. Если в open source, который вы используете, появится уязвимость, придется срочно ее устранять — и вряд ли на это уйдет две минуты. Еще есть юридические риски: автор open source может направить вам запрос на раскрытие той части кода, которую вы модифицировали, а это может оказаться конфиденциальной информацией. В итоге предоставить часть кода вы не сможете, а другая сторона будет иметь полное право обратиться в суд.
Подобных рисков помогает избежать анализ открытого исходного кода — для краткости мы будем называть его просто OSA. Что это такое и как его проводить, рассказывает Руслан Чотчаев, инженер в отделе развития процессов безопасности.
- какие риски несет в себе Open Source
- что такое Open Source Analysis и какие задачи он решает
- как провести Open Source Analysis
- каких рисков можно избежать, если сделать OSA регулярной практикой
Статья будет полезна разработчикам и специалистам по безопасности. Первые смогут освоить новую полезную практику — «самодиагностику» своих проектов через OSA, которая поможет избежать рисков и сократить время на запуск продукта. Вторые сверят координаты: какие решения можно использовать, чтобы повысить безопасность продуктов.
Open source — не только удобство, но и риски
По данным отчета Census III of Free and Open Source Software, от 70 до 96% кода в современных приложениях — это open source-компоненты. Обычный сервис тянет за собой в проект сотни транзитивных зависимостей, о существовании которых разработчик может даже не догадываться. Из этого вытекают проблемы:
- Уязвимость, которая может быть в open source-библиотеке, становится уязвимостью вашего приложения. Пользователи доверяют вам свои данные и надеются на безопасность ваших сервисов. Они взаимодействуют с вашим приложением, а не напрямую с отдельной библиотекой. Когда происходит утечка данных или атака, именно вы несете репутационные и юридические риски. Добавьте к этому возможные финансовые потери и разнообразие атак — от кражи данных до внедрения вредоносного кода и контроля над системой. А еще есть «спящие бомбы»: можно не знать об уязвимости годами, пока злоумышленники не найдут способ ее эксплуатировать. Продолжать пугать можно было бы долго, но давайте перейдем к следующему пункту.
- Обновление зависимости часто приходится откладывать «на потом», ведь сначала нужно проверить, не сломает ли оно работу приложения. Отложенные обновления приводят к тому, что технический долг накапливается. Еще вы можете продолжать использовать код с уже известными уязвимостями и лишить себя новых полезных функций, которые добавили разработчики.
- Вы можете случайно нарушить лицензионное соглашение. К сожалению, обычно лицензии на open source читают уже после того, как внесли библиотеку в продукт, или не читают вообще. Это грозит компании исковыми заявлениями в суд, последующими судебными процессами и возможными штрафами.
Избежать этих проблем помогает Open Source Analysis. Считаю, он должен стать обычной практикой — дальше об этом и поговорим.
Какие задачи решает Open Source Analysis
Начнем с базы. Open Source Analysis (OSA) — это анализ open source-компонентов, которые используются в приложении. Задача такого анализа — ответить на вопрос: «Какие риски мы наследуем, когда подключаем очередную библиотеку?».
OSA фокусируется на нескольких аспектах: уязвимости, лицензии, актуальности и поддержке компонентов, рисках для цепочки поставок (supply chain). Часто применяется с композиционным анализом (SCA). Сочетание этих практик помогает комплексно оценить безопасность применения open source.
С какими конкретно задачами помогает OSA:
1. Найти уязвимости — инциденты, которые уже случались. С OSA вы свовременно выявляете уязвимости в открытых компонентах, которые могут привести к серьезным инцидентам.
В качестве примера предлагаю посмотреть на Log4Shell (CVE-2021−44228) — одну из самых масштабных уязвимостей последних лет. Инциденты были зафиксированы по всему миру, а разработчикам пришлось выпускать экстренные патчи и отключать сервисы. После этого случая многие компании‑разработчики впервые задумались, а используют ли они Log4j в своих продуктах. Те, у кого уже был построен процесс OSA, смогли ответить на этот вопрос очень быстро. Другие потратили дни и недели.
2. Выявить атаки на цепочку поставок
Атаки на цепочку поставок (Supply Chain Attacks) — уже не теория, а практика: злоумышленники активно ими пользуются. Примеры:
- загрузка подмененных пакетов с публичных репозиториев (Dependency Confusion);
- компрометация аккаунтов мейнтейнеров проектов;
- внедрение вредоносного кода в обновления.
При помощи OSA можно выяснить, где находится источник зависимости и кто и как именно ее поддерживает.
3. Управлять лицензионными рисками еще на этапе разработки
Простой пример из практики. Продукт уже готов к релизу, но на этапе проверки к поставке внезапно выясняется, что в нем есть компоненты, распространяемые под лицензией GPL, а она требует раскрытия исходного кода продукта. В такой ситуации остается срочно перерабатывать продукт, переносить релиз и готовиться к возможной потере клиента.
С теорией понятно, но как такой анализ выглядит на практике?
Как проводится 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 позволяет автоматизировать ручные проверки и сэкономить рабочее время инженеров.
Провести OSA можно при помощи огромного количества инструментов — как коммерческих, так и open source. Среди них: OWASP Dependency‑Check, OWASP Dependency‑Track, Snyk, Trivy, Code Scoring, GitHub Dependabot / Security Advisories. Какой инструмент выбрать, зависит от уровня компании, зрелости процессов безопасной разработки, требований к лицензированию, выделенного бюджета и целей команды. Но чтобы начать применять эту практику, хватит и open source инструментов.
Что OSA дает разработчику
Если сделать Open Source Analysis своей постоянной практикой, вы получаете:
- прозрачность состава компонентов, которые используются в приложении;
- понимание потенциального вектора атаки на разрабатываемое приложение;
- возможность быстро среагировать на новые уязвимости;
- возможность управлять лицензионными рисками;
- высокий уровень безопасности разрабатываемого продукта.
Из этого вытекают преимущества перед конкурентами: вы снижаете вероятность атак и простоя оборудования, к которому могли бы привести инциденты. Так что Open Source Analysis — это необходимая инженерная практика. Этот анализ помогает честно ответить себе на вопрос: «Насколько вы действительно контролируете то, из чего состоит ваш продукт?».
Конечно, внедрение OSA требует времени и ресурсов — например, вам совершенно точно понадобятся регулярные awarnesses-сессии с командами разработки. Но усилия не будут потрачены впустую: в следующий раз вместо того, чтобы использовать open source-библиотеку с неподходящей лицензией, разработчики сразу подберут замену или продумают возможность написать компонент самостоятельно. А значит, и разгребать неприятные последствия не придется.
