Побудова комплексної стратегії тестування безпеки додатків не зводиться до простого додавання нових інструментів. Організації впроваджують SAST, SCA і DAST, розраховуючи отримати ширше покриття та краще контролювати ризики, але найбільшу цінність ці підходи дають тоді, коли кожен із них використовується на відповідному етапі життєвого циклу розробки.
Поєднання SAST, SCA і DAST дозволяє охопити ризики у вихідному коді, сторонніх залежностях і працюючих додатках. Ключове значення має не кількість інструментів, а те, наскільки доречно кожен із них використовується на своєму етапі.
Що таке багаторівнева стратегія тестування AppSec?
Багаторівнева AppSec-стратегія поєднує кілька підходів до тестування, щоб охопити різні етапи життєвого циклу розробки програмного забезпечення та різні категорії вразливостей.
Кожен інструмент працює з певним типом ризику на конкретному етапі пайплайну. Замість того щоб очікувати від одного сканера виявлення всіх можливих проблем, багаторівнева стратегія використовує кожен метод там, де він приносить найбільшу користь.
Чому багаторівневий підхід важливий
Жоден окремий метод не може виявити всі вразливості. Кожен тип тестування охоплює окрему частину ризиків безпеки додатків:
- SAST виявляє проблеми у вихідному коді;
- SCA виявляє ризики у сторонніх залежностях;
- DAST виявляє вразливості у працюючих додатках.
Разом ці підходи забезпечують ширше покриття. SAST допомагає знаходити проблеми ще під час розробки, SCA дає видимість ризиків у залежностях, а DAST показує, як додаток поводиться під час виконання.
Такий підхід дозволяє перевіряти безпеку протягом усього життєвого циклу розробки, а не покладатися на одну перевірку на окремому етапі.
Що робить кожен рівень: DAST, SAST і SCA
DAST, SAST і SCA відповідають на різні питання безпеки. Розуміння ролі кожного підходу допомагає побудувати стратегію тестування, яка охоплює код, залежності та поведінку додатка під час виконання.
SAST: статичне тестування безпеки додатків
SAST аналізує вихідний код до запуску додатка. Такий підхід допомагає розробникам знаходити небезпечні шаблони коду на ранніх етапах життєвого циклу розробки.
Що робить SAST
SAST аналізує вихідний код і виявляє вразливості ще під час розробки.
Серед них:
- небезпечні шаблони коду;
- ризики ін’єкцій;
- окремі логічні помилки та недоліки реалізації на рівні коду.
Оскільки SAST працює безпосередньо з вихідним кодом, проблеми можна виявити ще до розгортання додатка. Це дає розробникам можливість отримати зворотний зв’язок на ранньому етапі та виправити частину проблем ще під час роботи з кодом.
Коли використовується SAST
SAST зазвичай застосовується на ранніх етапах життєвого циклу розробки:
- під час комітів коду;
- у середовищах розробників;
- у CI-пайплайнах під час pull request.
Ранній запуск SAST дозволяє швидше отримувати інформацію про проблеми ще під час роботи з кодом. Це зменшує обсяг повторної роботи та допомагає не допустити переходу частини вразливостей на наступні етапи.
Переваги
SAST дозволяє змістити перевірки безпеки ближче до початку процесу розробки.
Основні переваги:
- раннє виявлення вразливостей;
- швидкий зворотний зв’язок для розробників;
- інтеграція у звичні процеси розробки.
Завдяки цьому SAST допомагає знаходити багато проблем на рівні коду ще до того, як вони потраплять у наступні етапи тестування.
Обмеження
SAST не аналізує додаток під час його виконання, тому має певні обмеження:
- не враховує контекст середовища виконання;
- може генерувати більше хибнопозитивних спрацювань;
- не може підтвердити можливість експлуатації вразливості.
Через це результати SAST часто потребують додаткового аналізу, щоб визначити, наскільки конкретна проблема впливає на додаток на практиці.
SCA: аналіз програмних компонентів
SCA зосереджується на сторонніх залежностях і компонентах з відкритим кодом. Оскільки сучасні додатки значною мірою залежать від зовнішніх бібліотек, SCA допомагає оцінювати ризики, які потрапляють у проєкт разом із такими компонентами.
Що робить SCA
SCA виявляє проблеми у сторонніх залежностях і бібліотеках з відкритим кодом.
Зокрема, відстежуються:
- компоненти з відомими вразливостями;
- застарілі залежності;
- ліцензійні ризики.
Це допомагає зрозуміти, чи створюють використовувані компоненти відомі ризики безпеки або проблеми з дотриманням ліцензійних вимог.
Коли використовується SCA
SCA зазвичай інтегрується у процеси збірки та керування залежностями:
- під час збірки;
- під час оновлення залежностей.
Перевірка на цих етапах допомагає виявляти ризики до переходу компонентів на наступні стадії пайплайну. SCA також може повідомляти про нові вразливості, якщо вони були виявлені у компоненті, який уже використовується в додатку.
Переваги
SCA забезпечує видимість одного з основних джерел ризику для сучасних додатків.
Основні переваги:
- видимість ризиків сторонніх компонентів;
- автоматизоване відстеження відомих вразливостей.
Без SCA команди можуть не мати достатнього уявлення про вразливості, які потрапляють у додаток через бібліотеки, пакети та фреймворки.
Обмеження
Результати SCA також потребують контексту для оцінки фактичного ризику:
- не дозволяють визначити можливість експлуатації;
- можуть містити велику кількість знахідок;
- не враховують повний контекст фактичного використання компонента в додатку.
Вразливий пакет може бути присутнім у проєкті, але його проблемна функціональність може не використовуватися або бути недоступною. Через це не всі знайдені проблеми мають однаковий рівень ризику.
DAST: динамічне тестування безпеки додатків
DAST тестує додаток під час його роботи. Такий підхід допомагає зрозуміти, як додаток поводиться під час виконання, і виявляти проблеми, які не завжди можна побачити під час аналізу коду або залежностей.
Що робить DAST
DAST тестує працюючі додатки, імітуючи реальні сценарії атак.
Серед вразливостей, які може виявляти DAST:
- ін’єкції;
- слабкі місця автентифікації;
- неправильні конфігурації середовища виконання.
Оскільки DAST аналізує працюючий додаток, він може виявляти проблеми, які проявляються лише під час виконання.
Коли використовується DAST
DAST зазвичай застосовується на пізніших етапах життєвого циклу розробки та у працюючих середовищах:
- staging-середовища;
- передпродакшн тестування;
- безперервний моніторинг production-середовищ, де це доречно.
Такі перевірки дозволяють оцінювати додаток в умовах, наближених до реального використання. У production-середовищах безперервний DAST-моніторинг може застосовуватися там, де це безпечно, для виявлення проблем, які з’являються після релізу.
Переваги
DAST забезпечує контекст середовища виконання, якого немає в інших підходів.
Основні переваги:
- виявлення вразливостей під час виконання;
- перевірка поведінки працюючого додатка;
- практичні результати для подальшого виправлення.
Завдяки цьому DAST доповнює SAST і SCA, перевіряючи додаток уже після його розгортання.
Як DAST, SAST і SCA мають працювати разом?
DAST, SAST і SCA найкраще працюють тоді, коли кожен інструмент має чітко визначену роль. Мета полягає не в тому, щоб запускати більше сканувань, а в побудові узгодженої стратегії тестування, яка забезпечує ширше покриття на різних етапах життєвого циклу.
Кожен інструмент відповідає на окреме питання:
- SAST: чи безпечний код?
- SCA: чи безпечні залежності?
- DAST: чи є вразливості у працюючому додатку?
Така модель дозволяє перевіряти безпеку протягом усього життєвого циклу розробки.
Покрокова інтеграція в пайплайн
Добре побудований пайплайн використовує кожен підхід на відповідному етапі:
- коміт коду запускає SAST-сканування;
- етап збірки запускає SCA-сканування;
- розгортання у staging запускає DAST-сканування;
- production-середовища використовують безперервний DAST-моніторинг.
Такий підхід допомагає виявляти проблеми на ранніх етапах і перевіряти додаток до та після релізу. Крім того, кожен метод тестування запускається саме там, де він природно вписується в життєвий цикл розробки.
