Comments 16
Смотрите - именно типы ошибок, если мы говорим об анализе общего назначения (т.к. например диагностики по стандарту MISRA С точно никогда не пересекуться с другими языками), между данными 3-мя языками (C++, C#, Java) пересекаются достаточно сильно - речь идёт о десятках процентов таких общих ошибок. Это, однако, не означает, что в одном из анализаторов мы получаем "бесплатные" ошибки, если они уже есть в другом - по крайней мере, в случае с PVS-Studio, нам всё-равно приходится реализовывать такие общие диагностики в каждом анализаторе отдельно.
Конечно, мы переиспользуем уже имеющуюся экспертизу по такой диагностике, что сильно помогает, но это всё-таки не "бесплатно". Теоретически, такай подхват общих диагностик анализаторами для разных языков возможен (и мы знаем, что такие анализаторы есть) - обычно это делается на уровне некоего общего промежуточного представления, в котором работают сразу несколько анализаторов, однако в случае с PVS-Studio исторически сложилось так, что каждый анализатор уникален.
@PaullСпасибо за интересные статьи. Подскажите, где-нибудь можно найти сравнение вашего анализатора с другими? Например с Solar appScreener?
Рад, что вам понравилось!
По поводу сравнения с другими решениями - мы пробовали такой формат, уже достаточно давно, лет 6-7 назад, и пришли к выводу, что это, скорее, достаточно неблагодарное занятие, если мы занимаемся этим сами. К сожалению, у читателя всегда остаётся ощущение предвзятости. Сравнение анализаторов вообще достаточно сложная задача, т.к. оно затрагивает очень много факторов, и, в большлинстве случаев, результатом получается некое пересечение множеств - каждый анализатор умеет что-то своё, что не умеет другой.
Поэтому сравнивать, как мне кажется, имеет смысл по какой-то конкретной характерристике, а не в общем. Если вас интересует что-то такое конкретное именно в плане сравнения с Solar appScreener - если вы её уточните, я попробую что-нибудь найти для вас.
У меня, кстати, на эту тему заметка была :). Почему мы не пишем о сравнении PVS-Studio с другими статическими анализаторами кода.
Вариант первый. Есть модули A и B допустим в одном Cmake проекте. технически пусть это будет библиотека и исполняемый файл его использующий. Допустим анализ делается через Clion. В таком варианте при межмодульном анализе при проверке исполняемого файла будут учитываться вычисленные виртуальные значения библиотеки B?
Если ответ да — более сложный вопрос.
Есть у нас проект A. В проект A входит библиотека B.
Компилируются они по отдельности.
Можно ли как то сделать файл метаданных или чего нибудь ещё по библиотеке B, чтоб при анализе проекта A использовались выведенные для B ограничения значений и вот это всё?
Ну то есть для основной компиляции есть хидеры и скомпилированная либа, а для анализа хидеры и какая то скомпилированная метаинформация?
PVS-Studio сохраняет информацию, собранную с помощью семантического анализа в файлы в специальном формате для каждой единицы трансляции соответственно. После чего, они объединяются в один для дальнейшего использования.
Если в вашем cmake проекте есть цели для сборки нужных библиотек, то они все будут учитываться при анализе. В текущей реализации, в ситуации, когда библиотека только линкуется, но её файлы с исходным кодом не присутствуют, её анализ не будет осуществляться, и, соответственно межмодульная информация не будет собрана.
В теории, нет ничего сложного в том, чтобы объединить межмодульную информацию для вашего проекта и стороннего, если они в реальности не нарушают ODR. Это хорошая идея для доработки интерфейсной части анализатора, но, пока что это придётся делать вручную (через ядро pvs-studio).
Я сейчас пишу статью о том, как у нас реализован межмодульный анализ. Хорошая идея будет там описать этот нюанс.
Большой проект в котором много модулей. Которые отдельно в том числе собираются на CI. В идеале вообще доделать Cmake скрипты, чтоб они вызывали анализ и формировали отчёт по таргету и как раз мета файл, который так же инсталился бы потом с либой для дальнейшего использования при проекте следующих проектов цепочки.
но, пока что это придётся делать вручную (через ядро pvs-studio).
Всмысле есть возможность самостоятельно написать плагин для этого или вызвать что-то из инструментария pvs, или речь о том что потенциально это есть, но никак недоступно пользователям?
И ещё немного не по теме… PVS пока не умеет анализировать конфигурации в WSL совсем из Clion, или требуется донастройка, установка самого PVS в WSL или что-то такое?
Всё зависит от структуры ваших проектов. Если они связаны одним CMake-скриптом на верхнем уровне, то межмодульный анализ и так отработает нормально.
Если у вас 2 отдельных, несвязанных друг с другом CMake-проекта, то всё сложнее. По умолчанию мы не разбираем CMake скрипты. Вместо этого используется сгенерированные последними файлы compile_commands.json, в которых содержатся все команды компиляции. Для каждой такой команды генерируется модуль результатов семантического анализа (DFO). Но, в compile_commands.json нет команд для компоновщика. Поэтому отследить внешние для вашего проекта библиотеки оттуда не получится.
По поводу скриптов. У нас есть CMake-модуль, который создаёт таргет для запуска анализа. На данный момент в нём не поддерживается межмодульный анализ. В теории, можно для таргетов, собираемых как библиотека, складывать рядом соответствующий DFO-файл. А потом разобрать у всех таргетов команды компоновки, и подключить его при необходимости. Но эту возможность нужно ещё исследовать, заранее сложно увидеть все подводные камни.
Что я имел в виду под ручным способом. C и C++ анализаторы PVS-Studio представлены ядром и набором вспомогательных утилит командной строки. Ядро - основная программа (PVS-Studio.exe для Windows и pvs-studio для Linux/macOS). Оно запускается в разных режимах, которые настраиваются через конфигурационные файлы. Для каждой единицы трансляции нужно протолкнуть соответствующий конфигурационный файл. Чтобы активировать межмодульный анализ, нужно в этих файлах прописать шаг, который вы выполняете. Всего их 3:
сбор семантической информации
слияние DFO модулей
запуск анализа с использованием объединённого DFO-файла
Помимо этого, в конфигурационных файлах прописывается и другая важная информация, например версия стандарта, платформа, препроцессор и т. д. Вручную писать их неудобно. Для этого мы и создали утилиты pvs-studio-anayzer (для Linux), или CompilerCommandsAnalyzer.exe для Windows. Их, к слову, использует плагин для CLion. А для анализа .sln используется PVS-Studio_Cmd.exe.
В этих утилитах на текущий момент не поддерживается функциональность, которую вы хотите. Однако само ядро может справиться с этой задачей, если правильно сгенерировать конфигурационные файлы. Но это, естественно, сложно и неудобно.
В нашей документации есть соответствующий раздел. Проcто стоит учесть, что описанные в нём сценарии уже несколько устарели (сейчас мы, в целом, не рекомендуем нашим пользователям лезть на такой низкий уровень настройки анализатора), и там могут быть описаны не все возможные параметры настройки. Но общую идею из этого документа понять можно, мне кажется. Если что, коллега @Minatychможет дополнит про какие-то более специфичные настройки, которые вам могут быть интересны.
@Paull Постарался описать кейс использования.
Наша основная цель: поиск уязвимостей и НДВ в наших продуктах и сторонних продуктах, которые мы используем в работе.
Пользователи анализатора в первую очередь сотрудники ИБ с минимальным опытом разработки, а во вторую разработчики.
Мы используем довольно много различных open source решений и хотелось бы анализировать:
Языки:
java;
groovy;
python;
php;
javascript;
pl/sql.
Минимум:
рекурсивно .jar файлы;
.class файлы;
структуру jsp страниц.
Критичные для нас моменты:
возможность анализа бинарных файлов (с использованием декомпиляции и деобфускации);
сравнение результатов сканирований и ретроспектива уязвимостей от версии к версии ПО с отображением сохранившихся, устранённых и новых уязвимостей;
ручное управление уровнем критичности уязвимостей;
рекомендации по настройке средств защиты (для веб-приложений), рекомендации по настройке WAF;
классификация уязвимостей по OWASP/PCI DSS/HIPAA/CWE;
наборы готовых правил сканирования с возможностью редактирования, создание своих пресетов из правил;
пополняемая база уязвимостей и НДВ;
интеграция с jira, git, gitlab, github, jenkins в идеале с Intellij IDEA и teamcity;
выгрузка результатов сканирования в json/csv/pdf.
PVS-Studio поддерживает языки C, C++, Java и C#. Соответственно, из перечисленных пунктов, для поддерживаемых нами языков, часть из данных требований мы поддерживаем (например, классификации по OWASP и CWE), часть не поддерживаем (например, HIPAA и анализ бинарных файлов). У нас есть поиск потенциальных уязвимостей, но нет поиска НДВ.
Т.е. именно по критичным для вас требованиям у нас сейчас есть не все возможности и не все языки.
Если вам интересно подробнее обсудить соответсвие данным специфичным требованиям по тем языкам, что мы поддерживаем, я думаю, нам лучше было бы перейти в формат более личной беседы - если бы вы отправили нам этот список в поддержку, мы бы ответили подробнее по каждому конкретному пункту.
@Paull, мы с коллегами дополним список и напишем обращение в саппорт. Спасибо.
Кстати, вот вам идея на заметку: SimpleDateFormat в Java может подготовить сюрприз к Новому году: год, написанный маленькими буквами совсем не то же самое, что год, написанный большими. В последнюю неделю старого года вы можете вдруг оказаться в будущем, потому что "YYYY" — это 2022 для дат 27.12.2021 — 31.12.2021, а не 2021, как кто-то может ожидать. Нужно использовать "yyyy"
Технологии статического анализа кода PVS-Studio