Волнует ли разработчиков безопасность кода? Для меня вопрос открыт. Эта статья — своего рода опрос: хочу собрать мнения как разработчиков, так и специалистов по безопасности.
Поможете?
Расскажу, откуда у меня интерес к этой теме.
Я работаю над PVS-Studio. С одной стороны, это инструмент для поиска ошибок в коде, с другой — дефектов безопасности. То есть PVS-Studio сочетает в себе как черты "классического" статического анализатора, так и SAST-решения.
В последнее время меня интересует именно позиционирование PVS-Studio как SAST-решения. Хочется лучше понимать, чего команды ждут от подобных инструментов. С какими проблемами они сталкиваются при внедрении? Что для них важно, а что — нет? Как устроены процессы работы с выхлопом инструментов?
Чтобы найти ответы на эти вопросы, я решил посмотреть доклады с конференций по безопасности — на них чаще рассказывают про опыт внедрения SAST. После просмотра десятка докладов у меня сложилось впечатление, что… разработчикам вообще-то SAST и не особо интересен.
Поверьте, от разработчиков будет много лестных слов, когда они узнают, что им подключили SAST.
В докладах я усмотрел общую мысль: разработчики не рады внедрению SAST. Организовать процесс так, чтобы разработчики правили предупреждения — сложная задача.
Однако SAST всё же закрывает часть проблем с безопасностью кода. Поэтому команды, которые строят secure SDLC, внедряют его в процессы. При этом в разных компаниях используют разные подходы:
- одни действуют жестко и вводят блокирующий security gate на предупреждения SAST-решений;
- другие действуют мягче и не блокируют предупреждениями процессы разработки.
В первом случае разработчики хакают систему (например, подавляют предупреждения без разбора), во втором — не разбирают выхлоп анализатора.
Заставить людей культурно поменять своё мышление и ходить править свои баги самостоятельно — это прямо отдельная история.
Тут возникает такой вопрос: волнует ли разработчиков безопасность кода?
Казалось бы, SAST-решения должны помогать повышать её. Да, есть минусы в виде false positives, и всё же. Из-за чего тогда возникает конфликт? Проблема в инструментах, в процессах — или и в том, и в другом?
Здесь мне и нужна ваша помощь — прошу рассказать о вашем опыте и помочь найти ответы.
Есть ли конфликт интересов между командами разработки и безопасности? Как внедрён SAST? Что в инструменте важно, а что — нет? Кто работает с результатами анализа? Как вообще организован процесс?
Делитесь опытом и мыслями: как устроены процессы у вас, что нравится, что — нет, и как можно было бы сделать лучше.
Комментарии (9)
panzerfaust
25.04.2023 09:50+1В докладах я усмотрел общую мысль: разработчики не рады внедрению SAST
Разработчики обычно не рады особым безопасникам, которые в пятницу вечером запускают саст и уже в понедельник утром вешают на доску urgent-blocker-super-pooper таски и блокают пайплайны. То есть кодерам обычно все равно, что кодить, а вот коленом поддых получать неприятно.
Решается это, как ни странно, без рокет-саенса. Четко очерчивается срок переходного периода плюс до бизнеса доводится мысль, что дополнительная активность может требовать дополнительных ресурсов. Работал в конторах с сонаркубом, чекмарксом, нексусом айкью - никаких проблемы особо не было.
SergVasiliev Автор
25.04.2023 09:50Спасибо за фидбек, интересно.
Четко очерчивается срок переходного периода плюс до бизнеса доводится мысль, что дополнительная активность может требовать дополнительных ресурсов.
Можете поподробнее рассказать про этот процесс? Интересно.
Если я правильно понял из описания, то спецы по безопасности периодически запускали SAST, собирали ворнинги и отдавали их разработчикам. При этом какого-то регулярного (условно, еженощного) анализа не было?Я слышал про разные подходы от "после настройки все предупреждения SAST'ов отдаём в разработку" до "составляем чуть ли не POC на каждую проблему, и уже затем отдаём разработчикам". Интересно, как было у вас.
sshikov
Не факт. Слишком много ложно положительных бывает.
SergVasiliev Автор
Это фраза с сарказмом. :)
А уж причины "лестных слов" разные, судя по рассказам. False positives — одна из, да.
sshikov
Ну, на самом деле я бы пережил FP, при одном простом условии — что можно было бы отключать конкретные проверки. Скажем, у меня вот вообще не веб приложение, то есть, это по сути, консольная утилита. При этом запуская ее, пользователь может передать фактически любые параметры. SAST же в свою очередь, все время ругается, что вот тут у вас параметры не санируются, то, се. А ведь все это фигня, и никакой уязвимости в этом месте нет, это путаница в голове у движка (ну или что там у него вместо головы?). Можно передавать любые параметры, любые пути к файлам — это нормальное поведение пользователя. Но выключить эту проверку я могу только в этой конкретной строке кода — а чтобы глобально, так нет. Считается, что я недостаточно умен по сравнению с теми, кто настраивал SAST ;) тоже сарказм, если чо.
SergVasiliev Автор
Я думал, это достаточно типовой кейс настройки SAST'ов (и стат. анализаторов), и они должны бы давать такую функциональность из коробки. Что нужно — оставляем, что не нужно — вырубаем. Не поштучно, а именно конкретные чекеры/диагностики/проверки.
Допускаю, что это искажение в духе "У нас есть, вещь полезная. Очевидно, что это должно быть у других".
sshikov
Да, скорее всего. Его так админят (у нас).
mayorovp
Проблема-то не с инструментом, а с теми кто его настраивает. Судя по фразе "Считается, что я недостаточно умен по сравнению с теми, кто настраивал SAST", нужная выключался есть, только вот те кто имеют к ней доступ — не знают зачем она нужна. Просто уверены, что чем больше проверок включено — тем безопаснее.