Comments 14
Доля уязвимостей, найденных статическими анализаторами ничтожно мала по сравнению с тем, на что натыкаются эксперты при анализе кода. Стоило обратить внимание людей на шеллшок, как там нашли сразу по меньшей мере 6 (!) уязвимостей и наложили около 30 патчей.
Из последних на моей памяти реально присвоенных CVE, что нашли анализаторы — уязвимость в Х.org, которую нашёл cppcheck. Это капля в море в пересчёте на адское количество ложных срабатываний.
В итоге так и живём — вся суть отечественного аудита кода заключается в гуглении CVE-шек из OpenSource проектов.
Из последних на моей памяти реально присвоенных CVE, что нашли анализаторы — уязвимость в Х.org, которую нашёл cppcheck. Это капля в море в пересчёте на адское количество ложных срабатываний.
В итоге так и живём — вся суть отечественного аудита кода заключается в гуглении CVE-шек из OpenSource проектов.
Ну так статический анализатор — не большая кнопка «Сделать хорошо». Это еще один инструмент на ряду с качественной IDE и другими инструментами, помогающими в разработке.
Так и речь не о том, что анализатор взял и выдал: «у вас CVE-2014-XXXX в строке номер 150», а о том, насколько реально помогли анализаторы при ловле этих самых CVE. Касательно аудита безопасности успешных примеров пока маловато, чтобы говорить о том, что анализатор помогает в обнаружении уязвимостей. Ибо уязвимость — это не просто ошибка, а ошибка, которую (пусть даже в теории) можно проэксплуатировать, но анализатор не может подсказать, как именно, он не знает особенности этой программы и не знает, что в этой строке может оказаться пароль или внешние данные. Именно поэтому мы редко видим новости «Анализатор ХХХ помог найти уязвимость YYY», хотя уязвимости в СПО отстреливают ежедневно.
На мой взгляд то о чем вы говорите и есть вышеупомянутая кнопка. Сейчас анализаторы находят возможные утечки, undefined behavior, опечатки — то, что может привести к падению программ, багам и возможно уязвимостям. А дальше уже обработать эту информацию должен программист.
Вот как раз вот в «обработать эту информацию должен программист собака и порылась». Статический анализатор — он работает локально и многого просто не видит. В любых программах мало-мальски разумного размера есть дикое количество кода, который либо вообще никогда не исполняется, либо никогда не вызывает ошибок определённого вида. Скажем то же самое сравнение
Теоретически, эту ошибку хорошо бы пофиксить всё равно, но спешки тут никакой нету. А вот если asan+fuzzer вам показали, что при определённых условиях у вас может быть выход за границы массива — то это, грубо говоря, уже пол-exploit'а. Вы уже точно знаете что ошибка проскочила через все имеющиеся у вас проверки и, почти наверняка, как-нибудь себя да проявит и «в бою».
m_szPassword != '\0' может быть типа как «настоящей» ошибкой, но если в вышестоящей функции стоит проверка if (strlen(m_szPassword) < minLen) return false; то эта ошибка никогда и никак не сможет проявиться.Теоретически, эту ошибку хорошо бы пофиксить всё равно, но спешки тут никакой нету. А вот если asan+fuzzer вам показали, что при определённых условиях у вас может быть выход за границы массива — то это, грубо говоря, уже пол-exploit'а. Вы уже точно знаете что ошибка проскочила через все имеющиеся у вас проверки и, почти наверняка, как-нибудь себя да проявит и «в бою».
Acronis это вы метко привели. Мы уже два года почти используем их кривущий в доску бэкап в Parallels Cloud Storage, мало того, что скорость его зависит от фазы луны, так еще без использования их тулкитов его невозможно распаковать ни клиенту, ни владельцу продукта — в доску проприетарный формат.
Так что плохой пример и про Акронис ничего хорошего сказать не хочется.
Так что плохой пример и про Акронис ничего хорошего сказать не хочется.
Acronis Backup написан на Си++ и над этим постоянно трудится 70 программистов.
А писался бы на Java/C#/чем-нибудь подобном, возможно, вместо 70 программистов хватило бы 30. Цифрами гордиться нужно аккуратно, с оглядкой… :)
Я уверен, что Вы переоцениваете вклад языка в разработку больших проектов. В таких проектах на передний план выступают совсем другие нюансы, сложности, организационные задачи и так далее, а вовсе не тип используемого языка. Разница составит максимум проценты (и ещё не известно, в какую сторону).
У вас в каждом посте не менее трети (а то и половины) ошибок — это специфика именно низкоуровневых языков, вроде ручного управление памятью. По-моему, снижение числа багов из-за используемого языка на 30-50% — достаточно полезная штука.
Обращаю внимание, я не отрицаю важности низкоуровневых языков — для встраиваемого железа или мест, где нужно вытянуть предельную производительность (те же драйвера, игровые движки, системные утилиты) без них никак. Но там, где производительность не является ключевым приоритетом — там, по-моему, managed-языки предпочтительны.
Обращаю внимание, я не отрицаю важности низкоуровневых языков — для встраиваемого железа или мест, где нужно вытянуть предельную производительность (те же драйвера, игровые движки, системные утилиты) без них никак. Но там, где производительность не является ключевым приоритетом — там, по-моему, managed-языки предпочтительны.
Здравствуйте!
Мы пользуемся cmake под Линукс. Насколько я понял, PVS-Studio существует только под Windows. Мне бы хотелось проверить наш проект статистическим анализатором кода, и, при наличии серьёзных результатов, выдвинуть предложение руководству по внедрению.
Какие есть решения под Линукс и cmake?
Мы пользуемся cmake под Линукс. Насколько я понял, PVS-Studio существует только под Windows. Мне бы хотелось проверить наш проект статистическим анализатором кода, и, при наличии серьёзных результатов, выдвинуть предложение руководству по внедрению.
Какие есть решения под Линукс и cmake?
Если есть возможность дать нам исходники, мы можем попробовать проверить проект и сделать презентацию по результатам. Если нет, то Вы можете попробовать подготовить препроцессированные *.i файлы и проверить их с помощью Standalone версии PVS-Studio. Результат может быть не очень, но для попробовать, что-то посмотреть и найти — подойдёт. Потом уже можно рассмотреть приобретение лицензии и доработку напильником для нужд проекта.
Coverity, например
Sign up to leave a comment.
По мотивам «трёх интервью о статических анализаторах», или четвертое интервью