Як ми реалізували безпеку коду на Prom.ua. Досвід інтеграції SAST/DAST у процес розробки

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Всім привіт! Я працюю в українській продуктовій компанії EVO на посаді Penetration Test Engineer. Одним із головних очікувань від мене як спеціаліста було завдання з реалізації SAST/DAST як частини SDLS на проєкті, що своєю чергою мало сприяти підвищенню безпеки коду.

Тож заручившись цими цілями, я реалізував доволі ефективний процес перевірки безпеки за допомогою сканування коду (SAST/DAST) для проєкту Prom.ua, описом якого і хочу поділитись.

Вступ

Нещодавно я проводив верифікацію знахідок в результаті SAST/DAST-тестування і пригадав, як я налаштовував цей процес, який він мав вигляд спочатку, і у що трансформувався сьогодні.

Спочатку знайти якусь конкретну інформацію для цього було досить складно, здебільшого на ринку були готові продукти, які являли собою пропрієтарне програмне забезпечення із платними підписками. Але мене зацікавила можливість застосувати рішення з відкритим кодом (open source).

Тому хочу поділитись власним досвідом із надією, що це стане в пригоді комусь ще, а також отримати відгук куди можна рухатись далі для покращення ефективності.

Гадаю, стаття буде корисна спеціалістам, які залучені до моніторингу безпеки, проводять тестування на проникнення або налаштовують процеси SDLC і можуть інтегрувати у них SAST/DAST.

І так, спочатку я вивчав, які взагалі інструменти SAST/DAST можуть покрити мої вимоги, а саме:

— ефективний пошук вразливостей;

— легку конфігурацію;

— гнучке налаштування.

Серед багатьох розглянутих рішень для вебзастосунків найкраще підійшов Semgrep для SAST та OWASP ZAP для DAST. Для мобільних застосунків ми використали MobSF, а для перевірки docker-образів контейнерів розгорнули Trivy.

До речі, коротко про SAST/DAST для кращого розуміння.

SAST (Static Application Security Testing)

Що це: Методика тестування безпеки програмного забезпечення, яка аналізує вихідний код, байт-код або бінарний код програми без її виконання.

Як працює: SAST-інструменти сканують код для виявлення вразливостей, таких як SQL-ін’єкції, XSS, і неправильне керування пам’яттю, ще на етапі розробки й багато іншого з огляду на патерни інструменту.

Переваги: Може виявити проблеми на ранніх стадіях розробки, дозволяючи їх виправити до того, як програма буде запущена.

Приклад: Fortify, SonarQube, Checkmarx, Сodacy.

DAST (Dynamic Application Security Testing)

Що це: Методика тестування безпеки, яка аналізує програму під час її виконання, взаємодіючи з нею як користувач або автоматизований інженер із тестування.

Як працює: DAST інструменти імітують атаки на запущену програму, щоб виявити вразливості, такі як SQL-ін’єкції, XSS, та інші проблеми безпеки, які проявляються під час виконання.

Переваги: Може виявити вразливості, які виникають лише під час виконання програми, включаючи проблеми з конфігурацією середовища.

Приклад: OWASP ZAP, Burp Suite, Acunetix, Invicti, Сodacy.

Ключові відмінності

Стадія застосування: SAST використовується на етапі розробки, тоді як DAST застосовується до вже запущеної програми.

Підхід: SAST аналізує код, тоді як DAST аналізує поведінку програми під час її виконання.

Тип уразливостей: SAST виявляє вразливості в коді, DAST — вразливості, які проявляються в запущеній програмі.

Отже, першим етапом слід було продумати архітектуру того, як усе повинно працювати. Звісно, її перша версія була дуже спрощена, проте з кожною ітерацією з’являлись нові деталі й вона поступово ускладнювалась.

Поряд із основним налаштуванням CI/CD-проєкту був запущений образ з SAST/DAST-інструментами, який запускався за певним графіком, бо залежав багато в чому від конфігурацій основного репозиторію.

Бувало, сканування завершувалось з помилкою і його доналаштування потребувало додаткового часу.

Саме тоді було вирішено мігрувати в окремий Git-проєкт із повними описами README.md для усіх скриптів та конфігураційних файлів, в рамках якого буде відбуватись весь процес SAST/DAST.

Основна ідея полягала в тому, щоб процес налаштування конфігурації та підтримки був максимально простим та зрозумілим, а опис можна було легко підтримувати в актуальному стані. Також структура мала відповідати принципам об’єктноорієнтованого програмування.

Процедура тестування

Наразі процедура тестування побудована за наступною логікою:

• За певним графіком ранер (віртуальне середовище, яке працює для виконання завдань в середовищі CI/CD) завантажує до себе репозиторій, який варто просканувати.

Приклади конфігураційних файлів для аналізу та використання за потреби можна знайти тут (SAST).

• Ранер запускається із докер-образом від Semgrep для SAST і OWASP ZAP для DAST.
• За результатами сканування Semgrep формує звіти gitlab-sast > gl-sast-report.json.
• Додатковий скрипт на bash import_scan_result_searchService.sh відсилає ці звіти у DefectDojo.

Це інструмент з відкритим вихідним кодом для керування звітами про вразливості, який ми використовуємо, щоб допомогти командам розробників програмного забезпечення ідентифікувати, відстежувати та виправляти вразливості на ранній стадії розробки.

• Нові звіти, отримані у DefectDojo, надсилаються через корпоративний месенджер у командні чати у формі посилання на результати сканування в системі DefectDojo.

Приклад скрипту, який за це відповідає — SAST_Notification.py. А такий вигляд має сповіщення. Лого теж своє, ChatGTP допоміг :)

Крім цього, для зручності користувачів інформація про результати сканування також додається у повідомлення у .pdf-файлі (приклад, звіту report_pdf.py та скрипту, який надсилає вже готові файли upload_to_slack_pdf.py)

• Для відстежування зведеної інформації по всіх сервісах, які ми перевіряємо, дані про результати всіх скануваннь передаються у Google-таблицю.

У ній розраховується індекс безпеки коду відповідно до кількості зауважень та їх критичності, а також в розрізі періодів. Ось приклад скрипту для цього — report_analises.py.

Окрема подяка Святославу Логіну за допомогу з ідеєю розрахунку індексу та формулою для цього.

Процес валідації

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

На приклад, на картинці зі статистикою видно оцінку сервісів індексом С, проте у більшості випадків на цю оцінку впливали хибно позитивні результати, що було встановлено під час валідації розробниками. Після цього більша частина зауважень була виправлена.

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

Для сканування мобільних застосунків ми використовуємо MobSF, при чому як безпосередньо сервер MobSF, так і docker-образ для сканування коду (ось тут приклад скрипта для запуску download_and_analyze.py).

Коротко про Mobile Security Framework (MobSF). Це універсальний інструмент, який виконує автоматизоване тестування на проникнення, аналіз програмного забезпечення та оцінку безпеки мобільних застосунків на базі Android/iOS та здатний виконувати статичний і динамічний аналіз, тобто SAST/DAST.

Процес для мобільних застосунків дещо подібний. Готовий релізний мобільний застосунок перед його розгортанням у робочому середовищі (production) відсилається для перевірки на сервер MobSF, розгорнутий у нашому тестовому середовищі. Після успішного завершення сканування звіт від MobSF також надсилається через корпоративний месенджер у командні чати розробників для подальшого аналізу та прийняття рішень.

Запуск пайплайну, у якому сканується застосунок, реалізований через тригер у пайплайні, який збирає мобільний застосунок. Таким чином, окрім стабільного графіка сканування ми також проводимо сканування перед релізом (приклад конфігураційного файлу для запуску — gitlab-ci-mobsf.yml).

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

На цьому, думаю, усе. Якщо матимете питання щодо реалізації, зажди радий допомогти. Також вітаються думки щодо покращення та розвитку описаної архітектури та її логіки.

Дякую Віталію Луговцю та Святославу Логіну за аналіз та доповнення статті перед її релізом.