Більшість команд дізнаються про вразливість одним із двох способів: або від тестувальників після релізу, або коли зловмисники вже знайшли забуті ключі в коді чи експлуатували вразливість у хмарі. SharksCode, українська IT-компанія, що створює високотехнологічні програмні рішення та платформи для B2B-ринку, обрала третій шлях – зробити так, щоб вразливість просто не мала шансів дожити до продакшну. Це питання архітектури процесу та інструментів, які цю архітектуру реалізують у кожному коміті й кожному деплої.
Компанія побудувала систему, в якій безпека перевіряється автоматично на кожному етапі розробки. Але зробила це так, щоб розробники цього майже не відчували. Тому тут немає зайвої бюрократії, нескінченних погоджень і сповіщень, які можна випадково пропустити.
Інструменти без процесу – це ілюзія захисту
У SharksCode не вірять у «срібну кулю» – універсальне рішення, що здатне розв’язати будь-які питання з безпекою. SAST, DAST, EDR, CSPM – жоден із цих інструментів не захистить продукт, якщо за ним немає процесу й архітектурної дисципліни. Погано налаштований security stack буває гіршим за його відсутність, адже команда вірить, що все гаразд, а критичні ризики тим часом нікуди не діваються.
Ще одна пастка – ізольоване впровадження окремих інструментів без єдиної моделі управління ризиками. Йдеться про окремий SAST, dependency scanner та cloud-аудит раз на квартал. Кожен із них щось знаходить, але не бачить повної картини. У результаті команда витрачає час на усунення локальних знахідок, проте не помічає системних проблем.
В SharksCode дотримуються чіткого принципу, коли процеси та архітектурні рішення визначають, що таке безпечно, а інструменти забезпечують масштабоване виконання цих вимог.
COO SharksCode Станіслав Андрєєв
«Із розгортанням процесу SSDLC ми одразу заклали можливість його автоматизації та масштабування», – коментує COO SharksCode Станіслав Андрєєв.
Shift Left. Безпека починається до написання коду
Ключовий принцип підходу SharksCode – Shift Left, коли перевірки безпеки зміщуються якомога раніше в циклі розробки: на етап написання коду або навіть проєктування.
Чим пізніше виявили вразливість, тим дорожче її виправити. Помилка, знайдена в IDE, виправляється за хвилини. Та сама помилка після релізу може коштувати тижнів роботи і репутаційних втрат. Вразливість, яку виявили вже після інциденту, виходить ще дорожчою. І справа не лише у грошах.
До практики Shift Left у SharksCode підштовхнув зокрема стандарт PCI DSS, який прямо вимагає інтегрувати перевірки безпеки у процес розробки.
Сьогодні карта безпеки SharksCode охоплює весь SDLC: планування та дизайн, написання коду в IDE, pre-commit, code review, CI-білд, pre-deploy gate і runtime у продакшні.
Кожен етап бачить лише свою частину ризиків. Pre-commit добре перехоплює hardcoded секрети, очевидні insecure patterns і проблеми з залежностями. Але він принципово не моніторить поведінку під час виконання, порушений контроль доступу, SSRF чи вразливості бізнес-логіки. Для цього потрібні SAST, DAST і CSPM на наступних рівнях. Якщо контроль є лише подекуди, між перевірками залишаються прогалини, через які цілі класи вразливостей непомітно просочуються далі.
CI/CD-пайплайн: що блокує, що сигналізує
Серце автоматизованої безпеки – CI/CD-пайплайн із кількома незалежними шарами перевірок. Архітектура розділяє два типи знахідок: критичні вразливості зупиняють білд, некритичні генерують асинхронні сповіщення. Незалежні перевірки виконуються паралельно, щоб безпека не ставала пляшковим горлом для команди розробки.
SAST (статичний аналіз коду) інтегрований прямо в IDE. Розробник отримує зворотний зв’язок ще під час написання коду, до того, як він потрапить навіть у pre-commit. Додатково, SAST запускається при кожному коміті та збірці. Це подвійний контроль на рівні розробника і на рівні пайплайну. Правила, за якими він працює, визначаються або верифікуються тимлідом команди та переглядаються щорічно, щоб відповідати актуальним загрозам і специфіці продукту.
DAST (динамічний аналіз) тестує вже запущений застосунок на Stage Environment – там, де всі компоненти інтегровані та працюють разом. Саме в такому контексті проявляються вразливості, невидимі при статичному аналізі. Йдеться про ін’єкції, проблеми з правами користувачів, некоректну обробку сесій та пошкодження пам’яті. Процес включає набір заздалегідь підготовлених атак і навмисно некоректно сформованих запитів. Жорстке правило без виключень: запуск DAST на Production Environment заборонений.
SCA (аналіз залежностей) сканує залежності на відомі CVE, аналізує transitive dependencies і перевіряє ліцензії – GPL, AGPL та інші – з можливими юридичними наслідками для комерційного продукту. Без SCA організація фактично не контролює, який сторонній код працює всередині її продукту. При виявленні небезпечного пакета система може автоматично створити PR з оновленням, що прибирає один із найбільших ручних процесів – відстеження та оновлення бібліотек. Рішення про конкретне оновлення приймається колегіально. Архітектори разом із командами розробки оцінюють ризики, але фінальне слово за CTO.
Для SAST, DAST і SCA в SharksCode використовується ox.security – платформа класу Application Security Posture Management (ASPM). Вона не замінює окремі security tools, а збирає сигнали з усього pipeline в єдину risk-oriented модель. Один центр видимості замість десятка розрізнених дашбордів.
Окремі шари пайплайну відповідають за:
- secret scanning: ключі та токени, випадково закомічені у код – надзвичайно поширена проблема, яку розробники часто не помічають самостійно;
- IaC scanning для перевірки Terraform, Docker та Helm-конфігів на небезпечні налаштування;
- container scanning перед деплоєм.
Для покриття інфраструктури використовується Tenable Vulnerability Management. Це система автоматизованого сканування серверів, мережевого обладнання та хмари, яка підтримує agent-based scans, web application scanning та інтеграцію з CI/CD і SIEM. В AWS додатково працює Amazon Inspector для безперервного сканування EC2, контейнерних образів у ECR та Lambda-функцій.
False positives
Найбільша пастка security-автоматизації – надлишок знахідок. Сотні сповіщень на день, багато з яких являють собою хибні тривоги. Дуже швидко настає alert fatigue, коли команда починає ігнорувати всі алерти підряд, включно з реальними. Якщо розробник щоранку закриває двісті сповіщень «на автоматі», він так само закриє і двісті перше, яке виявиться справжньою критичною вразливістю.
Це стратегічна проблема, а не технічна дрібниця. Інструменти, яким не довіряють, руйнують всю систему безпеки. Команда з ретельно розгорнутим, але погано налаштованим security-стеком може бути вразливішою, ніж без нього, бо вона впевнена у захисті, якого насправді немає. Саме тому тюнінг інструментів – не менш важлива робота, ніж їх початкове впровадження.
У SharksCode цю проблему вирішували системно. Ключову роль відіграв механізм інтелектуальної дедублікації знахідок в ox.security на базі ШІ. Замість сотень однотипних спрацювань команда отримує консолідовану картину реальних ризиків, що суттєво спрощує їхню валідацію.
CISO SharksCode Олександр Мацера
«Однією із унікальних властивостей системи ox.security є механізм інтелектуальної дедублікації знахідок, що використовує можливості ШІ в своїй основі. Використання цього механізму суттєво спрощує нам аналіз виявлених вразливостей, зокрема під час їхньої валідації», — пояснив CISO SharksCode Олександра Мацера.
Паралельно проводився тюнінг правил і порогів під специфіку конкретних проєктів, а не дефолтні конфігурації. Для відомих false positives ведуться suppress-листи з обов’язковою документацією причини кожного виключення – щоб рішення про ігнорування конкретного сигналу було усвідомленим і відстежуваним, а не просто заглушкою. Враховується такий контекст, як мова, фреймворк, тип продукту. Налаштований triage-процес визначає, хто і як відрізняє реальну вразливість від шуму.
Кінцевою метою цього процесу є висока довіра до кожного. Коли розробник бачить алерт від security-системи, він має знати, що це, швидше за все, реальна проблема, яку варто розглянути.
Автоматизація замість бюрократії
Найчастіше опір до security-інструментів виникає через побоювання, що це сповільнить роботу. Погано інтегрована безпека справді перетворюється на бюрократичне пляшкове горло: ручні аудити перед релізом, погодження із security-відділом, чек-листи, які ніхто не любить заповнювати. І все це безпосередньо перед деплоєм, коли тиск максимальний.
У SharksCode це вирішували на рівні архітектури. Паралельне виконання незалежних перевірок, асинхронні сповіщення для некритичних знахідок, централізація через ox.security. Замість десятка розрізнених інструментів усі сигнали зібрані в одному місці й опрацьовуються за єдиною моделлю пріоритизації ризиків. Менше контекстних перемикань і «зоопарку» інструментів, але більше фокусу на тому, що справді важливо.
Ручні процеси (аудити перед релізом, погодження із security-відділом) поступово замінюються автоматизованими перевірками без втрати якості контролю. Людина залишається в архітектурних рішеннях, triage складних і неоднозначних кейсів, визначенні правил і пріоритетів. Рутину віддають машинам, а судження залишають людям.
«Усвідомлення необхідності SSDLC приходить не відразу, а через накопичення різних факторів. Моя порада: не чекайте, коли керівництво дозріє само. Методично доносьте переваги вже зараз», – каже COO SharksCode Станіслав Андрєєв.
Безпека, вбудована в процес розробки, – це інвестиція в передбачуваність. Менше інцидентів, дорогих виправлень після релізу, технічного боргу, який непомітно накопичується, поки команда відкладає безпеку на потім. І в кінцевому підсумку залишається більше часу на те, щоб будувати продукт, а не гасити пожежі.