16 причин невдач зусиль DevSecOps (і як їх виправити)
Гетті
Оскільки резонансні кібератаки регулярно потрапляють у заголовки газет, не дивно, що все більше компаній сприймають рух DevSecOps. З метою впровадження функцій безпеки та зосередженості на кожному етапі процесу розробки — від концепції до випуску — DevSecOps об’єднує команди розробників, безпеки та операцій для створення кращих, потужніших процесів і продуктів — принаймні теоретично.
Насправді впровадження DevSecOps — це не простий крок; це вимагає нових партнерств і процесів, підкріплених повною відданістю зацікавлених сторін. Якщо не всі підтримають цю значну зміну парадигми, це може легко провалитися. Нижче 16 членів Технологічної ради Forbes діляться загальними причинами, чому зусилля DevSecOps не вдаються, і як цих помилок можна уникнути.
1. Це стає «департаментом ні»
Спроба нав’язати стиль безпеки «департаменту ні» через DevSecOps призводить до збою цих програм. Щоб бути успішними, програми безпеки повинні містити цільові показники продуктивності розробників і націлюватися на співпрацю та навчання. Встановіть огорожі замість блокпостів (це, звичайно, легше сказати, ніж зробити). – Варун Бадвар, Лабораторії Ендор
2. Це розглядається як проблема «інструментів».
DevSecOps розглядається переважно як проблема «інструментів», але насправді це проблема «культури» (мислення) і «процесів» (робочих процесів). Інструменти є основоположними. Вони необхідні, але недостатні. Приділяти належну увагу культурним і процедурним аспектам є великою проблемою, але ставити інструменти в центрі зусиль замість людей є помилкою. – Маноджкумар Пармар, AIShield (на базі Bosch)
Технологічна рада Forbes — це спільнота для ІТ-директорів, технічних директорів і технічних керівників світового рівня. Чи маю я право?
3. Співпраця не є рівноправним партнерством
DevSecOps — це чудова стратегія для кращого узгодження між розробкою та безпекою. Це не вдається, якщо співпраця не є рівноправним партнерством і маятник коливається надто далеко в бік розвитку чи безпеки. Коли служби безпеки намагаються нав’язати політику зацікавленим сторонам, її рідко приймають. Практики DevSecOps є успішними, коли є рівноправна співпраця між командами розробки та безпеки. – Джим Баркдолл, Аксіоматика
4. Команди безпеки та розробки відсторонені
Зусилля DevSecOps іноді зазнають невдачі через відсутність взаємодії та постійного двостороннього спілкування. Недавні звільнення в технологічному секторі та люди, які змінюють роботу, також можуть сприяти створенню розбіжностей між командами безпеки та розробниками. Моя порада командам — активно заохочувати частий діалог і впроваджувати процеси, щоб взаємодія та спілкування не переривалися, коли член команди йде. – Керолайн Вонг, Cobalt
5. Існує мінімальний спільний контекст або спілкування між інженерами безпеки та розробниками
Однією з причин невдачі зусиль DevSecOps є те, що вони не починаються зі спільного контексту та довірених відносин між інженерами безпеки та інженерами-розробниками. Щоб уникнути цього, практикуйте послідовне спілкування між командами, деталізуючи потреби та плани кожної. У найуспішніших випадках залучення інженерів із безпеки, принаймні на неповний робочий день, до команд інженерів є чудовим способом забезпечення зв’язку. – Дейв Меркель, Expel
6. Виправлення проблем із безпекою сповільнює продуктивність розробників
Проблема з DevSecOps полягає в тому, що усунення проблем із безпекою сповільнює продуктивність розробника. Щоб уникнути цього, організації повинні включити DevSecOps як критично важливу для бізнесу операцію. Заохочуйте методи, починаючи з етапу підготовки до виробництва, щоб уникнути часу, витраченого на усунення вразливостей. Організації також повинні використовувати інструменти, які повністю інтегровані в конвеєр DevOps. – Шей Леві, Noname Security
7. Безпека не повністю інтегрована в процеси розробки
DevSecsOps може вийти з ладу, якщо аспект безпеки не повністю інтегрований. Щоб уникнути цього, інтегруйте команду безпеки в процес розробки з самого початку та тісно співпрацюйте з розробниками, щоб забезпечити інтеграцію безпеки на кожному етапі. Проводьте регулярні оцінки безпеки, забезпечуйте навчання безпечним методам кодування та впроваджуйте автоматизовані інструменти для виявлення та вирішення проблем безпеки в режимі реального часу. – Мілан Дордевіч, Proctorio Incorporated
8. Швидкість перемагає над дисципліною
Зусилля DevSecOps провалюються, коли швидкість перемагає над дисципліною. Бажання забезпечити оновлену функціональність дозволяє легко ігнорувати процеси безпеки, включаючи тестування, виправлення та моніторинг. Відсутність розподілу обов'язків може призвести до надмірного доступу до виробництва та впровадження несанкціонованих змін. Кінцевий продукт може мати помилки та бути вразливим до кібератак. – Говард Тейлор, Radware
9. Команда розробників вносить зміни без відома групи безпеки
Однією з причин невдачі зусиль DevSecOps є відсутність співпраці між командами. Без спілкування та співпраці групи безпеки можуть не знати про зміни, внесені командами розробників, що призводить до вразливостей або проблем з відповідністю. Щоб уникнути цього, створіть міжфункціональні команди, до складу яких входять представники команд розробки, операцій і безпеки, щоб усі були в курсі змін. – Піт Хенлон, Маніпенні
10. Існує нереалістичний термін реалізації
Нереалістичний графік може бути великою проблемою. Впроваджувати DevSecOps слід поетапно; це вимагає поступових змін і автоматизації, які добре сприймаються, розуміються, практикуються і контролюються. Добре задокументовані процеси та безперервне навчання є обов’язковими для забезпечення безперебійної роботи DevSecOps, і ми повинні не поспішати. Будь-які спроби прискорити цю роботу можуть призвести до повного провалу. – Осборн Гомес, NIOSolutions Inc.
11. Технічні та бізнес-цілі не повністю зрозумілі
Технічне керівництво має повністю розуміти технічні та бізнес-цілі. Основою успіху DevSecOps є те, що всі команди планують і розробляють стратегію впровадження. Поставлення безпеки в центр поточної роботи інших елементів значною мірою допоможе забезпечити успішність підходу DevSecOps. – Bankim Chandra, DotSquares LLC
12. Немає достатніх ресурсів, щоб задовольнити як вимоги клієнтів, так і роботу SecOps
Однією з причин невдачі зусиль DevSecOps є недостатньо ресурсів для керування вимогами клієнта до функцій порівняно з потребами DevSecOps. Якщо ваші найбільші клієнти постійно розміщують високопріоритетні елементи на вершині стеку розробників, робота SecOps майже завжди падає нижче межі для ресурсів розробників. Потрібна організаційна прихильність до шляху, або ви повинні робити невеликі шматочки, щоб досягти прогресу. – Джеймс Бічем, ALTR
13. Особливості та функціональні можливості мають пріоритет над безпекою
Причина, по якій зусилля DevSecOps не вдаються, полягає в тому, що вони не мають такого високого пріоритету, як інші аспекти розробки та розгортання. Багато компаній мають тенденцію зосереджуватися на функціях і функціях, а не на безпеці, що може призвести до того, що продукт має вразливості, яких можна було б уникнути, якби команди розробників приділяли більше уваги безпеці. – Леон Гордон, Pomerol Partners
14. Фахівці з безпеки не розуміють процесу розробки програмного забезпечення
Як правило, спеціалісти з безпеки мають досвід роботи в мережах, зосереджені на ризиках і відповідності вимогам і не розуміють процесу розробки програмного забезпечення. Команди безпеки рідко розуміють автоматизовані сервери збірки, центральний код, контейнери тощо. Відсутність розуміння та нестача експертів з безпеки робить цю проблему однією з головних причин невдачі зусиль DevSecOps. – Кіран Бхуджле, SVAM International Inc.
15. Ролі та обов'язки не визначені
Відсутність спільної відповідальності та власності є основною причиною невдачі зусиль DevSecOps. Щоб цього уникнути, члени команди повинні мати чітко визначені ролі та обов’язки. Має бути регулярний зв’язок і навчання між відділами безпеки, розробки та операцій, а також має бути план вирішення будь-яких потенційних проблем безпеки, які можуть виникнути під час процесів розробки та експлуатації. – Махант Маллікарджуна, Mergen IT LLC
16. Вище керівництво не повністю підтримало
Однією з причин, чому зусилля DevSecOps можуть провалитися, є відсутність зацікавленості та підтримки з боку вищого керівництва. DevSecOps вимагає культурних змін у тому, як спільно працюють команди розробки, безпеки та операцій, і ця зміна може бути не повністю підтримана або зрозуміла вищим керівництвом. Без їхньої підтримки ініціативам DevSecOps може бути важко набрати обертів і успішно їх реалізувати. – Іван Новіков, Wallarm Inc.
