Статичне тестування безпеки додатків (SAST) має не найкращу репутацію. Інструменти SAST можуть видавати величезну кількість сповіщень, а команди безпеки, які часто мають досвід роботи з мережею, не завжди повністю розуміють їх. Це може призвести до погіршення відносин між командами, оскільки розробники часто сприймають цю роботу як таку, що відвертає увагу від роботи над своїми основними обов’язками.
У цьому блозі надано кілька простих порад, що працюють для покращення стану безпеки, зберігаючи при цьому гарні стосунки між службою безпеки та розробниками.
Як працює SAST?
SAST працює на основі правил кодування, щоб знайти загальні недоліки та слабкі місця, які можуть призвести до вразливостей. Ці недоліки зазвичай визначаються за допомогою фреймворку Common Weakness Enumeration (CWE). Самі по собі недоліки не є вразливостями, але вони свідчать про низьку якість коду. SAST можна уявити як перевірку орфографії або граматики, яка виявляє місця, де код написаний неякісно. Ключове тут те, що недолік може бути, а може і не бути чимось, що коли-небудь стане проблемою, і єдиний спосіб дізнатися це – дослідити його. Хоча інструменти SAST створені для виявлення вразливостей, які призводять до проблем з безпекою, вони, як правило, також можуть певною мірою розв’язувати проблеми якості коду, які не стосуються безпеки.
Надійні стратегії реагування на SAST-сповіщення без перевантаження розробників
Навіть найкращі з наявних інструментів SAST створюють багато сповіщень. Реакція на попередження SAST, має містити розгляд того, як це виконуватиметься в співпраці з іншими відділами. Якщо безсистемно видавати попередження на основі сповіщень від інструментів безпеки, довіра розробників та співпраця з ними швидко втратиться. Не всі сповіщення однакові, і не всі є вразливостями.
Ось дві стратегії реагування на SAST-сповіщення:
Припинення реагування
За такого підходу отримується базовий рівень SAST-сповіщень на самому початку, але відсутнє реагування на ці сповіщення. Натомість мета – не додавати нових вразливостей або проблем з якістю коду. Розробники будуть працювати лише з новими сповіщеннями. Потім, згодом, буде можливість скоротити свій беклог, використовуючи, наприклад, другу стратегію.
Поступова перевірка
При такому підході береться один тип CWE (SQL-ін’єкції, XSS і десеріалізація ненадійних даних – найпоширеніші) і вирішуються всі безпекові попередження, пов’язані з ними. Коли з ними буде завершено, переходять до наступного типу CWE, працюючи з найбільш критичними типами CWE в першу чергу. В цій стратегії важливо переконатися, що розробники знають план заздалегідь.
Вибір хорошого інструменту SAST
Пошук інструменту, який зменшує кількість сповіщень і водночас підвищує їх якість, дуже допоможе. Потрібно шукати інструмент, який робить наступне:
- Може бути налаштований відповідно до персональних потреб
Хороший інструмент SAST можна налаштувати відповідно до кастомних проєктів, щоб в результаті отримувати якісніші сповіщення.
- Має консолідацію потоків даних
Багато SAST-інструментів створюють сповіщення для кожного потоку даних, навіть якщо це означає сотні сповіщень, згенерованих лише для кількох фрагментів коду, які потребують вирішення. Наявність великої кількості сповіщень може бути корисною, коли обґрунтовується необхідність збільшення ресурсів для команди безпеки, але ця перевага швидко зменшується, коли розробникам доводиться реагувати на них.
- Заохочує навчання розробників
Деякі інструменти SAST інтегровані з освітніми програмами для розробників, такими як, наприклад, Secure Code Warrior. Жоден інструмент чи налаштування не зменшить кількість сповіщень так, як розробники, що пишуть безпечний та якісний код.
- Маскує якісні сповіщення
І остання порада: звертати увагу на контекст програми. SAST не володіє знаннями про середовище виконання або розгортання, тому потрібно самостійно вирішувати, чи є сповіщення справжньою вразливістю. Іноді те, що може здатися низькоякісним сповіщенням, може мати величезні наслідки в майбутньому. Наприклад, обхід шляху CWE в інструменті командного рядка може не бути справжньою вразливістю, але це все одно проблема якості коду. А якщо цей командний рядок коли-небудь буде розгорнутий як частина хмарного додатка, то він стане справжньою потенційною вразливістю безпеки.
Метою будь-якого інструменту безпеки додатків має бути поліпшення безпеки додатка. Надто велика кількість незначних сповіщень матиме негативний вплив у довгостроковій перспективі, оскільки розробники почнуть ігнорувати команду безпеки та можуть нехтувати безпечним кодуванням.
