Отрасль: Электронная коммерция
Компания: Ödeal
Местонахождение: Турция
Продукт: Invicti ASPM
История компании Ödeal о создании программы AppSec.
Вызовы
- Ödeal имела проблему, что безопасность не была встроена в жизненный цикл разработки программного обеспечения (SDLC). Инструменты использовались командами разработчиков по желанию.
- Проводимые ежеквартально тесты на проникновение оказывали давление на команды разработчиков, поскольку устранение уязвимостей мешало их деятельности.
- Не было никакой видимости уязвимостей приложений, как и контроля над показателями безопасности.
Про Ödeal
Основанная в 2014 году, Ödeal является поставщиком платежной технологии, позволяющей компаниям получать платежи дебетовыми или кредитными картами с помощью мобильных телефонов. Имея более 68 000 клиентов и надежную бизнес-модель, компания получила финансирование в 2021 году и быстро расширяет свои технологические команды.
Ситуация
Как быстро растущий финтех-стартап, как и их техническая команда, Ödeal находилась в процессе реструктуризации своих процессов CI/CD.
Из-за характера бизнеса, безопасность была проблемой для руководства, но с таким количеством задач разработчиков, вряд ли можно было выделить время на создание конвейера CI/CD, интегрированного с инструментами безопасности.
Существовала потребность в платформе, где тесты безопасности можно было легко интегрировать с CI/CD пайплайнами, что также могло бы обеспечить видимость общего состояния безопасности программ.
Подход Invicti ASPM
- Как первый шаг, приложения, существующие в инструменте CI/CD, автоматически загружались в Invicti ASPM после интеграции за считанные минуты.
- На основе технологического стека, используемого в каждой программе, были настроены соответствующие инструменты безопасности с открытым кодом в Invicti ASPM.
- Поскольку Ödeal уже имел механизм git-flow branching, тесты безопасности были расположены между ветвями функций и разработки. Это было необходимо, чтобы в каждом pull-request Invicti ASPM мог запускать сканирование с инструментами безопасности с открытым кодом.
- Общекорпоративный скрипт заключался в том, что если репозиторий был недавно создан в инструменте CI/CD, но еще не в Invicti ASPM, он автоматически создавался через CLI на основе иерархии, используемой командами разработчиков программного обеспечения.
- Используя возможности автоматизации на основе меток в Invicti ASPM, к программам с разными метками (т.е. внутренние, внешние, GDPR) применялись разные политики автоматизации.
- Функциональность добавления результатов проверки безопасности непосредственно в pull-request позволила разработчикам получать доступ к уязвимости, обнаруженной в каждом pull-request в их инструменте CI/CD. Это было нужно, чтобы они были осведомлены об уязвимости, прежде чем переходить к дальнейшим этапам конвейера.
Результаты
- Не тратя много на коммерческие инструменты и даже не имея команд безопасности в компании, технический аспект перехода к DevSecOps был легко достигнут путем написания общекорпоративного скрипта конвейера, который используется во всех программах.
- Благодаря этому любая команда, которая переходит на новый пайплайн CI/CD, автоматически интегрирует свои проекты в Invicti ASPM и начинает самостоятельно выполнять тесты безопасности в рамках конвейеров.
- При отсутствии команды безопасности правила автоматизации на основе меток выполняли базовые действия по моделированию угроз в командах разработчиков. Это привело к повышению осведомленности о восприятии рисков приложений. Такой подход также помог сосредоточить внимание на уязвимостях, которые, вероятнее всего, представляют реальную угрозу, не создавая шума для команд разработчиков.
