Часть 1.
Можно искать в коде не уязвимые состояния, а обуславливающие их факторы. Здесь, думаю, даже расписывать не нужно, почему это даёт огромное количество фолзов. Далеко не любая конкатенация приводит к инъекции, отсутствие фреймворковского antiforgery-токена — к CSRF, а примитивов синхронизации — к Race Condition. Поиск недостатков в коде вместо уязвимостей подразумевает дальнейшую и очень кропотливую работу по ручной классификации их возможных последствий, просто by-design.
Можно поиграть с понятием состояния и формальной моделью приложения. Модели уровня микрокода, процессора, виртуальной машины, семантики языка или размеченных потоков данных — настолько отличаются уровнем абстракции и своими состояниями, что между ними — пропасть. Но было бы довольно странно искать инъекции на модели микрокода, как и уязвимости спекулятивного выполнения на размеченных потоках данных. А значит, целые классы уязвимостей будут теряться, какая бы модель не оказалась выбрана.
Можно вообще не рассматривать целые классы состояний. Точнее даже нужно, в некоторых кейсах, иначе анализ зациклится на банальном:
for(;;) { /*…*/ }В общем-то, это — основная точка поиска баланса, между точностью, покрытием и временем анализа. Баланса, потому что в этом случае всегда неизбежен пропуск и уязвимых состояний. Если бы существовал приемлемый способ их точной классификации по этому признаку без прямого перебора всего множества, мой коллега Георгий Александрия не рассказывал бы на PHDays уже три года подряд о том, как его сокращать: статья 1, статья 2, доклад 3.
Именно поэтому в хорошем анализаторе не может быть малого количества ложноположительных срабатываний (FP) без большого количества ложноотрицательных (FN). И адский сотонализатор, дающий существенно меньшее количество FP, чем прочие, должен вызывать не лучи восторга, а большие вопросики к качеству анализа и проценту покрытия.
Но и это ещё не всё.
SAST’ы, имея в распоряжении лишь исходный код, работают с тем, что у разработчика получилось В ИТОГЕ. Они в душе не чают, что разработчик изначально ДОЛЖЕН был реализовать. У них нет ответа на вопрос «как должно быть?» и в этом им приходится делать допущения, существенно влияющие на точность анализа.
Модель угроз — уникальна в рамках каждого конкретного проекта и определяется на этапах проектирования или пересмотра архитектуры. Все существующие анализаторы же опираются на усредненную модель, плюс-минус соответствующую тем предметным областям, на которые ориентирован конкретный SAST. Поэтому, встретив в коде
request.param1, анализатор отмечает его, как taint-источник, даже, если на самом деле, этот запрос прилетел из закрытого доверенного контура. Та же история — с аргументами функций точек входа. Усредненная модель — усредненные результаты анализа 🤷♂️То же — с моделью доступа. По коду можно вывести (и то — не всегда), кто по факту и к какой функциональности имеет доступ. А кто и к какой должен его иметь и в рамках какой модели доступа? Снова фолзы.
То же — с моделью бизнес-логики. Какие сущности и их инварианты она подразумевает? Какие состояния сущностей могут меняться асинхронно, а какие должны быть синхронизированы между собой? Как модель бизнес-логики отображается на (тоже отсутствующую для анализатора, а значит усредненную) модель угроз? Здравствуйте, фолзы по Race Condition и всем логическим уязвимостям.
Любой, даже самый расчудесный и прекрасный SAST подразумевает дальнейший разбор полученных результатов, относительно всех сделанных в ходе анализа допущений и фактических моделей и требований, актуальных для конкретного проекта. «A» в SAST — это «Application», а не «Automated». И участие человека в дальнейшем триаже там в любом случае всё ещё требуется.
Ну, или не человека.
Но это, как говорит Каневский: уже совсем другая история.
#SAST