Статичне тестування безпеки додатків (SAST) – це ефективна та добре зарекомендована технологія перевірки безпеки програмного забезпечення. Вона дозволяє розробникам створювати якісний і захищений софт, стійкий до тих видів атак, які стали особливо поширеними в останні роки.
Однак головна проблема SAST полягає в тому, що цей метод схильний видавати велику кількість хибнопозитивних спрацювань, які марно витрачають час інженерної команди.
У цій статті розглядається SAST та проблема хибнопозитивних спрацювань, а також як їх уникати та чим тут може допомогти Mend SAST.
Що таке SAST?
SAST – це методологія тестування додатків, яка оцінює вихідний код для виявлення потенційних недоліків у архітектурі, використовуючи статичний аналіз програм для пошуку вразливостей. У SAST додаток сканується без необхідності виконання його коду. Його також називають white box тестуванням. SAST працює пліч-о-пліч з іншими практиками безпечного кодування, такими як аналіз вихідного коду та інструменти його перевірки, забезпечуючи розробникам кілька рівнів захисту при виявленні вразливостей.
SAST є одним із кількох підходів, що використовуються в тестуванні безпеки додатків (AST). Іншими основними підходами є динамічне тестування безпеки (DAST), інтерактивне тестування безпеки (IAST) та аналіз складу програмного забезпечення (SCA).
В ідеалі SAST проводиться на ранніх стадіях життєвого циклу розробки програмного забезпечення (SDLC). Зміщуючи безпеку ліворуч (принцип «shift left»), розробники отримують можливість швидко виправляти проблеми, не ламаючи збірки й не пропускаючи дефекти на пізніші стадії розробки, де усунення помилок коштує значно дорожче.
Однією з переваг SAST порівняно з DAST або IAST є те, що SAST виявляє недоліки у 100% кодової бази. Наприклад, використання ненадійного шифрування – це те, що інструмент DAST або IAST виявити не зможе, але це легко помітить інструмент SAST.
Проблема хибнопозитивних спрацьовувань SAST
Попри безліч переваг, інструменти SAST зажили поганої слави через генерацію величезної кількості попереджень про хибнопозитивні спрацьовування – потенційних дефектів коду, яких насправді не існує, якщо перевірити детальніше. Щоб продемонструвати це, ось два типових приклади проблем, що виникають за таких обставин.
По-перше, специфічні для конкретного проєкту операції для очистки даних.
Це заходи, які виконуються з метою захисту від вразливості. Ось приклад таких операцій для захисту від SQL-ін’єкцій:
final var allowedColumns = List.of(“col1”, “col2”, “col3”);
if(allowedColumns.contains(userInput)){
stmt.executeQuery(“SELECT ” + userInput + ” FROM table”)
}У цьому прикладі userInput – це рядок, який надходить ззовні: так звані «недовірені» дані. Ці дані легко можуть контролюватися зловмисником і стати причиною SQL-ін’єкції.
Коли недовірені дані потрапляють у ділянку коду, де їхнє використання може призвести до шкоди, це місце вважають небезпечною точкою обробки таких даних (з англ. taint sink). У наведеному вище фрагменті коду метод executeQuery є небезпечною точкою обробки даних для SQL-ін’єкції. Якщо не вжити додаткових заходів захисту, кіберзлочинці можуть атакувати базу даних, додавши шкідливий рядок через userInput, і використати його для вчинення зловмисних дій, таких як видалення всіх користувачів, отримання прав адміністратора тощо.
Загалом інструменти SAST перевіряють, чи існує шлях до недовіреної точки обробки даних (taint flow), і якщо він є, то фіксують вразливість. Розуміння цієї механіки також допомагає при порівнянні SAST та SCA, оскільки SAST аналізує безпосередньо кастомний код, тоді як SCA фокусується на сторонніх та open-source компонентах. Однак, якщо в цьому потоці вжито певних заходів, завдяки яким до недовіреної точки обробки можуть дійти лише безпечні значення, то вразливості немає. Ці заходи називаються операціями для очистки даних, оскільки після них до недовіреної точки обробки потрапляє лише ввід, безпечний для такого використання. Таким чином, зловмисник ніяк не зможе викликати зі шкідливим рядком.
Зазвичай операцією для очистки даних може виступати або якась стандартна функція бібліотеки (яку інструмент розпізнає автоматично, якщо вендор знає про цю бібліотеку і заздалегідь прописав відповідне правило), або щось «домашнє», специфічне для проєкту. У цьому випадку allowedColumns.contains(userInput) і є такою спеціалізованою операцією. Вона перевіряє, чи є userInput одним із дозволених рядків.
Загалом, найкращий спосіб запобігти SQL-ін’єкції – використовувати параметризовані запити. Тут вони не використовуються, тому інструменти статичного аналізу повідомлять про вразливість. Але насправді це хибнопозитивне спрацьовування, оскільки в цьому випадку застосовується специфічна для проєкту операція для очистки даних через вайтлістинг вводу (перевірку того, що передано лише один із очікуваних рядків). Про це жоден інструмент статичного аналізу не може знати заздалегідь.
Другий приклад – це контекстозалежна вразливість.
Рішення безпеки просто не може передбачити, чи є програма достатньо чутливою, щоб вимагати автентифікації та авторизації. Тому багато інструментів звітують про будь-який тип неавтентифікованого доступу, створюючи хибнопозитивні сповіщення для абсолютно нешкідливого софту. Наприклад, неавтентифікований доступ до сервісу, який просто показує поточний час, навряд чи є реальною вразливістю.
Наслідки хибнопозитивних спрацьовувань SAST
Щоб розібратися, що таке хибнопозитивне спрацьовування, важливо розуміти весь спектр результатів тестування, які може видати SAST-інструмент:
- Істинно негативний (True Negative) – правильно показує, що вразливості немає.
- Істинно позитивний (True Positive) – правильно показує, що вразливість є.
- Хибнонегативний (False Negative) – не показує вразливість, хоча насправді вона існує.
- Хибнопозитивний (False Positive) – помилково показує, що вразливість є, хоча насправді її немає.
Метою будь-якого інструменту AST має бути максимізація істинно негативних та істинно позитивних результатів при мінімізації хибнонегативних та хибнопозитивних. Проте з інженерної точки зору цього важко досягти. На практиці більшість продуктів SAST були розроблені так, щоб максимізувати кількість істинно позитивних результатів, навіть ціною створення великої кількості хибнопозитивних спрацьовувань. Це призводить до колосальних втрат часу, оскільки розробники вимушені шукати баги, яких насправді немає, що породжує наступні проблеми.
Основні причини хибнопозитивних спрацьовувань
Існують дві головні причини помилкових сповіщень під час SAST-тестів:
#1 Надмірні припущення у сканерах
Деякі інструменти SAST заклали у свій алгоритм занадто багато припущень, щоб забезпечити підтримку багатьох мов програмування. У більшості випадків ці припущення є загальними і не можуть коректно застосовуватися до всіх мов. Якщо якийсь шматок коду незрозумілий такому інструменту або відсутня залежність, він просто припускає, що в коді є проблема. Як результат – купа хибнопозитивних сповіщень.
#2 Погано спроєктовані правила
Деякі традиційні інструменти SAST розроблені неефективно і не можуть з упевненістю підтвердити вразливість. Щоб компенсувати це, вони маркують код як вразливий за найменшого натяку на проблему – просто про всяк випадок. Наприклад, вони шукають певні слова у назвах рядкових змінних, щоб визначити, чи містять вони чутливі дані (облікові дані автентифікації, паролі, ключі тощо).
Приклад такого коду:
userPasswordLabel.Text = “Please enter your password”;Хоча назва змінної містить слово «password», це зовсім не означає, що вона зберігає секретні дані. Це просто текстова мітка. Якщо інструмент SAST не може провести глибший аналіз, щоб визначити, чи змінна розкриває чутливу інформацію, він миттєво створить хибнопозитивне сповіщення.
Як уникати хибнопозитивних спрацьовувань SAST
Ось кілька способів приборкати хибнопозитивні спрацьовування та не дати їм зламати стратегію раннього тестування безпеки організації:
#1 Обрати якісний інструмент
Варто обрати рішення, яке заточене під конкретні завдання. Якщо взяти перший ліпший інструмент без оцінки його ефективності, можна провести купу часу за розбором хибнопозитивних сповіщень замість усунення реальних загроз.
Потрібен інструмент, який робить глибокий, точний та комплексний аналіз потрібною мовою програмування та покриває широкий спектр вразливостей. Універсальний інструмент, не оптимізований під обрану мову, може без вагомих причин видавати багато спрацьовувань.
Крім того, потрібно обирати інструмент, який може безперешкодно інтегруватися у поточне DevOps-середовище та CI/CD-пайплайн. Це позбавить необхідності окремо налаштовувати або запускати сканування, що могло б збільшити кількість зайвого шуму в результатах SAST.
#2 Практикувати кастомізацію
Застосування індивідуального набору правил до інструменту SAST допоможе знизити кількість хибнопозитивних спрацьовувань. Використання стандартних налаштувань інструменту може не відповідати конкретним потребам організації.
Якщо налаштувати інструмент SAST відповідно до власних уподобань, це допоможе виявляти саме ті проблеми, які цікавлять організацію, і мінімізувати кількість хибнопозитивних сповіщень. Впровадження інструменту без попереднього налаштування може згенерувати купу інформаційного сміття, через яке є ризик пропустити реальні загрози, що шкодять програмному забезпеченню.
#3 Фільтрувати та пріоритезувати
Також є можливість відфільтровувати результати, які не мають істотного значення для життєздатності софту. Наприклад, можна ігнорувати сповіщення з тих частин програми, які містять «мертвий код», або з пакетів, які взагалі не викликаються.
Це допоможе розставити пріоритети в результатах тестування на основі того, що є найважливішим для компанії. Таким чином з’явиться можливість визначити першочерговість їх виправлення за рівнем серйозності загроз, статусом вразливостей та можливістю усунення. Це дозволить зосередитися на найкритичніших аномаліях замість того, щоб витрачати зусилля на розбір проблем, які майже або взагалі ні на що не впливають.
Чим допомагає Mend SAST
Mend SAST дозволяє розробникам створювати додатки швидко без компромісів із безпекою. З ним можливо ефективно скоротити ризики та зменшити операційні навантаження, які зазвичай виникають через лавину сповіщень. Mend SAST має революційний двигун сканування, який видає результати у 10 разів швидше за традиційні рішення, тож розробникам не доведеться чекати.
Він інтегрується у поточне DevOps-середовище та CI/CD-пайплайни, тож не потрібно окремо налаштовувати або запускати сканування. Крім того, він є комплексним і підтримує понад 30 різних мов програмування, а також безліч різноманітних фреймворків і платформ. Це гарантує видимість понад 70 типів CWE (зокрема OWASP Top 10 та SANS 25) у десктопних, веб- та мобільних додатках, забезпечуючи глибокий аналіз широкого спектра вразливостей.
Mend SAST забезпечує максимальну ефективність та зручність для розробників, дозволяючи їм виявляти та усувати вразливості одразу ж – тоді, коли це зробити найшвидше та найпростіше. Вбудовані звіти для таких стандартів безпеки, як PCI та HIPAA, дозволяють легко виконувати вимоги щодо комплаєнсу. Ефективність та ергономічність Mend SAST допоможуть розробникам програмного забезпечення навчитися довіряти своїм робочим інструментам та охочіше співпрацювати з членами команди безпеки.
