Через велику кількість термінів та інформаційного шуму у кібербезпеці, такі різні терміни, як AppSec і DevSecOps, час від часу плутаються. Остання хвиля контенту, згенерованого штучним інтелектом тільки заважає знайти правду. Тож, далі проаналізуємо схожості, відмінності та перетини між AppSec і DevSecOps.
Чи дійсно це два різні терміни?
З першого погляду, ці два терміни досить чіткі та відмінні. AppSec є скороченням для application security — сфери кібербезпеки, що займається створенням безпечного програмного забезпечення, його запуском без вразливостей і захистом від атак. Це дуже широка сфера: вона охоплює аналіз коду, тестування справних додатків, захист розгортань і багато іншого з використанням різноманітних методологій та інструментів. У технічній індустрії AppSec часто використовується у вужчому значенні — для пошуку та усунення вразливостей у вебдодатках.
DevSecOps — це термін, що описує робочий процес і культуру включення безпеки в DevOps, методологію, яка об’єднує розробку додатків і операції в один інтегрований, високоавтоматизований і безперервний процес. DevSecOps (або SecDevOps) з’явився, оскільки команди DevOps значно випереджали традиційні методи тестування та усунення вразливостей. Щоб мінімізувати ризики безпеки без уповільнення швидкої розробки та доставлення програмного забезпечення, в пайплайн довелося додати автоматизовані інструменти безпеки та робочі процеси — і “Sec” додалося до “DevOps”.
Маючи ці визначення, розберемось, як ці два поняття перетинаються і чому вони можуть заплутуватися.
Різні підходи до практик безпеки
Можна сказати, що DevSecOps — це систематичний спосіб додавання application security у життєвий цикл розробки програмного забезпечення. Це натякає на твердження, що DevOps + AppSec = DevSecOps. Тож, чи означає це, що коли команди DevOps просять “shift left” і загалом почати займатися безпекою в їхньому циклі розробки, вони на шляху до того, щоб стати командами DevSecOps? Якщо дивитися лише на процес розробки, чи є AppSec і DevSecOps в основному еквівалентними?
DevSecOps — це більше культура, ніж конкретна методологія, з акцентом на впровадження мислення про безпеку в процес DevOps. Це про те, щоб зробити безпеку рутинним і обов’язковим аспектом якості програмного забезпечення на рівні з функціональністю, продуктивністю, підтримкою тощо. Однак, оскільки пайплайн DevOps є високоавтоматизованими, перехід до DevSecOps має бути підкріплений такими ж автоматизованими (але все ще точними) інструментами безпеки. Тут і починаються дискусії про інструменти AppSec і DevSecOps.
Варіанти інтеграції “AppSec” в “DevSecOps”
Ідея зробити безпеку частиною якості програмного забезпечення є гарною в теорії. В реальності, команди розробки мали складні стосунки з безпекою. Коли говорять про інструменти DevSecOps, зазвичай маються на увазі інструменти безпеки, які можуть працювати в автоматизованих механізмах DevOps, не порушуючи потоку роботи.
Є три основні способи проведення автоматизованого та безперервного тестування безпеки додатків у процесі DevOps: два статичні (SAST і SCA) і один динамічний (DAST). Кожен з них має свої переваги та обмеження, тому найкраща практика безпеки додатків полягає у використанні всіх трьох на різних етапах процесу, аби максимально залучити їх сильні сторони.
Навіщо потрібне SCA?
SCA розв’язує проблему широкого використання компонентів з відкритим кодом. При швидкому темпі розробки, наявність подібних каркасів і готових деталей є необхідністю, допомагаючи розробникам стандартизувати процеси та зосереджуватися на спеціальній бізнес-логіці, а не на створенні загальних рутин з нуля.
Впровадження перевірок SCA у пайплайн (конвеєри) є поширеною практикою, що допомагає ідентифікувати та оновлювати (або уникати) відомі вразливі компоненти. Деякі інструменти SCA також можуть перевіряти відповідність ліцензій і сканувати бази кодів на наявність фрагментів відкритого коду. Недоліком є те, що SCA може генерувати багато попереджень, які не застосовуються у конкретному контексті і які розробникам доводиться фільтрувати або просто ігнорувати.
Чи є SAST безпечним?
Найпоширенішим методом додавання перевірок безпеки до розробки є сканування коду на вразливості одразу після його написання, так само як Linter (програма, яка використовується розробником як “інструмент статичного аналізу коду який використовується для покращення якості коду”) та інші інструменти для розробників запускаються для знаходження помилок у коді. Інструменти SAST можуть працювати безпосередньо в IDE або як окремий процес аналізу. Вони також мають перевагу в тому, що вони легко інтегруються у SDLC і можуть використовуватися на будь-якому етапі розробки, навіть на коді, який ще не працює або не буде доступний запущеним додатком.
Як і у випадку з SCA, найбільшим недоліком SAST є доволі низька точність через наявність хибнопозитивних спрацювань, але неактуальних попереджень. Інструменти SAST також специфічні для програмних мов і обмежені кодом, який фактично знаходиться в активній розробці. А оскільки це статичний аналіз, він не може підтвердити, чи можливо буде використати цю вразливість і чи не виявить вразливостей у режимі виконання.
Погляд зі сторони на DAST
Інструменти DAST є необхідними для DevSecOps, оскільки вони розширили свою традиційну роль зовнішніх сканерів вразливостей, щоб забезпечувати динамічне тестування під час QA і на ранніх етапах збірки. DAST може сканувати будь-який справний вебдодаток і API (навіть прототип) на вразливості, незалежно від використовуваних технологій і компонентів. Якісні інструменти мають дуже низький рівень хибнопозитивних спрацювань і вимагають значно менше налаштувань і регулювань порівняно з SAST для отримання корисних результатів. Вони також безпосередньо інтегруються з популярними інструментами відстеження проблем та інструментами для співпраці, щоб надсилати проблеми безпеки безпосередньо розробникам разом з рекомендаціями щодо їх усунення.
Зворотний бік динамічного тестування всіх справних додатків ззовні полягає в тому, що будь-який не завантажений код не буде протестовано. DAST також не може тестувати чисто статичний код, як ізольований фрагмент або модуль, і часто надає трохи менш точні місця виявлення проблем, ніж конкретний рядок коду, на який може вказати SAST. Якість і зручність використання результатів DAST може сильно варіюватися залежно від конкретного інструменту та його технічної зрілості — гарний DAST може стати основою процесу DevSecOps, тоді як неякісний DAST швидко вийде з ужитку через створення більшої кількості проблем, ніж їх вирішення.
Безперервний процес безпеки, незалежно від назви
AppSec і DevSecOps є тісно пов’язаними термінами, які перетинаються в багатьох моментах. Однією з ключових відмінностей є те, що кожна організація, яка запускає додатки, повинна мати та впроваджувати програму AppSec, навіть якщо вона не розробляє власне програмне забезпечення. DevSecOps як процес розробки програмного забезпечення є актуальним лише тоді, коли створюються і запускаються власні додатки. Ще одним перетином є те, що, будь-яка сучасна організація певного розміру створює принаймні частину свого програмного забезпечення внутрішньо.
Найважливіше полягає в тому, що безпека додатків повинна бути впровадженою і розділеною відповідальністю в будь-якій організації, яка розробляє програмне забезпечення. Більшість популярних термінів з цієї сфери зводяться до наявності рутинного і безперервного процесу безпеки програмного забезпечення. Це починається з безпечного кодування та дизайну. А продовжується автоматизованим тестуванням на наявність вразливостей безпеки і закінчується операційною стороною підтримки належного рівня захисту на виробництві. Назва забезпечення не має значення до того моменту, поки використовуються ефективні інструменти та процеси для контролю ризику безпеки.
