Снятся ли разработчикам безопасные приложения?

1047_DoDevelopersDreamOfSecurity_ru/image1.png


Волнует ли разработчиков безопасность кода? Для меня вопрос открыт. Эта статья — своего рода опрос: хочу собрать мнения как разработчиков, так и специалистов по безопасности.


Поможете?


Расскажу, откуда у меня интерес к этой теме.


Я работаю над PVS-Studio. С одной стороны, это инструмент для поиска ошибок в коде, с другой — дефектов безопасности. То есть PVS-Studio сочетает в себе как черты "классического" статического анализатора, так и SAST-решения.


В последнее время меня интересует именно позиционирование PVS-Studio как SAST-решения. Хочется лучше понимать, чего команды ждут от подобных инструментов. С какими проблемами они сталкиваются при внедрении? Что для них важно, а что — нет? Как устроены процессы работы с выхлопом инструментов?


Чтобы найти ответы на эти вопросы, я решил посмотреть доклады с конференций по безопасности — на них чаще рассказывают про опыт внедрения SAST. После просмотра десятка докладов у меня сложилось впечатление, что… разработчикам вообще-то SAST и не особо интересен.


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

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


Однако SAST всё же закрывает часть проблем с безопасностью кода. Поэтому команды, которые строят secure SDLC, внедряют его в процессы. При этом в разных компаниях используют разные подходы:



В первом случае разработчики хакают систему (например, подавляют предупреждения без разбора), во втором — не разбирают выхлоп анализатора.


Заставить людей культурно поменять своё мышление и ходить править свои баги самостоятельно — это прямо отдельная история.

Тут возникает такой вопрос: волнует ли разработчиков безопасность кода?


Казалось бы, SAST-решения должны помогать повышать её. Да, есть минусы в виде false positives, и всё же. Из-за чего тогда возникает конфликт? Проблема в инструментах, в процессах — или и в том, и в другом?


Здесь мне и нужна ваша помощь — прошу рассказать о вашем опыте и помочь найти ответы.


Есть ли конфликт интересов между командами разработки и безопасности? Как внедрён SAST? Что в инструменте важно, а что — нет? Кто работает с результатами анализа? Как вообще организован процесс?


Делитесь опытом и мыслями: как устроены процессы у вас, что нравится, что — нет, и как можно было бы сделать лучше.

@SergVasiliev
25.04.2023 14:30 UTC
Первоисточник

Комментарии

@sshikov
25.04.2023 09:50 UTC
0
Поверьте, от разработчиков будет много лестных слов, когда они узнают, что им подключили SAST.

Не факт. Слишком много ложно положительных бывает.
@SergVasiliev
25.04.2023 10:07 UTC
0

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

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

25.04.2023 10:42 UTC
+1

Ну, на самом деле я бы пережил FP, при одном простом условии — что можно было бы отключать конкретные проверки. Скажем, у меня вот вообще не веб приложение, то есть, это по сути, консольная утилита. При этом запуская ее, пользователь может передать фактически любые параметры. SAST же в свою очередь, все время ругается, что вот тут у вас параметры не санируются, то, се. А ведь все это фигня, и никакой уязвимости в этом месте нет, это путаница в голове у движка (ну или что там у него вместо головы?). Можно передавать любые параметры, любые пути к файлам — это нормальное поведение пользователя. Но выключить эту проверку я могу только в этой конкретной строке кода — а чтобы глобально, так нет. Считается, что я недостаточно умен по сравнению с теми, кто настраивал SAST ;) тоже сарказм, если чо.

25.04.2023 11:46 UTC
0

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

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

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

25.04.2023 13:10 UTC
0

Да, скорее всего. Его так админят (у нас).

25.04.2023 13:43 UTC
0

Проблема-то не с инструментом, а с теми кто его настраивает. Судя по фразе "Считается, что я недостаточно умен по сравнению с теми, кто настраивал SAST", нужная выключался есть, только вот те кто имеют к ней доступ — не знают зачем она нужна. Просто уверены, что чем больше проверок включено — тем безопаснее.

@panzerfaust
25.04.2023 10:07 UTC
+1

В докладах я усмотрел общую мысль: разработчики не рады внедрению SAST

Разработчики обычно не рады особым безопасникам, которые в пятницу вечером запускают саст и уже в понедельник утром вешают на доску urgent-blocker-super-pooper таски и блокают пайплайны. То есть кодерам обычно все равно, что кодить, а вот коленом поддых получать неприятно.

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

@SergVasiliev
25.04.2023 12:09 UTC
0

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

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

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

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

@mugalem
28.04.2023 03:06 UTC
0

Очень разумно описан мини-подпроцесс. Но это уже когда пройдены все степени до принятия, по известной модели восприятия неизбежного :)

Перепрыгнуть "ресурсную пропасть" не всем удается.

Гораздо более распространена модель SSDLC "на минималках", когда этот самый переходный период превращается в слабоумие и отвагу. Кто-то где-то кому-то в высоких кабинетах обещает что "отработает" все вопросы защищенности приложения "до выхода в прод", ну раз мы уже "почти все сделали". Бабло побеждает зло )))