Comments 13
Ох, как же я за#@#^%мучался с эти чекмарксом...
У нас в компании он живёт уже более года и сканирует каждый дистрибутив (точнее версию исходников, из которых дистрибутив собирается). Я за это время отметил как ложно-положительные несколько тысяч срабатываний. И нашёл только пару потенциальных уязвимостей. Это та самая реальная жизнь за пределами красивых демонстраций. Да, у нас большой solution с кучей проектов, из которого собирается дистрибутив в пачкой приложений. В итоге инструмент видит несуществующие пути кода, откровенно плохо понимает asp.net и т.д. и т.п...
А у вас какой стек, .net? Очень интересно мнение живых пользователей. Долго сканируется ваше приложение?
да, .net + oracle + angular в моём solution. Сканируется где-то час, но это он ещё не все исходники берёт. Весь объём исходников он не осилил, так что пришлось часть исключить из сканирования.
Важное примечание: у нас в компании очень много разрабатываемых систем и ежесуточно проходят тысячи сканирований - это накладывает некоторые ограничения.
А вы используете его из коробки или настраивали? Проводили анализ какие правила фонят? Может их можно скорректировать под ваш проект?
"Всё сложно" :) Он же у нас общий, обслуживает его отдельная команда. Базовый набор правил - owasp. Периодически накатывают новую версию - приходится вычёсывать очередную пачку срабатываний. Хорошо хоть он их запоминает (хотя иногда и забывает). А настраивать.... Ему логику править надо. Он плохо понимает структуру сложных систем (много приложений с общей кодовой базой). Теоретически можно тестировать каждое приложение по отдельности, но это слишком сложно организовать и будет занимать слишком много времени.
У меня на прошлой работе (в 2020-м) тоже продвигали этот инструмент. Стек - Java, Kotlin, SpringBoot, JdbcTemplate/MyBatis.
В итоге у меня жутко отрицательное мнение о CxSAST. Валидных срабатываний там от силы доля процента. И то, угадывание в основном на ошибках в духе "у вас поле static, но при этом не final".
Kotlin вообще не воспринимался анализатором (может версия какая-то урезанная у нас была..).
Поиск SQL-иньекций - вообще смех. Инструмент и видит, что какой-то параметр из MVC контроллера доходит до jdbcTemplate, а в SQL есть конкатенация - сразу жалуется на иньекцию. Хотя параметр прокидывается валидно, а конкатенация из двух строк констант (тупо SQL в одну строку не влазит в редакторе)
XML пытался парсить и анализировать как Java. И даже что-то там якобы находил с уровнем high опасности! (Там SQL у нас лежали, в которых при определенной фантазии можно было увидеть вызовы методов - а-ля ".. SUM(field_name) ..")
Groovy вроде поддерживался, но работал плохо. Влезал к нам в грейдл скрипты, и говорил, что "==" использовать нельзя, нужен ".equals(..)" что, в общем-то, бессмысленно для groovy.
В общем, совсем меня CxSAST не порадовал. Просто шумный инструмент, наугад тыкающий в каждую двадцатую строку. Где-то да угадает.
Расскажите подробнее про SonarQube. Почему было ожидаемо, что он не нашел ни одной уязвимости ни в одном проекте?
SonarQube не делает taint-анализ, поэтому полноценным SAST по сути не является....
Отличный вопрос! Как правильно написали выше, дело в taint-анализе. Вот можно почитать:
Мы использовали бесплатную версию, в которой его нет
Вообще ожидаемо увидеть качественные результаты на затертом до дыр dvja
Все знают этот проект и все тестируют любые инструменты на нем
Поэтому доверие за счет возможности что-то докрутить со стороны вендора под кейс сильно снижается
В реальности на закрытом проекте любой из перечисленных SAST ведет себя достаточно плохо и упускает жуткие тривиальные уязвимости....
Увы, но на нашей кодовой базе реального проекта (PHP) все вышеперечисленные сканеры показали нулевой результат по критическим уязвимостям. Условия испытаний были простые. Реальная кодовая база. Общее количество известных недостатков около 60 штук (каждый из недостатков был найден и валидирован ранее ручным ревью кода перед релизами). Из них 4 критических (3 SQL injection, 1 SSRF) Зато мы наслушались перлов некоторых вендоров, лучшими из них были: «покажите уязвимость, а мы покажем как ее искать», «у вас программисты пишут без использования лучших практик и наш SAST нужно тюнинговать именно под вас».
SAST unboxing