Мораль сей басни такова: хочешь чтобы всё было правильно - делай сам.

Это так не работает :)

Всё-таки мы никуда не уйдём от использованиях сторонних компонентов. А что уж у них внутри — одним разработчикам известно (и то не факт).

Кстати, про "делать сам". В Java есть интересный момент, связанный с XXE: general entitites и parameter entities могут выключаться разными настройками. Видел, как в опенсорс проектах после репорта об XXE отключали одни настройки и забывали про другие...

И философский вопрос - стоит или не стоит полностью полагаться на изготовителей замков для дверей?

42 :)

КМК, вопрос сильно субъективный — каждому своё.

Не могу отредачить комментарий, отдельно напишу.

Почта: ссылка криво встала. Эл. почта: support@jugru.team
Бот: не могу сказать, напишу ребятам в поддержку.

Уточнил в поддержке организаторов конференций — нужно написать им в саппорт (на почту или в Телеграм).

Также записи докладов обычно выкладывают в общий доступ на YouTube ближе к следующей соответствующей конференции.

Проект старенький, информация об уязвимости — свежая. :)

Спасибо за фидбек, интересно.

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

Можете поподробнее рассказать про этот процесс? Интересно.
Если я правильно понял из описания, то спецы по безопасности периодически запускали SAST, собирали ворнинги и отдавали их разработчикам. При этом какого-то регулярного (условно, еженощного) анализа не было?

Я слышал про разные подходы от "после настройки все предупреждения SAST'ов отдаём в разработку" до "составляем чуть ли не POC на каждую проблему, и уже затем отдаём разработчикам". Интересно, как было у вас.

Но выключить эту проверку я могу только в этой конкретной строке кода — а чтобы глобально, так нет.

Я думал, это достаточно типовой кейс настройки SAST'ов (и стат. анализаторов), и они должны бы давать такую функциональность из коробки. Что нужно — оставляем, что не нужно — вырубаем. Не поштучно, а именно конкретные чекеры/диагностики/проверки.

Допускаю, что это искажение в духе "У нас есть, вещь полезная. Очевидно, что это должно быть у других".

Это фраза с сарказмом. :)

А уж причины "лестных слов" разные, судя по рассказам. False positives — одна из, да.

И зачем вообще кому-то нужна эта библиотека?

200К загрузок у неё откуда-то набралось.

На самом деле меня тоже удивило отношение кол-ва загрузок пакета к кол-ву форков / звёзд проекта. Но имеем, что имеем.

Я и не придираюсь — отталкиваюсь от контекста.

Нет гарантий, что Foo возвращает ссылку на объект. С таким же успехом метод может вернуть значение null. Проверка намекает, что разработчик допускает такой сценарий.

Не проверяем слитые исходники.

Вот как Яндекс заопенсорсит что-нибудь — это пожалуйста. :)

Если вы следите за пресс-релизами или подписаны на рассылки, то вероятно знаете большую часть описанного. Как вариант — предлагаю пробежаться по разделу "Что нового: кратко".

И в опросе проголосуйте, пожалуйста. :)

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

Хочу запускать PVS-Studio C# на M1.

Для бесплатного использования в некоммерческих проектах есть несколько вариантов. Они описаны в этой статье.

Если хочется просто попробовать — легче воспользоваться триалом.

Тема сравнения инструментов на самом деле сложная. :(

Анализаторы — инструменты комплексные. То есть это не только про “выдать предупреждение”, но и про удобство интеграции, производительность, разные доп. возможности (типа лёгкого старта) и т. п.

Можно, конечно, всё свести к одним только возможностям анализа: чтобы предупреждения выдавал и не фолсил. Однако я думаю, это будет не совсем корректно.

Если всё-таки браться сравнивать инструменты исключительно по тем предупреждениям, которые они выдают — это тоже та ещё работёнка. Просто сравнить количество предупреждений — не вариант. Нужно тщательно анализировать вывод: смотреть true positives, false positives, а по-хорошему — и false negatives (хотя бы отталкиваясь от true positives других инструментов).

Окей, допустим, решили посмотреть true positives. Тут тоже начинаются интересности: одну и ту же ошибку разные инструменты скорее будут всего подсвечивать разными сообщениями, а вероятно — ещё и выдавать их на разные строки. Этой темы я касался в докладе "Как устроено тестирование средства статического тестирования", когда рассказывал про тестирование на бенчмарках.

Допустим, сделали сравнение, потратили кучу сил и времени.

Побеждает PVS-Studio. Какая будет реакция? Скорее всего что-то вроде: “Ага, ну конечно. Статью же люди из PVS-Studio писали — какие неожиданные результаты…”.

Побеждает не PVS-Studio. Тут у меня, как заинтересованного лица, появляется сильное желание улучшить анализатор, чтобы он показал себя лучше. Почти 8 лет жизни в продукт вложено — шутка ли? :)

Получается, что я пришёл примерно к тому же, что описано в первом пункте статьи “Почему мы не пишем о сравнении PVS-Studio с другими статическими анализаторами кода”. Это хорошо — кажется, она не потеряла своей актуальности. :)

Как же быть?

Если рассматривать вопрос с прагматической точки зрения, я бы переформулировал его так: "Какой из анализаторов принесёт больше пользы на нашем проекте: A, B или C?"

Как это понять? Попробовать. :)

P.S. Если решите попробовать PVS-Studio, рекомендую полистать заметку: "PVS-Studio: 2 фишки для быстрого старта". Она небольшая, но рассказывает о двух важных механизмах, которые сделают знакомство приятнее.

P.P.S. И ещё стоит помнить о философии статического анализа.

Скорее всего многие из ошибок были подсвечены "warning"-ами самой средой разработки (или ее плагином).

Когда я разбирал логи анализатора, то работал в Visual Studio. Насколько я помню, в текстовом редакторе она ни одного из выписанных мест не подсветила.

Что из этого детектит Rider, а что нет — сказать не могу. В любом случае, факт в том, что всё описанное ушло в релиз. :)

К сожалению, с таким отношением к коду/работе частенько сталкиваюсь :-(

Интересно, если поделитесь мыслями на этот счёт: что с этим делать?

Вопрос сравнения хороший, спасибо.

На самом деле коллеги уже проходили это на примере C++ анализатора. Ответ — в заметке “Почему мы не пишем о сравнении PVS-Studio с другими статическими анализаторами кода”.

Однако мне захотелось переосмыслить тему сравнения.
Комментарий получается большим, пришлось даже открыть Word, чтобы всё сформулировать. :)

Чуть позже напишу его в этой же ветке.

Всегда пожалуйста. Здорово, что удалось найти подходящий вариант использования. :)

Кушать хочется. :)

Если хочется попробовать — проще взять триал.

Если речь именно о регулярном бесплатном использовании — в этой статье разобрано несколько вариантов (для студентов, некоммерческих проектов и т. п.).

Жаль, что DotNext'а нет :(