DevSecOps: Інтеграція безпеки продукту на кожному етапі SDLC

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

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

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

Що пропонує DevSecOps?

По-перше, DevSecOps чітко дає зрозуміти, що «безпека є обов’язком кожного», одночасно гарантуючи збереження швидкості розробки.

Таким чином, DevSecOps може існувати без використання додаткового програмного забезпечення для перевірки безпеки. DevSecOps допомагає зменшити затримки між доставкою коду з Dev платформи в Security і назад, забезпечуючи економію часу та ресурсів. Це досягається завдяки включенню безпеки в процес розробки, тестування та впровадження програмного забезпечення.

У традиційному SDLC безпека розглядається як перешкода для інновацій і швидкої розробки. За допомогою DevSecOps тестовий код піддається всім перевіркам безпеки, і команди проєкту не мають проблем з безпекою, такими як випадкові атаки, зломи та простої.

У процесі інтеграції безпеки DevSecOps надає ряд ключових переваг для своїх користувачів, а саме:

• Використовує набір процедур тестування, включаючи інтеграційне, модульне тощо, щоб запобігти регресії та підвищити якість кожного релізу, тим самим заощаджуючи значну кількість часу.
• Визначає вразливі місця на кожному етапі, що знижує ризики проєкту.
• Працює за принципом безпеки за проєктом, який передбачає надання розробникам механізмів автоматизованого тестування.
• Використовує відповідний підхід до розгалуження та тегування для керування джерелами (SCM) і автоматично генерує примітки до випуску, щоб надати всім зацікавленим сторонам повне розуміння.
• Гарантує успішність кожної збірки та наявність узгодженого та ефективного механізму вирішення проблем у разі збоїв, що заохочує співпрацю між різними командами.
• Надає можливість членам команди аналізувати KPI та покращувати процес DevSecOps.
• Використовує синьо/зелене розгортання (Blue-green deployment)  для швидкого реагування на зміни.
• Дозволяє командам без проблем використовувати ті самі процеси та інструменти для додатків, незалежно від мови програмування, на якій вони написані.
• Спільна відповідальність за безпеку допомагає створювати та випускати функції та виправляти проблеми без будь-яких перешкод.
• Допомагає уникнути шкоди репутації, запобігаючи ймовірності порушення, завдяки посиленому аудиту та моніторингу.

Ось як DevSecOps виводить DevOps на новий рівень.

Як змінюються етапи SDLC при впровадженні DevSecOps

1. Планування (Plan).

Етап планування DevSecOps є найменш автоматизованим, і неможливий без співпраці, обговорення, перегляду та стратегії аналізу безпеки. Команди повинні провести аналіз безпеки та розробити графік тестування, у якому вказано, де, коли та як воно буде проводитися.

IriusRisk, інструмент спільного моделювання загроз, є популярним інструментом планування DevSecOps. Є також інструменти для співпраці та спілкування, як Slack, і рішення для керування та відстеження проблем, як Jira або Asana.

2. Код (Code).

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

Кожне фіксування та злиття автоматично запускає перевірку безпеки або перевірку, коли технології безпеки безпосередньо інтегровані в існуючий робочий процес Git розробників. Ці технології підтримують різні інтегровані середовища розробки та багато мов програмування. Деякі популярні засоби безпеки включають PMD, Gerrit, SpotBugs, CheckStyle, Phabricator і Find Security Bugs.

3. Розробка (Build).

Коли розробляють код для вихідного репозиторію, починається етап «складання». Основним завданням інструментів збірки DevSecOps є автоматизований аналіз безпеки вихідного артефакту збірки. Статичне тестування прикладного програмного забезпечення (SAST), модульне тестування та аналіз компонентів програмного забезпечення є найважливішими процедурами безпеки. Інструменти можна впровадити в існуючий конвеєр CI/CD для автоматизації цих тестів.

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

Найпопулярніші інструменти для створення фазового аналізу збірки включають Checkmarx, SourceClear, Retire.js, SonarQube, OWASP Dependency-Check і Snyk.

5. Тестування (Test).

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

Інструменти динамічного тестування безпеки додатків (DAST) використовуються протягом усього процесу тестування для виявлення потоків додатків, таких як авторизація, автентифікація користувачів, кінцеві точки, підключені до API, і впровадження SQL.

На поточному ринку доступні численні платні інструменти тестування з відкритим кодом. Підтримувані функції та мовні екосистеми включають BDD Automated Security Tests, Boofuzz, JBro Fuzz, OWASP ZAP, SecApp suite, GAUNTLET, IBM AppScan і Arachi.

6. Реліз (Release).

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

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

На етапі випуску рішення для керування конфігурацією є ключовим компонентом безпеки. На цьому етапі можливий перегляд і аудит конфігурації системи. У результаті коміти до репозиторію керування конфігураціями можуть використовувати для зміни конфігурації, яка стає незмінною. Деякі популярні інструменти керування конфігурацією включають HashiCorp Terraform, Docker, Ansible, Chef і Puppet.

7. Розгорнення (Deploy).

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

Етап розгортання — це сприятливий час для таких інструментів верифікації, як Osquery, Falco та Tripwire. Вони можуть збирати дані з активної системи, щоб оцінити, чи вона функціонує належним чином. Організації також можуть застосовувати принципи інженерії хаосу, тестуючи систему, щоб підвищити свою впевненість у її стійкості до турбулентності. Можлива реплікація подій реального світу, таких як збої жорсткого диска, втрата з’єднання з мережею та збої сервера.

8. Функціонування (Operation).

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

9. Нагляд (Monitor).

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

Найкращі практики для впровадження DevSecOps

Реалізація філософії DevSecOps вимагає поєднання кількох підходів і відходу від традиційного світогляду. Нижче наведені поради щодо покращення процесу тут і зараз:

• Вимірюйте час, втрачений на роботу з уразливими місцями після об’єднання коду. Далі знайдіть шаблон у типі чи джерелі цих вразливостей безпеки та внесіть корективи для покращення.
• Визначте больові точки та ризики програмного забезпечення між розробкою та безпекою, створіть план їх вирішення, а потім виконайте цей план.
• Робіть  невеликі зміни в код. Менші оновлення легше переглядати та захищати, і їх можна запускати швидше, ніж монолітні зміни проєкту.
• Автоматизуйте та інтегруйте сканування безпеки. Зробіть сканування усюди, щоб перевіряти кожну зміну безпечного коду та виявляти недоліки безпеки в джерелі їх створення.
• Вбудуйте сканування безпеки в робочий процес розробника. Інтегрована безпека дозволяє розробникам знаходити та виправляти вразливості до того, як код побачить світ. Це також зменшує кількість уразливостей із відкритим кодом, які надсилаються команді безпеки, спрощуючи їх перевірку.
• Надайте розробникам доступ до звітів SAST і DAST. Хоча це важливо для виправлення, це також цінний інструмент, який допомагає розробникам розробляти безпечні методи кодування.
• Зменште або виключіть будь-які каскадні процеси безпеки у вашому SDLC. Ви завжди повинні мати можливість змінювати напрямок у разі потреби: підтримуйте свою організацію та засоби керування безпекою.
• Надайте групі безпеки бачення як вирішених, так і невирішених уразливостей у коді, де знаходяться вразливості, хто їх створив і їхній статус для виправлення.
• Оптимізуйте свій інструментарій, щоб співробітники могли зосередити свою увагу на одному інтерфейсі: єдиному джерелі правди.

А що по кейсах?

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

Один з кейсів – це історія Hilti, яка успішно впровадила GitLab для забезпечення власного коду із SCM, CI/CD та сканування безпеки. За допомогою GitLab час розгортання скоротився з трьох годин до всього лише 15 хвилин. Тепер команди розробки та тестування володіють кодом та можуть бачити потенційні вразливості заздалегідь. Завдяки GitLab вони змогли розробляти програмне забезпечення власними силами та швидше, ніж якби використовували складний набір інструментів.

Інша успішна історія – Dunelm, ритейлер товарів для дому, який обрав GitLab SaaS Ultimate для інтеграції інструментів та безшовного розгортання безпечних конвеєрів на хмарній платформі AWS.

В міру того, як інженерні команди Dunelm переходили до цільової архітектури безсерверних технологій, вони виявляли великі пробіли в існуючих інструментах CI/CD. Для того, щоб інтегрувати різноманітні плагіни та швидко створювати надійні програмні конвеєри, була необхідна більша автоматизація, поліпшення управління, безпеки та гнучкості. Керівництво Dunelm обрало GitLab CI/CD, щоб дозволити технічним командам взяти на себе проблеми продуктивності, тестування та безпеки на початку та протягом усього SDLC. Сьогодні команди можуть запускати більш складні сканування в рамках конвеєрів GitLab. За допомогою сканування SAST/DAST вразливості безпеки виявляються значно раніше в процесі розробки та команди можуть їх одразу виправляти.

Ще один наочний приклад, як GitLab оптимізував роботу компанії Zebra, платформі для порівняння онлайн страхування. Зокрема, Zebra використовувала GitHub та Jenkins для розгортання, велика кількість плагінів призвела до складнощів з управлінням та проблемам безпеки. Після аналізу різних платформ, керівництво обрало GitLab, який пропонує розширений репозиторій та можливості CI/CD. Крім того, команди перейшли від використання трьох інструментів до використання лише GitLab CI/CD, що дозволило повністю автоматизувати процес. GitLab також забезпечив безпеку та відповідність вимогам сертифікації SOC2.

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

Чек-лист на 10 пунктів для перевірки безпеки

Наостанок пропоную вам розглянути чек-лист безпеки DevSecOps з десяти кроків, якими користуються в GitLab, і який може допомогти команді засинхронитись і впевнитись, що вони на правильному шляху.

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

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

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

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

5. Вносьте невеликі, інкрементні зміни до коду. У GitLab ітерація є однією з основних цінностей, тому, коли вони вносять зміни, ці зміни невеликі та швидкі у виконанні, які вже потім розвиваються. Той самий принцип діє і при переході від DevOps до DevSecOps. Невеликі, інкрементні зміни коду легше перевіряти та захищати, і їх можна запускати швидше, ніж монолітні зміни в проєкті.

6. Автоматизуйте та інтегруйте. Автоматизація та інтеграція є ключовими для DevOps, але вони також роблять сканування безпеки потужним інструментом. Якщо сканування буде виконуватись усюди, кожна зміна коду буде перевірятися, і вразливості будуть знайдені набагато раніше.

7. Зробіть прозорою звітність про безпеку. Замість того, щоб тримати результати статичного тестування безпеки додатків (SAST) і динамічного тестування безпеки додатків (DAST) в ізоляції в командах безпеки, переконайтеся, що ця інформація доступна для всієї команди, особливо для розробників.

8. Визначте, чи маєте ви процеси безпеки за принципом Waterfall. При традиційному waterfall підході до безпеки вразливості зазвичай виявляються наприкінці циклу розробки. Витратьте час на аудит існуючих робочих процесів безпеки в рамках SDLC. Якщо ви знайдете будь-які процеси у стилі водоспаду, подумайте про те, щоб усунути або принаймні значно зменшити свою залежність від них. Ви завжди повинні мати можливість змінювати напрямок.

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

10. Об’єднайте свої інструменти в єдину платформу DevSecOps. Важко відповідати за безпеку, коли команди не мають потрібних інструментів. Найкращий спосіб Shift Left Security – це наскрізна платформа, яка допомагає командам DevOps відійти від процесів Waterfall, впорядковує комунікацію, включає автоматизацію та безперервну інтеграцію, а також забезпечує єдине джерело правдивих даних про результати сканування безпеки та стан критичних вразливостей.

Підсумовуючи, впровадження DevSecOps має наступні переваги:

• Це допомагає створити довіру клієнтів, надаючи безпечні продукти і сервіси.
• Це запобігає використання вразливостей системи та покращує безпеку системи в цілому.
• Методологія DevSecOps дозволяє командам швидко досягати результатів, забезпечуючи найвищий рівень безпеки.
• Інтегруючи засоби безпеки в процес розробки програмного забезпечення від проєктування до розгортання, команди можуть миттєво виявляти й усувати потенційні ризики, таким чином зменшуючи ризики зловмисних атак.
• DevSecOps допомагає організаціям випереджати потенційні загрози та залишатися конкурентоспроможними на своїх ринках.

Загалом, впровадження DevSecOps має важливе значення для будь-якої команди, яка прагне захистити себе від зловмисних атак, при цьому швидко й ефективно забезпечуючи розробку. Крім того, інтеграція безпеки в SDLC гарантує безпеку всіх нових програм із самого початку. 

Gitlab and Cloudfresh

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

Наші експерти GitLab допоможуть вам впровадити та керувати високоякісними технічними рішеннями GitLab.

Скористайтеся цим посиланням, щоб отримати 30-денну безкоштовну пробну версію для самоврядних ліцензій GitLab, професійної адаптації, консультацій, досвіду та технічної підтримки від Cloudfresh.

Давайте прискоримо вашу трансформацію DevSecOps разом!

Зв'яжіться з Сloudfresh