Что должен знать технический директор о DevSecOps
Меня зовут Вячеслав Бессонов, я основатель провайдера IT-решений Hilbert Team, в прошлом разработчик и CTO. В этой статье хочу объяснить, почему техническим директорам важно не игнорировать методологию DevSecOps.
Вместо предисловия, приведу для примера две ситуации, которые я сам не раз наблюдал на рынке, и, думаю, вы тоже.
1 история
Одна компания долгое время разрабатывала продукт, но спустя всего пару месяцев после долгожданного релиза она подверглась хакерской атаке, в результате которой были слиты пользовательские данные. Причиной инцидента стала уязвимость в сторонней библиотеке, интегрированной в код продукта. Несмотря на то, что сам код был тщательно проверен, уязвимость в библиотеке осталась незамеченной. В результате атаки компания столкнулась с серьезными последствиями, включая утечку данных, финансовые потери и ущерб репутации.
Вывод
Такой сценарий, к сожалению, не редкость в современном мире. Классический пример атаки на цепочку поставок — когда злоумышленник тайно внедряет вредоносный код в легитимное программное обеспечение. По данным Cyble в 2024 году, атаки на цепочку поставок происходили как минимум раз в два дня.
2 история
Компания, стремясь обеспечить максимальную безопасность своего продукта, решила привлечь команду специалистов по информационной безопасности для проведения финального аудита перед релизом. Однако, стремление к безупречной защите столкнулось с жесткими временными рамками, установленными руководством. Когда на финальной стадии тестирования была обнаружена критическая уязвимость, стало очевидно, что релиз необходимо отложить на несколько месяцев. Это вызвало дополнительные финансовые затраты и недовольство руководства.
Вывод
Это доказывает нам, что традиционный подход к обеспечению безопасности, когда она рассматривается как отдельный этап в конце разработки, уже не работает. Мир меняется слишком быстро, а риски растут с каждым днем.
Что же делать? Ответ кроется в методологии DevSecOps.
Краткий исторический экскурс в мир DevSecOps
DevSecOps – это по сути расширение методологии DevOps с интеграцией в него автоматизированных проверок безопасности. DevSecOps стала ответом на растущую потребность в более безопасных и надежных программных системах в условиях постоянных кибератак.
Ключевые события и факторы, повлиявшие на появление DevSecOps:
В последние годы значительно возросло количество и сложность кибератак, в том числе распространились атаки на цепочки поставок (supply chain attack), что привело к серьезным финансовым потерям и репутационным рискам для многих компаний. Отметим, что в 2024 году количество кибератак на российские компании выросло в 2,5 раза по сравнению с 2023 годом и почти достигло 130 тысяч.
Переход к облачным вычислениям ускорил процесс разработки и развертывания программного обеспечения, но также создал новые уязвимости.
Переход от монолитной архитектуры к микросервисам повышает гибкость, но усложняет управление безопасностью.
Все более строгие требования к безопасности данных, такие как ФЗ-152, ГОСТ Р 56939-2024, ГОСТ Р 71207-2024 и другие, заставили компании уделять больше внимания защите информации.
Термин «DevSecOps» начал активно использоваться после 2016 года, так что это довольно молодое направление. Он отразил понимание того, что безопасность должна быть интегрирована в каждый этап разработки, начиная с планирования и заканчивая эксплуатацией.
Зачем это CTO?
Как мы уже выяснили, DevSecOps — это не просто набор инструментов или процессов, это новый подход к разработке программного обеспечения, который ставит безопасность на первое место.
Давайте резюмируем, зачем вам как техническому директору важно не игнорировать эту свежую тенденцию:
Принцип DevSecOps
Ключевая идея DevSecOps — автоматизировать проверку безопасности на каждом этапе разработки программного обеспечения. Раньше, когда тестирование безопасности проводилось в конце, любые найденные уязвимости требовали возврата к начальным этапам разработки, что увеличивало затраты и время на проект, что показано на схеме ниже. DevSecOps позволяет выявлять и исправлять проблемы безопасности гораздо раньше, еще на стадии написания кода.
Чем раньше обнаруживается уязвимость в системе, тем меньше затрат она требует для устранения. Если ошибка найдена на ранних этапах разработки, исправить ее отно��ительно просто.
Однако, если проблема вскрылась на этапе сборки, то стоимость ее устранения возрастает в несколько раз из-за необходимости внесения изменений в процесс сборки. Еще дороже обходится исправление ошибок на стадии интеграционного тестирования, которое может потребовать полного перезапуска цикла разработки. Самые дорогостоящие и опасные последствия несут в себе уязвимости, обнаруженные после развертывания системы, так как они могут привести к утечкам данных и серьезным репутационным потерям.
Именно поэтому так важно проводить проверки безопасности как можно раньше в процессе разработки, сдвигая их влево по пайплайну, что соответствует концепции Shift Left.
Проверки безопасности на каждом этапе пайплайна разработки:
Давайте разберемся, какие проверки проводятся на каждом этапе и какие инструменты для этого используются.
- Pre-commit
Проверка на локальных машинах разработчиков исходного кода перед тем, как он попадает в систему контроля версий. Это помогает выявить уязвимости еще до того, как они попадут в удаленный репозиторий. - Pre-build
После того как код попал в систему контроля версий, запускаются более глубокие проверки. Используются такие инструменты как:- Secret Detection ищет утечки секретных данных, таких как пароли, токены доступа, ключи API, прямо в коде.
- SAST (Static Application Security Testing) анализирует исходный код на наличие уязвимостей без запуска приложения.
- OSA (Open Source Analysis) позволяет не допускать попадания небезопасных Open Source-компонентов в контур разработки и в сами продукты.
- SCA (Software Composition Analysis) сканирует зависимости (компоненты) проекта на наличие уязвимостей. Post-build
После сборки приложения из исходного кода проводится дополнительная проверка собранного артефакта (например, Docker-образа). Здесь также используются SCA, но уже для анализа бинарных файлов.Test-time
Во время тестирования приложения используются более продвинутые инструменты:- DAST (Dynamic Application Security Testing) анализирует приложение в процессе работы, имитируя атаки хакеров.
- IAST(Interactive Application Security Testing) повышает точность динамического тестирования, потому что дает больше информации о работе приложения благодаря анализу кода.
- OAST (Out-of-band Application Security Testing) находит уязвимости, которые не видит DAST.
Post-deploy
На этапе эксплуатации приложения также необходимо проводить проверки безопасности, чтобы выявить возможные проблемы, когда приложение находится в реальной среде:
- MAST (Mobile Application Security Testing) анализирует защищенность мобильных приложений.
- Container Security обеспечивает контейнерную безопасность.
Постоянный мониторинг безопасности позволяет своевременно выявлять и реагировать на возникающие угрозы:
- WAF (Web Application Firewall) обеспечивает защиту веб-приложений. Это инструмент для фильтрации трафика. Он работает на прикладном уровне и защищает веб-приложения, анализируя трафик HTTP/HTTPS.
❗Критически важно настроить процесс управления уязвимостями, а его эффективное построение возможно при наличии инструмента, в котором можно анализировать все результаты работы. Это могут быть ASOC (Application Security Orchestration and Correlation) или ASPM (Application Security Posture Management).
Таким образом, комплексный подход к безопасности на протяжении всего жизненного цикла разработки позволяет значительно снизить риски, связанные с киберугрозами. Использование различных инструментов на каждом этапе пайплайна помогает обеспечить надежную защиту приложения.
Получите бесплатно обзор отечественных DevSecOps-инструментов со всеми преимуществами и особенностями.
Какие сложности возникают при внедрении DevSecOps?
Внедрение DevSecOps может столкнуться с рядом трудностей.
Одна из них — это культурный разрыв между разработчиками и специалистами по безопасности. Разработчики стремятся к быстрой доставке продукта, а специалисты по безопасности — к его максимальной защищенности. Этот конфликт интересов может затруднить внедрение DevSecOps.
Кроме того, интеграция различных инструментов безопасности в существующую инфраструктуру разработки может оказаться сложной задачей и повлиять на скорость разработки. Однако важно понимать, что замедление разработки на начальных этапах – это инвестиция в долгосрочную безопасность. В дальнейшем, когда процессы будут отлажены, а инструменты интегрированы, скорость разработки, наоборот, может увеличиться благодаря раннему обнаружению и устранению уязвимостей.
Также проблемой может стать отсутствие специалистов, обладающих как навыками разработки, так и знаниями в области безопасности.
И не будем забывать о том, что внедрение DevSecOps требует инвестиций в новые инструменты, обучение сотрудников и изменение процессов, но, как мы уже выяснили, в дальнейшем, это может значительно сэкономить бюджет.
Как Hilbert Team может поддержать внедрение DevSecOps?
Hilbert Team предоставляет комплексную услугу по внедрению DevSecOps, которая включает в себя большой портфель российских и/или Open Source-инструментов, их интеграцию в контур заказчика, а также дальнейшую поддержку и обучение команд заказчиков.
На первом этапе мы проводим DevSecOps-аудит, который позволяет оценить зрелость процессов по безопасности и объем необходимых работ по внедрению инструментов.
На втором этапе происходит непосредственно внедрение выбранных AppSec-анализаторов.
На заключительном этапе мы предлагаем обучение для инженерной команды заказчика и ежемесячную поддержку, если есть необходимость.
Если вам интересно разобраться, как внедрить DevSecOps в вашей организации, предлагаем записаться на бесплатную консультацию с нашими специалистами, где мы разберем вашу текущую ситуацию и предложим решения, которые помогут настроить процесс безопасной разработки ваших приложений.