Поиск уязвимостей по открытым источникам в рамках цикла разработки безопасного ПО

Поиск уязвимостей по открытым источникам в рамках цикла разработки безопасного ПО

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

В данной статье рассматриваются методы и инструменты анализа уязвимостей по открытым источникам, их применение для повышения уровня безопасности ПО и лучшие практики их интеграции в процесс разработки. Отдельное внимание отведено композиционному анализу, который представляет собой мощный инструмент для выявления уязвимостей в программном обеспечении, включая библиотеки и компоненты, используемые в разработке. Разработка безопасного программного обеспечения на данный момент в Российской Федерации применяется в соответствии с требованиями ГОСТ Р 56939-2024. 

Введение

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

Анализ по открытым источникам информации позволяет разработчикам идентифицировать и управлять этими рисками. Различные источники указывают, что поиск уязвимостей в ПО с ОИС становится необходимым элементом цикла разработки безопасного программного обеспечения (SDLC). 

Цель данной статьи — рассмотреть преимущества использования инструментов данного анализа в процессе разработки безопасного ПО.

Методика проведения анализа уязвимостей по открытым источникам

Анализ сторонних компонентов программного обеспечения на предмет известных уязвимостей может быть проведён несколькими способами:

1. Ручной поиск уязвимостей по базам данных уязвимостей, который включает в себя поиск информации о компонентах в различных источниках информации, таких как:

— национальные базы данных:

• Банк данных угроз безопасности информации (БДУ ФСТЭК);

— зарубежные базы данных уязвимостей и недостатков (ошибок):

• Common Vulnerabilities and Exposures (CVE);
• CVE Details;
• National Vulnerability Database;
• Vulners.

— публикации и тематические форумы;
— результаты исследований, полученные сторонними исследователями;
— официальный сайт производителей компонентов с открытым исходным кодом.

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

2. Статический анализ исходного кода (SAST — Static Application Security Testing) — вид работ, который включает в себя поиск дефектов в исходном коде без его фактического выполнения.

3. Динамический анализ исходного кода (DAST — Dynamic Application Security Testing) — вид работ, который включает в себя поиск уязвимостей в процессе выполнения кода.

4. Нефункциональное тестирование — вид работ, который включает в себя проверки, не относящиеся к тестированию функциональных возможностей ПО. Данный термин был введён в ГОСТ Р 56939-2024 и в первую очередь является заменой понятия тестирования на проникновение. Однако, в отличие от классического пентеста, нефункциональное тестирование — более широкое понятие, включающее в себя также другие проверки, которые требуется проводить в соответствии с промышленными требованиями разработчика. В контексте анализа заимствованных компонентов авторы данной статьи подразумевают именно тестирование на проникновение.

5. Композиционный анализ (SCA — Software Composition Analysis) — вид работ, основанный на формировании перечня зависимостей ПО, определении лицензионной чистоты используемых компонентов и выявлении наличия уязвимостей и/или иных недостатков в зависимостях ПО. 

Стоит дополнительно отметить, что статический анализ, динамический анализ и нефункциональное тестирование в отношении заимствованных компонентов требуют гораздо больших трудозатрат с точки зрения проведения, поскольку необходимо разработать уникальную методику тестирования каждого компонента. Соответственно, данные виды анализов целесообразно проводить на этапе тестирования программного обеспечения, когда состав заимствованных компонентов уже сформирован. Важно также подчеркнуть, что в процессе тестирования можно выявить zero-day-уязвимости. Это уязвимости, которые не были ранее известны разработчикам или производителям программного обеспечения, и, следовательно, на них отсутствуют патчи или средства защиты. 

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

Многие проекты используют пакетные менеджеры зависимостей (например, npm, maven, pip). Анализ списка зависимостей позволяет идентифицировать используемые компоненты и проверить их на наличие уязвимостей в вышеупомянутых базах данных. Инструменты для анализа состава компонентов помогают автоматизировать данный процесс. 

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

Этапы композиционного анализа традиционно включают в себя:

1. Идентификацию компонентов, которая определяет все внешние библиотеки и зависимости, используемые в проекте.
2. Выявление известных уязвимостей в этих компонентах с использованием различных баз данных уязвимостей, таких как CVE (Common Vulnerabilities and Exposures).
3. Проверка лицензионных соглашений используемых компонентов на предмет соответствия требованиям проекта.

Для прохождения первого этапа необходимо сгенерировать SBOM-файл (Software Bill of Materials) — файл, который содержит в себе спецификацию в виде машиночитаемого формата, в котором перечислены библиотеки и их версии.

Взаимодействие между программными компонентами определяется через граф зависимостей, вершины которого представляют компоненты, а рёбра — зависимости между ними. Зависимости делятся на прямые (direct dependencies) и транзитивные (transitive dependencies). Прямая зависимость устанавливается, если компонент A явно использует компонент B, что обычно отображается в метаданных проекта (например, package.json, requirements.txt). Транзитивная зависимость возникает, когда компонент A зависит от компонента B, а B, в свою очередь, зависит от компонента C. В этом случае C является транзитивной зависимостью для компонента A (рис. 1).

Рисунок 1. Транзитивная зависимость

Требования регуляторов

Анализ компонентов открытого программного обеспечения на наличие известных уязвимостей является обязательным требованием множества отечественных и международных нормативных документов. Несмотря на повсеместную необходимость выявления уязвимостей в заимствованных компонентах (часто сводящуюся к поиску информации в открытых источниках для идентификации потенциальных угроз), явное указание на композиционный анализ как специфический метод проверки присутствует лишь в национальном стандарте ГОСТ Р 56939-2024 (таблица 1). Остальные рассмотренные стандарты (ГОСТ Р 56939-2016, ГОСТ Р ИСО/МЭК 15408-3-2013, «Профиль защиты прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций», стандарт PCI DSS, NIST SP 800-171) описывают требования к анализу ПО с ОИС, однако не конкретизируют методологию.

Анализ требований, представленных в таблице далее по тексту, демонстрирует неоднородность подходов к анализу заимствованных компонентов по открытым источникам информации. В то время как необходимость такого анализа признаётся во всех рассмотренных документах, только ГОСТ Р 56939-2024 указывает на композиционный анализ как наиболее эффективный метод. Это свидетельствует на недостаток стандартизации в области оценки безопасности заимствованных компонентов, что может привести к неполному покрытию уязвимостей и повышенному риску компрометации системы. Дальнейшие исследования должны быть направлены на разработку более чётких и унифицированных методик, учитывающих специфику различных областей применения программного обеспечения. 

Таблица 1. Требования регуляторов

 
 
Инструменты, применяемые при композиционном анализе

Использование CI/CD позволяет автоматизировать процесс анализа зависимостей, что снижает вероятность возникновения человеческой ошибки и обеспечивает регулярное обновление информации о безопасности.

Для композиционного анализа наиболее популярными решениями являются OWASP Dependency Track и OWASP Dependency Check. Далее более подробно рассмотрим пример использования OWASP Dependency Track.

Для автоматизированного использования данного инструмента необходимо подготовить файл определённой структуры, в котором содержатся зависимые компоненты и информация о них (SBOM-файл). Необходимо выбирать утилиту для генерации файла в соответствии с используемыми языками программирования. Наиболее распространённая утилита генерации — CycloneDX (cdxgen).

После анализа SBOM-файла в OWASP Dependency Track можно отслеживать не только сами выявленные уязвимости (рис. 2), но и изменение количества уязвимостей в проекте, который инкрементально исследуется (рис. 3).

Рисунок 2. Выявленные уязвимости

Рисунок 3. График зависимости количества выявленных уязвимостей от версии проекта

Вывод

Современная разработка с использованием ПО с ОИС требует особого внимания к вопросам безопасности. Применение методов и инструментов анализа уязвимостей, включая композиционный анализ, позволяет существенно снизить риски, связанные с использованием уязвимых библиотек и компонентов. Интеграция таких практик в процесс разработки способствует созданию надёжного ПО, соответствующего как международным стандартам, так и требованиям ГОСТ Р 56939-2024, актуального для Российской Федерации. Постоянное совершенствование подходов к обеспечению безопасности и внедрение инновационных решений позволяют разработчикам и организациям быть готовыми к вызовам стремительно меняющегося технологического ландшафта.