Уроки 200 сесій тріажу SAST: Що насправді знаходять інструменти безпеки

Вступ: Досвід тріажу SAST

Протягом останнього десятиліття автор провів близько 200 сесій тріажу результатів сканування SAST (Static Application Security Testing). Типовий сценарій полягає в тому, що після першого сканування інструмент SAST видає від 200 до 2000 знахідок. Перший тріаж займає багато часу, але з кожною наступною сесією починають виявлятися закономірності: ті самі п'ять правил, що генерують ті самі п'ять категорій знахідок, однакові форми хибних спрацьовувань та невелика кількість реальних проблем.

Правило 95 відсотків: Шум проти сигналу

Ключове спостереження полягає в тому, що близько 95% знахідок, виявлених під час сканувань, з якими працював автор, належать до однієї з трьох категорій:

1. Хибні спрацьовування: Повторювані по всій кодовій базі, спричинені патернами фреймворків або бібліотек, які сканер не розуміє.
2. Низька операційна важливість: Реальні знахідки низької операційної важливості, зазвичай у коді, недоступному із зовнішнього трафіку або такому, що не обробляє чутливі дані.
3. Тестовий код: Реальні знахідки середньої важливості в тестовому коді, зразках коду або прикладних конфігураціях, які не є частиною продакшн-розгортання.

Решта 5% — це ті знахідки, де зосереджена справжня робота з безпеки: високоважливі, зовнішньо доступні, пов'язані з обробкою чутливих даних проблеми, які дійсно потребують виправлення перед наступним релізом.

Помилкові спрацьовування, що забирають час

Найбільше часу забирають хибні спрацьовування, пов'язані з нерозумінням сканером патернів фреймворків. Наприклад, сканер може не розуміти обгортку DAO, яка коректно виконує прив'язку параметрів, і позначати кожен виклик бази даних як SQL-ін'єкцію. Аналогічно, він може не бачити, що фільтр автентифікації вже очистив дані перед тим, як вони досягнуть контролера, або що рушій шаблонів кодує вивід перед відображенням у браузері.

Це не є багами сканера, а скоріше неминучим результатом того, що сканер не має повної моделі кодової бази. Статичний аналіз є наближенням, і це наближення має прогалини. Вирішенням є створення кастомних правил (правил пригнічення), які вказують сканеру, що певний метод виконує санітизацію. Це може зайняти півдня, але усуває сотні знахідок і значно покращує якість наступних сканувань. Команди, які ігнорують це, ризикують тим, що їхня програма безпеки з часом занепаде через низьке співвідношення сигналу до шуму.

Налаштування, що приносить найбільшу користь: Каденція

Найбільш ефективним налаштуванням, що принесло значну користь, виявилася зміна каденції та обсягу сканування. Замість періодичного сканування всієї кодової бази, що генерувало величезні звіти здебільшого застарілого коду, було впроваджено сканування на етапі pull request. Це дозволило звітувати лише про зміни, внесені в поточному запиті, і блокувати нові знахідки. Такий підхід перетворив нечитабельні звіти на дієві, оскільки розробники бачили лише кілька знахідок у своєму свіжому коді, а не сотні в історичній кодовій базі.

Реальні, але неважливі знахідки

Багато команд не мають способу висловити, що «ця знахідка реальна, але неважлива». Інструменти надають рівень важливості, але не операційний контекст. Наприклад, SQL-ін'єкція в тестовому скрипті, що запускається в dev-середовищі з синтетичними даними, є реальною, але неважливою. Аналогічно, хардкодна таємниця в юніт-тесті або обхід шляху в адміністративному інструменті, що використовується лише розробниками, є реальними, але не становлять операційного ризику.

Команди, які не розробляють словник для таких випадків, або виправляють усе (що дорого і повільно), або ігнорують усе. Функціональним рішенням є прийняття ризику з документованими компенсуючими контролями. Знахідка визнається, причина невиправлення фіксується, а компенсуючий контроль (наприклад, тестовий код, ізольоване середовище) документується.

5 відсотків, які дійсно мають значення

Критичні знахідки, які дійсно вимагали блокування релізу, зазвичай концентрувалися в невеликій кількості файлів і патернів. До них належать:

• Прогалини в авторизації: Методи контролера, які не перевіряють доступ користувача до ресурсу.
• Прямі посилання на об'єкти: Часто в парі з прогалинами в авторизації, дозволяють доступ до будь-якого ресурсу шляхом перебору ID.
• Криптографічні помилки: Хардкодні ключі, слабке хешування паролів, неправильні генератори випадкових чисел.
• Вразливості ін'єкцій: SQL-ін'єкції, ін'єкції команд, LDAP-ін'єкції.
• Розкриття інформації в обробниках помилок: Повернення трасування стека або параметрів запиту у відповідях 500.

Автор також згадує випадок, коли рядок підключення до продакшн-бази даних, включно з обліковими даними, був знайдений у файлі application.properties. Ця знахідка була пропущена всіма скануваннями протягом років, оскільки конфігурація сканера за замовчуванням виключала файли властивостей, вважаючи їх «конфігурацією, а не кодом». Це підкреслює важливість розуміння того, що саме сканер не перевіряє.

Що сканери не виявляють

SAST-сканери мають суттєві обмеження і не виявляють:

• Логічні помилки бізнесу: Наприклад, дисконтний код, який можна застосувати кілька разів, ескалація привілеїв через послідовність легітимних викликів API, стан гонки в процесі замовлення, слабкості в механізмі скидання пароля.
• Архітектурні недоліки: Мікросервіс, який мав би автентифікуватися, але не робить цього, або потік даних, що розкриває PHI (Protected Health Information) системі логування, не призначеній для її зберігання.
• Проблеми, що залежать від контексту: Наприклад, SSRF (Server-Side Request Forgery), експлуатований лише в певному хмарному середовищі, XXE (XML External Entity), що спрацьовує лише за певного формату запиту, або вразливість десеріалізації, що залежить від класів у classpath під час виконання.

Яскравим прикладом є випадок, коли продукт, що чисто працював у США, готувався до запуску в Європі. Перевірка відповідності перед запуском виявила, що поля, які логувалися і були нечутливими за американськими правилами, ставали регульованими даними за європейськими. Сканер не мав поняття про юрисдикцію, і дефект не існував на рівні, який статичний аналіз міг би побачити.

Найкорисніше налаштування

Якщо вибирати одне налаштування, що принесло найбільшу цінність, то це каденція та обсяг: сканування на pull request, лише дельта змін, з блокуванням нових знахідок. Це дозволило зупинити генерацію шуму як єдиної величезної партії, заощадивши кумулятивний час тріажу більше, ніж усі написані правила пригнічення разом узяті.

Поради собі десятирічної давнини

Автор сформулював кілька ключових порад, які він би дав собі на початку кар'єри:

• Більше часу на налаштування, менше на окремі знахідки: Спочатку категоризувати, потім налаштовувати, потім виправляти.
• Операційна важливість важливіша за технічну: CVSS не знає вашої програми. Переоцінюйте ризики відповідно до власного контексту.
• Більшість знахідок — шум: Навчіться швидко фільтрувати, щоб зосередитися на важливому.
• SAST — це база, не гарантія: Високоважливі знахідки, які сканер не бачить, є джерелом більшості реальних витоків.
• Процес важливіший за інструмент: Середньоякісний інструмент SAST з дисциплінованим тріажем дає кращі результати, ніж високоякісний інструмент з хаотичним тріажем.
• Завжди запитуйте, що сканер не бачив: Кожного разу, коли сканування повертається чистим, витратьте десять хвилин, щоб запитати, що сканер не розглядав, не міг побачити або не було сказано, що це важливо.

Висновок

SAST є корисною частиною програми безпеки, але не самою програмою. 95% шуму є структурною властивістю статичного аналізу, а 5% сигналу є реальним і цінним. Завдання полягає в тому, щоб швидко розрізняти одне від іншого, щоб зосередитися на частині, яка має значення. Ця навичка розвивається з часом і вимагає судження, а не лише інструментів.

Що це означає для розробників

Розробникам слід розуміти, що інструменти SAST генерують багато шуму, і ефективність їх використання залежить від ретельного налаштування та інтеграції в робочий процес (наприклад, сканування на pull request). Важливо розрізняти технічну та операційну важливість знахідок, зосереджуючись на 5% дійсно критичних проблем, а також усвідомлювати обмеження SAST щодо виявлення логічних та архітектурних недоліків.

Ключові факти

• Автор провів близько 200 сесій тріажу SAST за десятиліття, виявивши типові патерни.

• Приблизно 95% знахідок SAST є хибними спрацьовуваннями, низьковажливими або знаходяться в тестовому коді.

• Лише 5% знахідок SAST є високоважливими, зовнішньо доступними проблемами, що стосуються чутливих даних.

• Основні хибні спрацьовування спричинені нерозумінням сканером патернів фреймворків; їх можна усунути за допомогою кастомних правил.

• Найбільш ефективне налаштування SAST — це зміна каденції сканування на pull request, звітування лише про нові зміни та блокування нових знахідок.

Джерела

• What 200 SAST Triage Sessions Taught Me About Application Security