Кейс Invicti ASPM: Як створити програму безпеки з нуля?

Галузь: Електронна комерція

Компанія: Ödeal

Місцезнаходження: Туреччина

Продукт: Invicti ASPM

Історія компанії Ödeal про створення програми AppSec.

Виклики

• Ödeal мала проблему, що безпека не була вбудована в життєвий цикл розробки програмного забезпечення (SDLC). Інструменти використовувалися командами розробників за бажанням.

• Тести на проникнення, що проводилися щоквартально, чинили тиск на команди розробників, оскільки усунення вразливостей заважало їхній діяльності.

• Не було жодної видимості вразливостей додатків, як і контролю за показниками безпеки.

Про Ödeal

Заснована у 2014 році, Ödeal є постачальником платіжної технології, яка дозволяє компаніям отримувати платежі дебетовими або кредитними картками за допомогою мобільних телефонів. Маючи понад 68 000 клієнтів та надійну бізнес-модель, компанія отримала фінансування у 2021 році та з того часу швидко розширює свої технологічні команди.

Ситуація

Як фінтех-стартап, що швидко зростає, як і їхня технічна команда, Ödeal перебувала в процесі реструктуризації своїх процесів CI/CD.

Через характер бізнесу, безпека була проблемою для керівництва, але з такою кількістю завдань розробників, навряд чи можна було виділити час на створення конвеєра CI/CD, інтегрованого з інструментами безпеки.

Існувала потреба в платформі, де тести безпеки можна було б легко інтегрувати з CI/CD пайплайнами, що також могло б забезпечити видимість загального стану безпеки програм.

Підхід Invicti ASPM

1. Як перший крок, додатки, що існують в інструменті CI/CD, автоматично завантажувалися до Invicti ASPM після інтеграції за лічені хвилини.
2. На основі технологічного стека, що використовується в кожній програмі, були налаштовані відповідні інструменти безпеки з відкритим кодом в Invicti ASPM.
3. Оскільки Ödeal вже мав механізм git-flow branching, тести безпеки були розташовані між гілками функцій та розробки. Це було потрібно, щоб у кожному pull-request Invicti ASPM міг запускати сканування з інструментами безпеки з відкритим кодом.
4. Загальнокорпоративний скрипт полягав у тому, що якщо репозиторій нещодавно був створений в інструменті CI/CD, але ще не в Invicti ASPM, він автоматично створювався через CLI на основі ієрархії, що використовується командами розробників програмного забезпечення.
5. Використовуючи можливості автоматизації на основі міток в Invicti ASPM, до програм з різними мітками (тобто внутрішні, зовнішні, GDPR) застосовувалися різні політики автоматизації.
6. Функціональність додавання результатів перевірки безпеки безпосередньо у pull-request дала змогу розробникам отримувати доступ до вразливостей, виявлених у кожному pull-request в їхньому інструменті CI/CD, щоб вони були обізнані про вразливості, перш ніж переходити до подальших етапів конвеєра.

Результати

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

• Завдяки цьому тепер будь-яка команда, яка переходить на новий пайплайн CI/CD, автоматично інтегрує свої проєкти в Invicti ASPM та починає самостійно виконувати попередньо визначені тести безпеки в рамках конвеєрів.

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