Комментарии 5
Есть важный момент: часто SAST вызывает у людей чувство, что почти любая проблема будет отловлена на этапе анализа исходного кода. В то время, как качество SAST состоит как минимум из 4 китов:
Качество сканирующего ядра
Качество и полнота правил
Качество документации (как следствие, либо качество интеграции, либо хотя бы шанс не пропустить неочевидный момент) и поддержки поставщика (иногда понять, как сканировать какой-то код, или почему возникает проблема, бывает крайне сложно). Например, даже при использовании весьма качественного SonarQube можно легко пропустить критичную SQL-инъекцию просто потому, что тот, кто использует систему, не знал о том, как именно работает подавление уязвимостей.
Соответствие рекламных материалов реальности (обожаю SAST, которые заявляют поддержку кучи функционала, хотя в реальности не имеют либо правил под него, либо вообще не поддерживают).
Поэтому я почти призываю писать перед каждой статьей, что SAST (и вообще SSDLC) - это очень сложно, но очень круто.
Спасибо за комментарий.
часто SAST вызывает у людей чувство, что почти любая проблема будет отловлена на этапе анализа исходного кода
Кстати, недавно с коллегой обсуждали подобную тему. Не возникает ли у людей ощущения, что если внедрить SAST, это даст 100% защиту от уязвимостей?
Мол, написано, что SAST-тул ловит XSS - значит мы от них полностью защищены.
Хочется верить, что в целом есть понимание, что никакой тул не даёт 100% гарантии.
как следствие, либо качество интеграции
Я бы интеграцию даже в отдельный пункт вынес. Хочется, чтобы всё заводилось быстро и без танцев с бубном.
Как минимум это полезно в плане "попробовать и познакомиться" с инструментом: легко поставить, проанализировать, посмотреть самые интересные предупреждения.
Но и при внедрении / регулярном использовании не менее важно: удобство выполнения baseline, false positives обработать, прикрутить к CI и т. д.
Не возникает ли у людей ощущения, что если внедрить SAST, это даст 100% защиту от уязвимостей?
Мол, написано, что SAST-тул ловит XSS — значит мы от них полностью защищены.
Если бы вы видели, как это выглядит в реальности, вам бы возможно было не смешно. У нас вот сканирование SAST обязательно в процессе релиза любого продукта. И в моем продукте оный сканер ловит XSS. Это было бы замечательно — только продукт не имеет никакого отношения к вебу. То есть XSS у нас в принципе невозможно даже представить себе. Ну то есть, может быть для типовых приложений оно и имеет какой-то смысл, а для нашего нетипичного все те предупреждения, что оно генерирует — не более чем мусор.
Вовсе не хочу сказать, что применять не надо. Надо просто голову прикладывать, как впрочем и всегда.
Если бы вы видели, как это выглядит в реальности, вам бы возможно было не смешно.
Так я и не смеялся. :)
Надо просто голову прикладывать, как впрочем и всегда.
Один из лучших советов по жизни в принципе, как по мне.
все те предупреждения, что оно генерирует — не более чем мусор.
Вспомнил Heisenbug 2021. Во время общений в дискуссионке всплывала похожая история. Что-то в духе того, что SAST-тул ругался на использование taint-данных, хотя им неоткуда было взяться. Результат - боль, страдания, мучения.
В целом, как микроскопом не нужно забивать гвозди, так и каждому инструменту своё применение.
Только стоит помнить, что:
проблема может выстрелить там, где не ждали. В духе: "Да какие тут уязвимости? А, ой.";
бывает, разработчики думают, что стат. анализатор (не только SAST) фолсит. По факту оказывается, что тул прав.
Место SAST в Secure SDLC: 3 причины внедрения в DevSecOps-пайплайн