Смена DevOps на DevSecOps

При создании или модернизации дисциплины "Безопасность разработки" в этой статье описывается, как интеграция безопасности в методики разработки позволяет перейти от операций разработчика (DevOps) к операциям с безопасностью разработчиков (DevSecOps) и помогает обеспечить безопасную доставку приложений.

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

Циклы непрерывного выпуска сокращают время между решениями проектирования и развертыванием в рабочей среде, что повышает вероятность появления слабых мест в рабочих средах, в том числе:

• Слабые места в разработке приложений
• Уязвимые зависимости
• Ошибки конфигурации
• Недостатки автоматизации инфраструктуры
• Плохое управление секретами или гигиена.

Риск DevOps

Современные среды DevOps расширяют область атаки в разных системах разработки, конвейера и рабочей среды. Средства DevOps, такие как репозитории исходного кода, конвейеры и системы автоматизации, являются высокоценными целевыми объектами для злоумышленников.

Если вредоносный код появился раньше, он может пройти через существующие проверки безопасности и достичь рабочих систем.

К общим целям атаки относятся:

• Внедрение вредоносного кода в артефакты сборки.
• Компрометация учетных данных разработчиков или сервисных учетных записей.
• Доступ к данным производственной среды или их эксфильтрация.

Злоумышленники часто нацелены на пользовательские приложения и среды разработки для получения доступа:

• Конфиденциальные данные организации или клиента.
• Частная бизнес-логика и интеллектуальная собственность.
• Производственная инфраструктура через скомпрометированные системы разработки.
• Последующие клиенты в результате компрометации цепочки поставок программного обеспечения.

Потенциальные риски безопасности приведены на следующей схеме:

Риск, связанный с приложением и разработкой

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

Риск	Цель	Потенциальный результат
Проектирование и реализация приложений	Проблемы безопасности, возникающие на этапе проектирования или разработки, могут сделать рабочие нагрузки уязвимыми для таких методов атак, как: — неправильная проверка входных данных — небезопасная логика проверки подлинности или авторизации — слабая или неправильно реализованная криптография — раскрытие конфиденциальных данных через логику приложения	Эти слабые места могут позволить злоумышленникам: — доступ к данным приложения или управление ими — выполнение несанкционированных операций - поддерживать постоянный доступ с помощью внедрённых логических уязвимостей.
Инфраструктура и автоматизация разработки	Атаки могут быть нацелены: — репозитории исходного кода — сборка конвейеров — автоматизация развертывания — Шаблоны «инфраструктура как код» (IaC) — разрабатывайте конечные точки или идентификаторы служб	Компрометация может позволить злоумышленникам: — Вставка вредоносного кода в артефакты сборки — изменение конфигураций развертывания — сохранять постоянный доступ с помощью внедрённой логической уязвимости — получение учетных данных или секретов, используемых в рабочих средах.
Цепочка поставок программного обеспечения разработки	Приложения обычно полагаются на: — сторонние библиотеки — пакеты с открытым кодом — образы контейнеров — службы платформы	Уязвимости или вредоносный код, введенные с помощью этих зависимостей, могут повлиять: — организационные производственные рабочие нагрузки — клиентские или партнерские среды

Интеграция безопасности в процессы разработки снижает вероятность распространения этих рисков в рабочий выпуск.

Сдвиг влево

Shift left — это подход к проектированию безопасности, который интегрирует безопасность ранее в жизненный цикл разработки.

Вместо проверки безопасности в конце процесса организации внедряют его в:

• Формирование видения
• Design
• Развитие
• Operations

Это снижает затраты на исправление и риск.

Чтобы поддержать этот подход, организации должны

• Используйте структурированные рекомендации, такие как жизненный цикл разработки безопасности (SDL) в начале процесса, а не поздно, когда проблемы становятся дорогостоящими и сложными.
• Чтобы обеспечить этот подход, интегрировать управление, риск и соответствие требованиям (GRC) в стратегию развития.

Что такое DevSecOps?

DevSecOps реализует подход Shift Left, расширяя DevOps и встраивая безопасность в каждый этап жизненного цикла разработки программного обеспечения — от зарождения идеи до проектирования, разработки и эксплуатации.

• В традиционных подходах к разработке проверка безопасности часто выполняется как окончательный шлюз качества перед выпуском. Это создало задержки, увеличение затрат на исправление и позволило уязвимостям сохраняться до конца жизненного цикла.

• DevSecOps смещает вопросы безопасности на более ранние этапы и непрерывно встраивает их в процессы разработки и эксплуатации.

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

• DevSecOps интегрирует безопасность в:

  • Архитектурный проект
  • Реализация приложения
  • Автоматизация инфраструктуры
  • Развертывание и операционные процессы

Benefits

DevSecOps позволяет группам разработчиков, безопасности и операций выполнять следующие действия:

• Определите и исправьте проблемы, возникающие ранее в жизненном цикле.
• Уменьшение воздействия на рабочую среду.
• Поддержка скорости доставки при управлении рисками.

Безопасность становится частью создания и доставки программного обеспечения, а не элемента управления, примененного после доставки.

Безопасный жизненный цикл инноваций

Инновации обычно выполняются на двух этапах жизненного цикла:

Этап	Сведения
Инкубация идеи	Функциональная возможность спроектирована, реализована и валидирована для первоначального использования в промышленной эксплуатации. Начинается с новой идеи
Первый выпуск	Первый производственный выпуск соответствует минимальным критериям продукта для безопасного использования продукта. - Разработка: функциональные возможности соответствуют минимальным бизнес-требованиям. - Безопасность: возможности соответствуют нормативным требованиям, требованиям безопасности и безопасности для использования в рабочей среде. - Эксплуатация: Функциональность соответствует минимальным требованиям к качеству, производительности и сопровождаемости, необходимым для использования в промышленной среде.

После первоначального выпуска разработка становится итеративной по мере развития рабочих нагрузок:

• Изменение допустимости рисков
• Требования к приложению и зрелость
• Нормативные обязательства
• Условия угрозы

Интеграция безопасности в разработку

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

• Сложность уязвимостей
• Затраты на исправление
• Операционные задержки и нарушения
• Повышение риска активной эксплуатации

DevSecOps постоянно интегрирует безопасность во время разработки и операций, чтобы устранить проблемы ранее, уменьшить риск и повысить согласованность.

Основные методики

Безопасность должна быть внедрена в существующие процессы разработки, чтобы быть эффективными, масштабируемыми и устойчивыми. Он должен быть интегрирован непосредственно в способ разработки, сборки, развертывания и эксплуатации приложений, а не реализации в отдельном или параллельном рабочем процессе. Мы рекомендуем:

• Описание сквозных рабочих процессов — от идеи до разработки, развертывания и дальнейшей эксплуатации.
• Определение четких ролей, средств и обязанностей по обеспечению безопасности на каждом этапе жизненного цикла.
• Создание согласованных путей исправления для уязвимостей, дефектов и проблем проектирования.

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

Как минимум, убедитесь, что вы:

• Определите этапы, люди и технологии, участвующие в жизненном цикле разработки.
• Определите, как действия безопасности интегрируются в каждый этап, а не рассматривать их как отдельные контрольные точки.
• Создайте процессы для обработки основных изменений и стандартных исправлений на протяжении всего жизненного цикла.

Автоматизация безопасности в разработке и развертывании

Автоматизация имеет важное значение для обеспечения согласованной безопасности и масштабирования в разных средах разработки и операций.

• Интегрируйте средства контроля безопасности и инструменты прямо в конвейеры CI/CD.
• Автоматизация ключевых действий, таких как моделирование угроз, сканирование кода, проверка и применение политик.
• Используйте подход «инфраструктура как код» (IaC), чтобы обеспечить воспроизводимые и безопасные развертывания.

Базовые элементы платформы, такие как целевые зоны Azure, могут поддерживать этот подход за счёт

Платформенные основы, такие как Azure целевые зоны могут поддерживать этот подход, предоставляя стандартные шаблоны для интеграции с безопасностью, управлением и DevOps.

Ожидаемые результаты

Организации, которые переходят с DevOps на DevSecOps, могут:

• Снижение вероятности появления уязвимостей в рабочих нагрузках
• Ограничение возможности злоумышленников использовать инфраструктуру разработки или автоматизацию
• Повышение устойчивости приложений к изменяющимся методам атак
• Поддержка нормативных требований и требований к соответствию организации
• Обеспечение скорости инноваций без увеличения операционного или риска безопасности

Советы по навигации по пути

Для внедрения DevSecOps требуются организационные и культурные изменения.

Изменения в области образования и культуры

Это критически важные ранние шаги. Ваша команда должна развивать новые навыки и принимать новые подходы, чтобы понять модель DevSecOps.

Перемены в образовании и культуре требуют времени, целенаправленных усилий, поддержки со стороны руководства и регулярного сопровождения, чтобы помочь людям в полной мере понять и увидеть ценность этих изменений.

Изменение культуры и навыков резко может иногда касаться профессиональной личности людей, создавая потенциал для сильного сопротивления. Важно понять и выразить причину, что и как изменить для каждого человека и их ситуации.

Изменение занимает время

Вы можете двигаться вперёд лишь с той скоростью, с которой ваша команда способна адаптироваться к последствиям новых подходов к работе. Команды должны выполнять свои существующие задания во время их преобразования.

Важно тщательно определить приоритеты наиболее важных и управлять ожиданиями того, как быстро это изменение может произойти.

Сосредоточение на поэтапной стратегии, при которой наиболее важные и базовые элементы внедряются в первую очередь, пойдет на пользу вашей организации.

Изменение вводит (временное) трение

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

Ограниченные ресурсы

Задача, с которой организации обычно сталкиваются на раннем этапе, заключается в поиске талантов и навыков в области безопасности и разработки приложений.

По мере того как организации начинают работать более эффективно, они могут найти скрытые таланты, такие как разработчики с учетом безопасности или специалистов по безопасности с опытом разработки.

Текущие смены

Приложения меняются быстро. Помимо новых функций, техническое определение и состав приложения существенно меняется при внедрении таких технологий, как облачные, бессерверные и ИИ.

Этот сдвиг меняет методики разработки, безопасность приложений и даже позволяет неразвитым пользователям создавать приложения.

Рассмотрим модель SRE

Некоторые реализации DevSecOps объединяют операции и обязанности безопасности в роль инженера надежности сайта (SRE ).

Хотя такая модель может работать, это часто крайнее изменение существующей корпоративной культуры и практики.

Если вы рассматриваете модель SRE, мы рекомендуем начать с внедрения безопасности в DevOps с помощью практических быстрых побед и добавочного прогресса, описанных в этом руководстве, чтобы обеспечить хорошую отдачу от инвестиций (ROI) и удовлетворения непосредственных потребностей.

Это постепенно возлагает обязанности в области безопасности на сотрудников, отвечающих за эксплуатацию и разработку, что приближает команды к целевому состоянию SRE.

Дальнейшие действия

Узнайте о рекомендациях по безопасной разработке.