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

Доступны бесплатные и коммерческие решения SAST. Имеет ли значение, какой использовать? Мы протестировали некоторых из них, чтобы выяснить, как они справляются с обнаружением уязвимостей в системе безопасности.

Как извлечь выгоду из инструментов SAST

Ошибки программирования порождают ошибки, и ошибки могут использоваться как уязвимости системы безопасности. Инструменты SAST используются для скорейшего обнаружения плохого кода, прежде чем он станет частью продукта. Использование этих инструментов считается лучшей практикой в ​​современных конвейерах разработки программного обеспечения и принципах DevSecOps.

Инструменты SAST можно использовать в основном двумя способами.

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

Инструменты SAST можно использовать путем интеграции в редактор кода или как часть репозитория и конвейера сборки.

Что является ошибкой или уязвимостью, зависит от используемых языков программирования и фреймворков. Ошибка программирования на языке C очень отличается от плохого кода Java или Swift. Следовательно, статический анализ кода также зависит от языка программирования.

Некоторые решения SAST ориентированы на решение проблемы качества кода на определенных языках программирования, в то время как другие охватывают большое количество языков. Ваш подход должен соответствовать технологиям, с которыми вы работаете.

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

Не серебряная пуля

Хотя инструменты тестирования статического анализа кода полезны, они имеют свои ограничения. Мы создали это сравнение, чтобы изучить эти ограничения и производительность некоторых популярных инструментов SAST.

Мы решили использовать для сравнения язык C. Даже если этот язык не является предпочтительным для новых проектов, многие популярные программы, которые мы используем сегодня, написаны на C или C ++ и активно поддерживаются. C также общеизвестно сложно безопасно программировать, что делает еще более важным наличие хороших инструментов.

Что является ошибкой или уязвимостью, зависит от используемых языков программирования и фреймворков.

В качестве основы для анализа мы будем использовать Примеры безопасного кодирования на Си. Правила безопасного кодирования для C были написаны с учетом типичных ошибок программирования. Следование стандарту снижает вероятность появления ошибок в вашем коде.

Автоматическая оценка серьезности может вводить в заблуждение

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

Хотя рейтинги полезны для определения приоритетов вашей работы, имейте в виду, что проблемы с низкой серьезностью также могут создавать уязвимости.

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

Инструменты обычно имеют разные уровни серьезности обнаруженных ошибок. Было бы разумно просмотреть результаты в порядке приоритета, исправляя в первую очередь проблемы, связанные с безопасностью, и другие критические проблемы, а пока не разрешать новые проблемы для нового кода. Однако есть примеры, когда доверие к автоматизированным рейтингам серьезности вводило в заблуждение. Хотя рейтинги полезны для определения приоритетов вашей работы, имейте в виду, что проблемы с низкой серьезностью также могут создавать уязвимости.

Известная проблема проверки сертификата сервера Apple SSL - пример проблемы, которую инструмент может классифицировать как низкую серьезность. Https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1266.

Обратите внимание на два «goto fail»; линии спина к спине. Первый правильно является частью оператора if, но второй будет переходить в конец функции перед проверкой хэша сертификата.

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

Инструменты, выбранные для сравнения

Для сравнительного тестирования мы выбрали следующие инструменты:

  • Clang - это компилятор с открытым исходным кодом для C-подобных языков программирования. Компилятор Clang включает также инструмент статического анализа кода. Clang поддерживает C-подобные языки, а статический анализ кода также поддерживает C, C ++ и Objective-C. Для этого теста использовалась версия Clang 9.0.0.
  • Infer - это инструмент статического анализа кода с открытым исходным кодом. Первую версию инструмента разработала команда, работающая в Facebook. Infer поддерживает Android, Java, C / C ++ и Objective-C. Для C Infer фокусируется на проверке разыменования нулевого указателя, утечек памяти, соглашений о кодировании и недоступных API. Для этого теста использовалась версия Infer 0.17.0.
  • SonarQube - это коммерческий инструмент статического анализа кода. SonarQube поддерживает более 24 языков кодирования, а также предлагает поддержку C / C ++. Для этого теста использовалась облачная версия SaaS под названием SonarCloud.
  • GitHub CodeQL - это механизм семантического анализа кода с открытым исходным кодом. CodeQL поддерживает языки программирования C / C ++, C #, Go, Java, JavaScript / TypeScript и Python. Для этого теста был создан репозиторий GitHub и включен CodeQL.

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

Все используемые инструменты и сервисы были последней версии, доступной на момент тестирования в сентябре и октябре 2020 года.

Результаты теста

Наш тестовый набор примеров стандарта безопасного кодирования C дал следующие результаты.

SonarQube обеспечил лучший уровень обнаружения по всем уровням серьезности.

Мы предоставляем подробную разбивку по результатам нашего репо.

Анализ

Три популярных инструмента статического анализа кода с открытым исходным кодом не показали хороших результатов в нашем тесте с использованием примеров Secure C Coding Standard.

Clang оказался лучшим из протестированных инструментов, чуть меньше половины обнаруженных примеров с высокой степенью серьезности. И Clang, и Infer лучше справились с обнаружением кода, нарушающего правила управления памятью Secure C Coding. Clang пропустил только одну выборку из восьми выборок с высокой степенью важности управления памятью. При разработке инструмента основное внимание уделялось выявлению наиболее критических типов ошибок, и, как утверждают сами проекты, инструменты все еще находятся в стадии разработки.

SonarQube работал довольно равномерно по уровням серьезности. Инструмент справился с обнаружением образцов намного лучше, чем его аналоги с открытым исходным кодом. Тем не менее, он пропустил примерно одну треть образцов, даже на самом высоком уровне серьезности.

CodeQL не блещет ошибками управления памятью, обнаружив всего три образца. Вдобавок CodeQL, кажется, работает намного хуже, чем Clang или Infer с целочисленными образцами и образцами с плавающей запятой. Однако по сравнению с Clang или Infer CodeQL лучше работает с образцами ввода / вывода, чем другие анализаторы кода с открытым исходным кодом.

При сравнении результатов инструменты в основном пересекаются. Совокупные результаты для всех сканеров с открытым исходным кодом увеличились бы до 58 для правил с высокой степенью серьезности, 28 для правил со средней степенью серьезности и 33 для правил с низкой степенью серьезности.

Стоит упомянуть, что использование как Clang, так и Infer обнаружит все образцы с высокой степенью серьезности управления памятью. Кроме того, инструменты с открытым исходным кодом могут обнаруживать 10 образцов высокого, 5 среднего и 10 низкого уровня серьезности, которые пропустил SonarQube. Использование инструментов с открытым исходным кодом в дополнение к SonarQube увеличивает скорость обнаружения SonarQube на 7–11 процентных пунктов в зависимости от серьезности.

Вывод

Наше тестирование с примерами Secure C Coding Standard показывает, что производительность тестируемых инструментов сильно различается. Ни один из инструментов не позволял обнаруживать хорошо задокументированные уязвимые примеры.

Имеет смысл выяснить, какой инструмент или их комбинация обеспечат наилучшую совместимость с вашими стандартами кодирования.

В целом, у инструментов с открытым исходным кодом были ограниченные преимущества. Кажется, обработка примеров стандарта безопасного кодирования C не была приоритетом при их разработке. Это не значит, что они бесполезны для команд разработчиков. Им все же удалось обнаружить множество образцов, особенно в области управления памятью, где коренятся многие уязвимости, связанные с кодом C.

У SonarQube, обнаружившего множество примеров кода, все же были некоторые промахи. В этом тесте уровень обнаружения SonarQube увеличился на 7–11 процентных пунктов в зависимости от серьезности при использовании вместе с инструментами с открытым исходным кодом. Даже при объединении инструментов коэффициент пропусков может составлять от 20 до 33 процентов в зависимости от серьезности.

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

Ссылки