Комментарии 9
Поверьте, от разработчиков будет много лестных слов, когда они узнают, что им подключили SAST.
Не факт. Слишком много ложно положительных бывает.
Это фраза с сарказмом. :)
А уж причины "лестных слов" разные, судя по рассказам. False positives — одна из, да.
Ну, на самом деле я бы пережил FP, при одном простом условии — что можно было бы отключать конкретные проверки. Скажем, у меня вот вообще не веб приложение, то есть, это по сути, консольная утилита. При этом запуская ее, пользователь может передать фактически любые параметры. SAST же в свою очередь, все время ругается, что вот тут у вас параметры не санируются, то, се. А ведь все это фигня, и никакой уязвимости в этом месте нет, это путаница в голове у движка (ну или что там у него вместо головы?). Можно передавать любые параметры, любые пути к файлам — это нормальное поведение пользователя. Но выключить эту проверку я могу только в этой конкретной строке кода — а чтобы глобально, так нет. Считается, что я недостаточно умен по сравнению с теми, кто настраивал SAST ;) тоже сарказм, если чо.
Но выключить эту проверку я могу только в этой конкретной строке кода — а чтобы глобально, так нет.
Я думал, это достаточно типовой кейс настройки SAST'ов (и стат. анализаторов), и они должны бы давать такую функциональность из коробки. Что нужно — оставляем, что не нужно — вырубаем. Не поштучно, а именно конкретные чекеры/диагностики/проверки.
Допускаю, что это искажение в духе "У нас есть, вещь полезная. Очевидно, что это должно быть у других".
Да, скорее всего. Его так админят (у нас).
Проблема-то не с инструментом, а с теми кто его настраивает. Судя по фразе "Считается, что я недостаточно умен по сравнению с теми, кто настраивал SAST", нужная выключался есть, только вот те кто имеют к ней доступ — не знают зачем она нужна. Просто уверены, что чем больше проверок включено — тем безопаснее.
В докладах я усмотрел общую мысль: разработчики не рады внедрению SAST
Разработчики обычно не рады особым безопасникам, которые в пятницу вечером запускают саст и уже в понедельник утром вешают на доску urgent-blocker-super-pooper таски и блокают пайплайны. То есть кодерам обычно все равно, что кодить, а вот коленом поддых получать неприятно.
Решается это, как ни странно, без рокет-саенса. Четко очерчивается срок переходного периода плюс до бизнеса доводится мысль, что дополнительная активность может требовать дополнительных ресурсов. Работал в конторах с сонаркубом, чекмарксом, нексусом айкью - никаких проблемы особо не было.
Спасибо за фидбек, интересно.
Четко очерчивается срок переходного периода плюс до бизнеса доводится мысль, что дополнительная активность может требовать дополнительных ресурсов.
Можете поподробнее рассказать про этот процесс? Интересно.
Если я правильно понял из описания, то спецы по безопасности периодически запускали SAST, собирали ворнинги и отдавали их разработчикам. При этом какого-то регулярного (условно, еженощного) анализа не было?
Я слышал про разные подходы от "после настройки все предупреждения SAST'ов отдаём в разработку" до "составляем чуть ли не POC на каждую проблему, и уже затем отдаём разработчикам". Интересно, как было у вас.
Очень разумно описан мини-подпроцесс. Но это уже когда пройдены все степени до принятия, по известной модели восприятия неизбежного :)
Перепрыгнуть "ресурсную пропасть" не всем удается.
Гораздо более распространена модель SSDLC "на минималках", когда этот самый переходный период превращается в слабоумие и отвагу. Кто-то где-то кому-то в высоких кабинетах обещает что "отработает" все вопросы защищенности приложения "до выхода в прод", ну раз мы уже "почти все сделали". Бабло побеждает зло )))
Снятся ли разработчикам безопасные приложения?