Заблуждения про анализ кода или зачем нужен SCA 09.08.2022 12:00В различных методологиях безопасной разработки мы всегда встречаем отдельный раздел про контроль заимствованных компонентов с открытым кодом. Даются понятные объяснения, зачем нужно делать инвентаризацию open source и проверку на уязвимости, но лишь вскользь говорится про инструменты SCA (SCA — анализ композиции программного кода), которыми такой анализ выполняется. По итогам прочтенных рекомендаций зачастую остается ощущение, что статическим анализом закрываются все вопросы проверки кода.
SAST-сканеры, предназначенные для анализа кода или его части на наличие уязвимостей без запуска исследуемого приложения на исполнение, действительно закрывают очень большую и важную часть проверок, но тем не менее, ряд задач ожидают встраивания SCA в конвейер разработки. Мы попытались выяснить, с чем связан данный пробел, и в результате проведенных интервью с множеством компаний появилась подборка основных заблуждений, связанных с анализом кода, чем и хочу поделиться с вами.
Заблуждение №1. «Мы весь код пишем сами»
В реальности нехитрый аудит в 100% случаев показывал наличие заимствованного программного кода.
Писать весь код с нуля — дорого и долго, и дело не только в первоначальных вложениях на создание уникального проприетарного кода. Если компоненты с открытым кодом поддерживает и развивает целое сообщество, то проприетарный код до конца его жизненного цикла требуется поддерживать самостоятельно. Со временем усилия на его сопровождение растут в геометрической прогрессии, существенно замедляя разработку нового функционала. Проприетарный код также как и открытый содержит ошибки и уязвимости, поэтому даже если бы весь код «писали сами», то он не был бы из-за этого безопасным.
Стоит отметить, что часто бизнес-заказчик знает об использовании open source в проектах, но думает, что это единичные включения. Дело в том, что кроме прямых включений (директивных зависимостей), в проект попадает огромное количество транзитивных зависимостей. Происходит это из-за того, что те самые единичные включения требуют включения еще нескольких других компонентов (то есть зависят от них), эти несколько компонентов в свою очередь зависят уже от множества… эти цепочки бывают очень длинными.
Так, «отсутствующий» или «единичные включения» open source в конечном итоге могут составлять и 80% и 90% проекта.
Заблуждение №2. «Наш SAST-сканер закрывает все задачи в части проверки кода»
В реальности SAST-сканеры хороши для проприетарного кода, а адекватный контроль open source в непрерывном режиме делается с помощью SCA-инструментов.
Как я уже говорила, на практике компоненты с открытым кодом составляют подавляющее большинство в проекте. Для контроля и анализа, их нужно выявить, определить зависимости, проверить на уязвимости и лицензионное соответствие, а для своевременного реагирования необходимы готовые рекомендации по исправлению обнаруженных ненорм. Каждая из перечисленных задач по принципу решения для проприетарного и открытого кода отличается.
Если инвентаризация open source компонентов еще простая задача, то для определения всех транзитивных зависимостей уже требуется качественный специализированный SCA-инструмент. После определения всех зависимостей формируется список из сотен компонентов (которые написаны миллионами строк кода), причем этот список активно обновляется по мере появления новых версий компонентов. SAST в виду принципа своего устройства, на миллионах строк часто обновляемого кода дает столь огромное количество срабатываний, что разобрать их на существенные и игнорируемые само по себе крайне сложно, не говоря уже о том, чтобы выработать решение по всем существенным угрозам. В связи с этим, SAST хорош для регулярной проверки проприетарного кода, но для миллионов строк открытого кода в темпе производства требуется другой подход – такой, чтобы специалисты по безопасности успевали реагировать. Принцип работы SCA совершенно не похож на SAST, сам код не сканируется. SCA-инструмент после инвентаризации open source делает поиск известных уязвимостей в различных базах по обнаруженным компонентам и выдает разработчикам найденную информацию об уязвимостях и вариантах исправлений. Наличие уязвимостей, о которых информирует SCA уже проверено сообществом и публично известно. Таким образом, количество предупреждений SCA генерирует в существенно меньшем количестве, но с высокой точностью и в подавляющем числе случаев – с вариантами исправлений.
Кроме того, включение open source влечет за собой специфические юридические риски такие, что лицензионные соглашения компонентов с открытым кодом могут быть не подходящими, например, обязывать открывать весь написанный вами код или запрещать использовать компоненты при ряде условий. Поэтому SCA-инструменты также выполняют непрерывный мониторинг лицензионной чистоты. Лицензионное соответствие обеспечивает легитимное существование разработанного программного продукта в публичном пространстве.
Именно совместное использование инструментов SAST и SCA дают адекватные результаты проверки кода вашей программной разработки на постоянной основе и на самых ранних стадиях.
Заблуждение №3. «Анализ кода нужно начинать с SAST»
В реальности быстрее и проще начать с SCA.
После февраля 2022 года российские компании ощутили на себе очень высокую активность атак, усилилась необходимость повышения безопасности разработки. Сейчас особенно требуется быстро и эффективно реагировать на найденные уязвимости в коде. SAST-сканеры проверяет проприетарный код, SCA-инструменты – открытый код, вместе они обеспечивают входную проверку кода на самых ранних стадиях разработки. SCA является первым звеном противодействия Supply Chain Attack (атака на цепи поставок или атака с эксплуатацией доверия к сторонней организации), неподходящие компоненты отсекаются на входе и обнаруживаются на последующих этапах в ходе непрерывного мониторинга. Для включенного open source выдаются рекомендации по исправлению известных уязвимостей. Автоматизированные политики проверки SCA довольно просты, никакого сложного тюнинга для снижения ложных срабатываний не нужно. В совокупности эти свойства SCA позволяют быстро и с наименьшими усилиями выполнить все основные проверки open source компонентов: провести инвентаризацию прямых и транзитивных зависимостей, проверить лицензионные соглашения, обнаружить известные уязвимости и выдать рекомендации по исправлению.
Компоненты с открытым кодом стали особенно популярной мишенью для атак на российские предприятия, при этом opensource составляет, как правило, большую часть программной разработки, и его контроль является ключевой задачей. Разработчики применяют ряд мер по защите, в частности, карантин для новых сборок, файерволл для загрузки неподходящих компонентов, отслеживание появления новых уязвимостей и реагирование на них. Для реализации автоматизированных политик в части open source применяются инструменты SCA, причем российское производство не уступает по качеству и функциональным возможностям зарубежным аналогам.
Если у вас уже используется SAST-сканер, то включение в ваши процессы SCA не составит проблемы. Если же вы только начинаете строить безопасную разработку, то с SCA начать будет проще всего.
Автор: Орешкина Дарья, директор по развитию бизнеса Web Control
Источник ►
Источник ►