Хотя подход DevOps к поставке программного обеспечения положительно изменил ИТ-индустрию, требования безопасности в значительной степени остались без внимания. Это то, что DevSecOps стремится исправить.
DevSecOps — одна из самых важных тенденций DevOps начиная с 2018 года . Это подход к безопасности ИТ-операций, позволяющий использовать принципы и лучшие практики DevOps для обеспечения лучшей, быстрой и более безопасной доставки программного обеспечения. По сути, это означает, что все требования безопасности с самого начала кодифицированы и включены в автоматизированные модульные тесты вместо того, чтобы иметь дело с ними перед выпуском продукта.
DevSecOps — это тенденция автоматизировать все проверки безопасности, кодифицируя их в модульных тестах и используя их с самого начала разработки программного обеспечения, а не в конце цикла.
Чем он отличается от DevOps? Это на самом деле одно и то же, единственное, что DevOps цель состоит в том, чтобы поставлять программное обеспечение настолько надежно и часто, насколько это необходимо, не говоря уже об обеспечении его стабильной работы в производственном процессе. С DevSecOps требования безопасности просто добавляются, но общий рабочий процесс не меняется. Как это может быть сделано?
Вот 6 шагов к DevSecOps.
Они не легкие и не простые, но они помогают выполнить работу:
- Аудит существующей ИТ-инфраструктуры и устранение недостатков
- Автоматизируйте тестирование безопасности
- Постоянно проверяйте зависимости кода
- Разбейте проверки на управляемые куски
- Интеграция с другими инструментами DevOps имеет решающее значение
- Постоянно обучайте своих разработчиков безопасному кодированию
Ниже мы кратко рассмотрим основные требования и проблемы на пути к DevSecOps.
Аудит существующей ИТ-инфраструктуры и устранение недостатков
Перед внедрением чего-то нового полезно определить ваше текущее состояние и текущие процессы. Проведение аудита существующей ИТ-инфраструктуры , систем и инструментов, процессов и практик на местах является в целом целесообразной идеей. Это еще более полезно, когда вы планируете изменить существующие процедуры безопасности и проверки.
Правильный способ оценить вашу инфраструктуру и ее проблемы — выполнить моделирование угроз — взгляните на свои системы с точки зрения злоумышленника и попытайтесь найти самые слабые места. Это позволяет разработать эффективные контрмеры для потенциальных нарушений безопасности, устранить узкие места в процессах или полностью устранить слабые цепи. Моделирование угроз не может быть автоматизировано, однако это чрезвычайно полезное упражнение, позволяющее вашим разработчикам высматривать потенциальные уязвимости безопасности и избегать создания новых точек нарушения кода продукта.
Автоматизируйте тестирование безопасности
Следующим шагом после выявления потенциальных проблем безопасности и разработки решений для них является систематизация этих решений, чтобы они стали частью автоматизированного модульного тестирования новых функций кода. Таким образом, требования безопасности выполняются с самого начала процесса разработки программного обеспечения, а не остаются последними перед выпуском. На самом деле, результаты опроса Sonatype по QA и автоматизации тестирования в 2017 году показывают, что почти 40% из более чем 2300 опрошенных специалистов по QA уже проводят автоматизированные тесты программного обеспечения по всем конвейерам доставки программного обеспечения. Ваша команда тоже это делает?
Тем не менее, эта автоматизация должна осуществляться с большой осторожностью. Во время выполнения статических тестов безопасности приложений ( SAST ) в средах тестирования и промежуточной среды убедитесь, что эти тесты выполняются только для последних дополнений к базе кода. В противном случае эти тесты будут слишком длительными для выполнения во время ночных развертываний и фактически замедлят, а не улучшат процесс доставки программного обеспечения.
Подумайте о внедрении методов динамического тестирования безопасности приложений ( DAST ) в свои рабочие процессы, если вы этого еще не сделали. Вместо проверки кода при разработке и тестировании, эта практика концентрируется на проверке работоспособности и производительности приложений, работающих в рабочей среде. OWASP предлагает огромный список уязвимостей приложений, и защиту вашего продукта от них — это, как правило, отличная практика. Такие инструменты, как Sonatype, Selenium, Splunk, InSpec, Tanium и другие, могут помочь вашей команде QA эффективно справиться с этим шагом.
Постоянно проверяйте зависимости кода
Переход на облачные технологии способствовал беспрецедентному росту разработки программного обеспечения, поскольку ИТ-индустрия смогла быстрее завершить проекты и быстро удовлетворить требования клиентов. Для дальнейшего расширения возможностей этого подхода использование программного обеспечения и модулей с открытым исходным кодом становится основным подходом к поставке программного обеспечения, поскольку разработка каждого модуля с нуля, по сути, является пустой тратой времени и ресурсов. Однако использование стороннего кода означает зависеть от его недостатков безопасности и уязвимостей.
GitHub представил оповещения о безопасности в 2017 году, поэтому каждый участник проекта получает уведомление об обновлении проекта, от которого он зависит. Другой способ сделать это — использовать инструмент проверки зависимостей OWASP (https://www.owasp.org/index.php/OWASP_Dependency_Check), который можно добавить в качестве плагина для большинства браузеров.
Разбейте проверки на управляемые куски
Самая большая проблема внедрения методов DevSecOps заключается в необходимости их постепенного внедрения. Список необходимых проверок может быть довольно длинным, но их быстрое выполнение будет очень сложной задачей для ваших разработчиков. Вместо этого, выполнение только нескольких проверок во время каждого из спринтов разработки продукта позволяет процессу быть намного более гладким и встречать меньшее сопротивление. По сути, это дает команде время для решения новых задач и включения их в повседневную рутину рабочих процессов доставки программного обеспечения.
Интеграция с другими инструментами DevOps имеет решающее значение
Для обеспечения эффективности выбранный инструмент интеграции безопасности должен хорошо работать с остальными инструментами DevOps, используемыми в вашей компании. Это позволяет беспрепятственно интегрировать проверки безопасности в конвейеры CI / CD для доставки программного обеспечения и решения для облачного мониторинга, используемые для поддержания производительности вашей производственной среды.
Лучший способ интеграции этих систем — через взаимодействия API, которые уменьшают объем конфигурации для каждого отдельного инструмента. Такие решения, как Splunk, Selenium и другие инструменты, имеют простую и понятную интеграцию с Kubernetes и Terraform , Jenkins и Ansible, стеком ELK, Prometheus + Grafana и другим популярным программным обеспечением DevOps.
Постоянно обучайте своих разработчиков безопасному кодированию
Давайте кратко рассмотрим прогресс на данный момент. Системный аудит завершен, и моделирование угроз помогло обнаружить и устранить потенциальные нарушения безопасности; автоматизированный контроль качества и тестирование на месте, а зависимости кода от сторонних модулей регулярно проверяются; проверки безопасности постепенно выполняются по всем конвейерам доставки программного обеспечения, а инструменты мониторинга безопасности интегрируются с другими частями вашего инструментария команды DevOps.
Кто-то может подумать, что мы приближаемся к финишу… и кто-то ошибся. Из-за того, что DevSecOps, как и любой другой процесс в цифровом преобразовании, является не разовым усилием, а долгосрочным путешествием и приверженностью компании. Таким образом, следующим этапом цикла является обеспечение того, чтобы разработчики постоянно использовали все вышеупомянутые инструменты и подходы, чтобы требования безопасности действительно учитывались с самого начала каждого проекта. Только когда следование этому рабочему процессу становится единственным возможным способом разработки нового программного обеспечения, вы можете быть уверены, что делаете DevSecOps правильно.
Заключительные мысли о DevSecOps
Таким образом, DevSecOps не является инструментом, методологией или проектом. Это тектонический сдвиг в бизнес-процессах и корпоративном отношении к культуре DevOps и сдвиг проверок безопасности влево на протяжении всего жизненного цикла доставки программного обеспечения. Это сложный и длительный процесс, но его преимущества весьма ощутимы — лучшее качество доставки программного обеспечения, более безопасные продукты, меньше проблем при производстве и снижение множества других рисков разработки программного обеспечения.
Как вы реализуете подход DevSecOps в вашей компании? Вы хотели бы нанять авторитетного поставщика управляемых услуг для этого? Если так — обращайтесь в ITFB , мы готовы помочь!