Открытый код скрывает опасные уязвимости. Как их найти?
Исследование Джеймса Кусика показало, что в коде открытых проектов, включая крупные, такие как Chromium, и небольшие, вроде Genann, выявлены уязвимости различной степени риска, что подтверждает необходимость систематического анализа кода. В проприетарных приложениях уровень проблем оказался промежуточным, но также требует регулярной проверки для минимизации рисков в цепочке поставок программного обеспечения.
Открытый исходный код стал неотъемлемой частью цифровой инфраструктуры.
Он лежит в основе браузеров, мобильных приложений и систем, обеспечивающих взаимосвязь бизнес процессов. Для многих руководителей безопасности это стало фоном, который не требует ежедневного внимания. Именно в этом и кроется потенциальная опасность.
Исследование, проведённое Джеймсом Кусиком из Рицумэйкан-университета, ставило перед собой задачу: насколько безопасен код, на котором мы строим критически важные системы? В ходе работы сравнивались миллионы строк как открытого, так и закрытого программного обеспечения, чтобы выявить скрытые уязвимости и оценить их серьёзность. Результаты показали, почему статический анализ кода должен стать неотъемлемой частью любой стратегии безопасности.
Сравнение открытого и проприетарного кода
В исследовании анализировались два открытых проекта. Chromium, основа для браузеров Chrome, Edge и Opera, представляет собой крупный и известный проект. В качестве контраста использовалась Genann — небольшая библиотека для нейронных сетей. В рамках исследования также оценивались несколько проприетарных SaaS-приложений, разработанных и поддерживаемых внутри одной компании, что позволило провести прямое сравнение с открытым кодом.
Результаты показали различия. В сканировании Chromium было выявлено 1 460 потенциальных проблем, распределённых по почти шести миллионам строк кода, из которых лишь несколько считались критическими или с высокой степенью риска. Genann, напротив, продемонстрировала совсем другую картину: шесть потенциальных проблем в 682 строках кода — это около одной на каждые 27 строк.
Проприетарные приложения оказались где-то посередине. В почти трёх миллионах строк кода было найдено около пяти тысяч проблем, большинство из которых имели среднюю или низкую степень риска. Даже внутри этой группы уровень угрозы значительно различался между отдельными приложениями.
К чему это ведет? Открытые проекты, даже с крупным и активным сообществом, не застрахованы от скрытых уязвимостей. Это требует систематического подхода к проверке кода.
Угрозы из цепочки поставок
Для руководителей информационной безопасности эти данные подчеркивают растущую проблему цепочки поставок. Открытые компоненты часто интегрируются в системы без тщательной проверки. Даже проекты вроде Chromium, имеющие активную группу разработчиков, могут содержать скрытые уязвимости.
Кусик подчеркивает, что для специалистов по безопасности нельзя предполагать, что открытый код безопасен, не проверив его самостоятельно. «Я бы не доверял никакому открытому коду или продукту, который я не проверил или не отсканировал. Интеграция кода в ваш продукт без понимания его состояния качества или степени уязвимости — это, как минимум, рискованно. Это похоже на то, чтобы сесть в машину, не зная, работают ли тормоза. Время, потраченное на оценку рисков, — это время, потраченное не зря», — отмечает он.
Когда организации добавляют библиотеки открытого кода без сканирования, они вносят неизвестные слабости в свою инфраструктуру. После развертывания такие компоненты становятся сложнее отслеживать и обновлять. Риск возрастает, когда команды всё чаще полагаются на микросервисы и облачные архитектуры, в которых широко используется открытый код.
Построение безопасного процесса разработки
Исследование предлагает пошаговый путь интеграции статического анализа в жизненный цикл безопасной разработки, основанный на десятилетнем опыте. В него входят выбор инструментов, получение кода из репозиториев, запуск сканирования и работа с разработчиками по анализу и устранению найденных проблем.
Одним из ключевых уроков стало то, что сканирование должно быть непрерывным. Каждое обновление, новая функция или изменение кода может привести к введению уязвимостей. Инструменты анализа могут интегрироваться напрямую в CI/CD-конвейеры, позволяя выявлять проблемы на более ранних этапах и в масштабе.
Кусик также отмечает, что ИИ будет играть всё более важную роль в обнаружении уязвимостей, но не стоит рассматривать его как панацею. «AI-инструменты для сканирования уже готовы к использованию, но они не обеспечивают 100%-ную детекцию, как и большинство других инструментов. Также не существует автоматической цепочки сканирования и исправления. Это всё ещё итеративный процесс, требующий оценки, написания кода, повторного тестирования и приоритизации, поскольку не все уязвимости могут быть устранены, если ресурсы ограничены, а сроки выхода — жёсткие», — поясняет он.
Он добавляет, что, несмотря на перспективы, ИИ-инструменты ещё долго не заменят человеческую экспертизу. «Интеграция AI может оптимизировать отдельные этапы — сначала сканирование уязвимостей, затем их устранение, что в сумме может дать значительный выигрыш по сравнению с ручной работой», — отмечает Кусик.
Что за этим стоит? ИИ может стать мощным помощником, но не заменой людям. Его эффективность достигается только в комбинации с человеческим суждением.
Открытый код — не равен нулевому риску
Открытый исходный код всегда будет играть ключевую роль в бизнесе. Исследование показывает, что его нельзя рассматривать как полностью безопасный. Интеграция сканирования в процессы разработки и закупки позволяет получить прозрачность в цепочке поставок ПО и снизить риск, что скрытые уязвимости нанесут серьёзный урон.
Тренд: Безопасность начинается с видимости. Там, где нет прозрачности — есть уязвимость.
Открытый исходный код не исключает рисков для критически важных систем
Исследования показывают, что даже крупные проекты с активным сообществом содержат уязвимости, которые остаются незамеченными без систематического анализа. Это подчеркивает необходимость внедрения статического анализа кода как постоянной части жизненного цикла разработки. Проприетарные и открытые проекты демонстрируют разный уровень рисков, но ни один не гарантирует безопасности без проверки. Интеграция открытых библиотек без оценки их состояния ведёт к накоплению скрытых угроз, которые сложно отслеживать в сложных облачных и микросервисных архитектурах.
Растущая зависимость от внешних компонентов усиливает уязвимости цепочки поставок. Использование ИИ для анализа кода открывает новые возможности, но не заменяет человеческое суждение. Технологии позволяют ускорить выявление проблем, но не обеспечивают автоматического решения. Это требует пересмотра подходов к управлению рисками: безопасность становится вопросом не только технологий, но и процессов, включающих постоянное сканирование, интеграцию в CI/CD и оценку рисков на всех этапах. Без прозрачности и систематического подхода к контролю качества кода, даже самые надёжные проекты могут стать источником угроз.
