Помилка №1: Не враховувати, що DevSecOps – це робоча культура
DevSecOps – це зміна культури компанії для включення безпеки в розробку. Хоча наявність правильних інструментів і фреймворків має вирішальне значення для успіху, головна мета (і вимога) полягає в тому, щоб зробити безпеку невід’ємною частиною якості програмного забезпечення. Перехід до DevSecOps означає серйозні зміни в тому, як всі працюють і співпрацюють, і компанії, які не впроваджують ці зміни, швидше за все, зазнають невдачі в своїх зусиллях.
«DevSecOps – це культура, в якій кожен в компанії відповідає за високоякісний продукт», – говорить Суха Акюз, старший менеджер з безпеки додатків в Invicti. «Деякі компанії розглядають DevSecOps як тягар, оскільки це означає додавання безлічі технологій, інструментів і фреймворків без універсальних стандартів або кращих практик, яким можна було б слідувати. Насправді найкращі практики побудови DevSecOps будуть різними та унікальними для кожної організації. Саме тому вона має бути частиною ширшої культури, де Dev, Sec, Ops і навіть інші відділи працюють разом, щоб досягти найвищої якості програмного забезпечення у всьому, включаючи безпеку».
Помилка №2: Намагання централізувати DevSecOps
Якщо організація не визнає необхідність культурних змін як передумову, вона може спробувати впровадити DevSecOps лише за допомогою структурних змін. Фахівець Invicti Ден Мерфі пояснює: «Нерідко DevSecOps намагаються «вирішити», призначивши на цю роль команду або відділ. Однак найбільш успішні впровадження DevSecOps визнають, що це скоріше культура і спосіб мислення. Розробка, безпека та операції об’єднані в єдину цілісну роль, в ідеалі інтегровану на рівні команди».
Спроби впровадити DevSecOps за допомогою команди «зверху-вниз» без глибоких змін всередині команд в кінцевому підсумку приречені на провал або, в кращому випадку, на поверхневі результати. Одним із прикладів цього, є невдала спроба створити спеціальну програму з безпеки, яка б навчала та надавала повноваження людині в кожній команді розробників переглядати конфіденційний код та впроваджувати найкращі практики безпеки. «Занадто часто про DevSecOps говорять на словах, але розробники продовжують писати код так, ніби розгортання, обслуговування та безпека – це проблема когось іншого».
Помилка №3: Побудова DevSecOps без точної автоматизації
Навіть за наявності правильної культури і талановитих фахівців, додавання тестування безпеки і виправлення помилок до високоавтоматизованого конвеєра DevOps спрацює тільки в тому випадку, якщо цей рівень автоматизації буде відповідати рівню компанії. «Якщо намагатися вбудувати безпеку в процес, не інвестуючи в автоматизацію, команда може вручну запускати сканування безпеки перед випуском, – пояснює Мерфі. «Це неминуче створює напругу між виправленням і відправкою, що призводить до того, що компанії свідомо випускають вразливий код, щоб вкластися у встановлені зовнішні терміни».
Крім того, що недостатня автоматизація та інтеграція ставлять під загрозу безпеку в короткостроковій перспективі, вони також негативно впливають на весь процес розробки. Без правильних інструментів, які роблять тестування і виправлення невід’ємною частиною розробки додатків, проблеми будуть накопичуватися без чіткого способу зменшити відставання. Це особливо небезпечно при спробі автоматизувати неякісні результати, які потребують трудомісткої ручної перевірки. «Неспроможність автоматизувати точне сканування безпеки як частину конвеєра CI/CD призводить до накопичення проблем з безпеки», – попереджає Мерфі.
Помилка №4: Відсутність постійного процесу DevSecOps
Безпека додатків завжди повинна бути безперервним процесом вдосконалення, як з точки зору створення більш безпечного програмного забезпечення, так і з точки зору поліпшення тестування безпеки та усунення самих вразливостей. Це особливо актуально при спробі вбудувати безпеку в конвеєр. Суха Акюз говорить про це прямо: «Якщо компанії сканують кожні три місяці, вони не займаються DevSecOps. Їм потрібно постійно відстежувати результати і щодня вдосконалювати свій конвеєр, щоб з часом покращити впровадження DevSecOps».
Навіть при наявності безперервного процесу тестування безпеки, управління вразливостями часто відходить на другий план, що знову ж таки призводить до нагромадження проблем. «Дуже важливо не тільки знайти дефекти безпеки, але й правильно з ними впоратися. Одних лише інструментів для цього недостатньо, тому важливо, щоб команда інженерів безпеки координувала запуск тестів та усунення вразливостей протягом усього процесу DevSecOps. Наявність безперервного зворотного зв’язку має вирішальне значення для запобігання вузьких місць», – підкреслює Акюз.
Помилка №5: Ставлення до DevSecOps як до прямого джерела доходу
Якщо все зроблено правильно, DevSecOps дозволяє організаціям подолати проблеми з безпекою, розглядати безпеку як частину якості програмного забезпечення і рухатися в напрямку підвищення цієї якості.
Однак він дозволяє створювати більш безпечне та якісне програмне забезпечення швидше з тими ж ресурсами, змінюючи культуру роботи, – зазначає Суха Акюз. «З часом можна побачити фінансову вигоду, оскільки заощаджується багато часу, але пряма вигода і мета DevSecOps – це покращена безпека програмного забезпечення як частина кращої якості програмного забезпечення в цілому».
DevSecOps під будь-якою іншою назвою
Немає сумнівів у тому, що забезпечення безпеки додатків зараз є обов’язковою вимогою для будь-якої організації, яка розробляє власне програмне забезпечення. В умовах стрімкого зростання кількості витоків даних та заражень шкідливим програмним забезпеченням, використання вразливого програмного забезпечення може стати надзвичайно дорогим задоволенням. DevSecOps – це один із способів вбудувати безпеку в конвеєр веброзробки, і яку б абревіатуру та процес не обрати, важливо, щоб він безперервно працював в організації.
«DevSecOps – це все ще дуже молодий підхід, який потребує часу, щоб дозріти. Жодна компанія не може сказати, що знає єдиний правильний спосіб впровадження DevSecOps. Ми можемо говорити про загальні рамки, але це не означає, що всі будуть використовувати їх однаково», – підсумовує Суха Акюз. «Головна мета – зробити безпеку процесом безперервного поліпшення якості програмного забезпечення».
