Pull to refresh

Comments 5

Хочу уточнить, что всё-таки понимаете под термином «уязвимость»? Подробнее этот вопрос я задал здесь. Буду благодарен, если будут приведен какие-то примеры кода с уязвимостями разного уровня критичности. Я не понимаю, как анализатор решает, какая уязвимость критична, а какая нет. И я рискну предположить, что на самом деле речь идёт не об уязвимостях, а о потенциальных уязвимостях (software weaknesses).
Речь об уязвимостях, которые обнаруживает статический анализатор. Безусловно, любой статический анализатор может давать ложные срабатывания (если он пытается находить интересные уязвимости). В этом смысле мы говорим про «потенциальные уязвимости». Разные анализаторы соревнуются по количеству ложных срабатываний и настоящих нахождений.

CVE — это все-таки база конкретных уязвимостей в конкретных системах и версиях, а тут мы анализируем переданный код. Можно обнаруживать, что в проекте используется уязвимая версия библиотеки, но это немного другой класс средств (SCA — software composition analysis). Критичность в анализаторах определяется экспертно в алгоритмической базе и в базе правил. Например, если алгоритм уверен в уязвимости, и это SQL-инъекция — будет критическое срабатывание. Если это плохая обработка ошибок — низкий уровень.
В этом смысле мы говорим про «потенциальные уязвимости».
Спасибо.
Откровенно говоря, не верю, что оно обнаружит «спящий» бекдор без исходных кодов.
В этом и есть ноу-хау продукта, что при отсутствии исходных кодов также проводится статический анализ, не динамический. Конечно, если бекдор заключается в мертвом коде, который удален при компиляции — не найдет. Но если речь идет о, например, триггере по времени, то бекдор вполне может быть найден с помощью реверс инжениринга. Скоро выйдет наша статья на эту тему здесь в блоге.
Sign up to leave a comment.