Игорь Никифоров о DevSecOps как культуре и образе мышления – «Внедрение идей DevSecOps непростая задача, но они того стоят».
С развитием различных подходов и появлением новых методов разработки программного обеспечения, направленных на увеличение скорости и сокращение длительности всех этапов жизненного цикла, вопрос обеспечения безопасности становится всё более актуальным. Уязвимость ПО не только несёт для разработчиков репутационные риски, но и может привести к серьёзным финансовым потерям и юридическим последствиям. Именно поэтому для современных ИТ-команд задача безопасности является одной из наиболее актуальных. Минимизировать угрозы и наладить стабильные релизы без потери скорости помогает подход DevSecOps, основанный на принципах автоматизации, ответственности и сотрудничества. Подробнее о нём и том, как и кому с его помощью удаётся автоматизировать интеграцию задач безопасности, CNews рассказал Игорь Никифоров, ИТ-эксперт и ведущий Devops инженер в компании BostonGene.
CNews: В самом подходе DevOps уже были заложены моменты связанные с безопасностью. Является ли DevSecOps закономерным развитием этого подхода и каким компаниям стоит уже задумываться об его использовании?
Игорь Никифоров: Да, прежде всего DevSecOps стоит рассматривать как ещё один логичный виток в развитии подходов к обеспечению безопасности в ходе разработки программного обеспечения. Главное его отличие от DevOps состоит в том, что здесь эта задача становится основной надстройкой над всем процессом разработки ПО.
На самом деле существует несколько вариаций термина DevSecOps, где Sec возникает на разных этапах. Несмотря на то, что DevSecOps самый распространенный, возникновение Sec в середине процесса не совсем правильно, так как о безопасности нужно задумываться ещё на самых ранних стадиях проектирования той или иной функциональности, когда команда разработки работает совместно с командой ИБ. Как и в случае с DevOps, в DevSecOps процесс важнее конечных инструментов, они, как и все остальное, могут меняться или улучшаться с течением времени.
Говоря о компаниях, стоит отметить, что стартапы, скорее всего, не смогут позволить себе такой процесс, поскольку он требует значительных ресурсов, не только временных, но и человеческих. Компания так же должна достаточно созреть, для того чтобы начать использовать Sec в DevOps, т.е. прежде всего иметь устоявшиеся процессы DevOps, только если вопросы безопасности изначально не диктуются отраслью или особенностью бизнеса.
CNews: Какие преимущества можно выделить в DevSecOps?
Игорь Никифоров: Первое, что я бы отметил, это, конечно, рост скорости разработки, а также безопасность и качество самого кода. Вообще весь смысл DevSecOps сводится к тому, чтобы, в первую очередь, сформировать образ мышления, при котором каждый участник процесса несет ответственность за безопасность. Так как при разработке в среде, не использующей принципы DevSecOps, проблемы с безопасностью могут привести к огромным временным потерям, а исправление таких проблем в коде постфактум может стоить не только временных, но и значительных финансовых затрат. Именно поэтому быстрая и безопасная доставка ПО в соответствии с принципами DevSecOps позволяет сократить временные и денежные затраты, тем самым минимизируя потребность в устранении проблем с безопасностью на последних этапах разработки, а интеграция задач, связанных с безопасностью, исключает необходимость повторных проверок и сборок приложений, тем самым значительно повышая безопасность и качество кода.
Вторым преимуществом является тот факт, что такие процессы как аудит, сканирование и тестирование кода на безопасность проводятся на каждом этапе цикла разработки. Это способствует устранению проблем безопасности сразу после их обнаружения, что исключает появление новых уязвимостей. Такой процесс помогает более эффективно налаживать взаимодействие между отделами разработки, эксплуатации и безопасности, что помогает организации намного оперативнее реагировать на инциденты. А поскольку DevSecOps интегрирует свои задачи на ранних этапах разработки, то исчезает необходимость вручную искать и исправлять общеизвестные уязвимости (CVE), что сильно ограничивает потенциальных злоумышленников по использованию уязвимостей в продуктивных окружениях.
В-третьих, DevSecOps позволяет интегрировать свои процессы в существующий конвейер CI/CD, так как тестирование безопасности можно довольно легко интегрировать в наборы автоматических тестов, но степень автоматизации этих процессов, конечно, во многом будет зависеть от проекта. Сама автоматизация тестирования позволяет включить зависимости приложения в подходящие уровни исправлений, чтобы точно быть уверенным в том, что оно успешно прошло этап модульного тестирования безопасности. Ну и наконец, для тестирования и защиты кода могут применяться методы статического (SAST) и динамического анализа (DAST) до того, как приложение будет развёрнуто в продуктивной среде.
CNews: Не секрет, что скорость разработки ПО и сокращения TTM (Time to market) возрастает с каждым днём. Какие инструменты и технологии могут помочь в обеспечении безопасности современных приложений?
Игорь Никифоров: Безусловно, трансформация DevOps в DevSecOps требует понимания определённых технологий и методов обеспечения безопасности приложений. При этом стоит отметить, что традиционные инструменты сканирования безопасности не очень подходят для автоматизации в задачах CI/CD, но вместе с этим на рынке достаточно много инструментов, заточенных именно на такую интеграцию.
Первое, что я бы я хотел выделить, – это SAST или статистический анализ, который позволяет анализировать код на наличие известных уязвимостей. Поскольку статический анализ кода выполняется для исходного кода приложения, его можно запускать на ранних стадиях конвейера CI/CD, т.е. сразу после внесения изменений. Стоит отметить, что инструменты SAST привязаны непосредственно к языку, и один из основных плюсов, который нужно выделить, это поиск и выявление уязвимостей в коде на раннем этапе разработки, т.е. когда ещё нет не только стенда, но и самого приложения или отдельного разрабатываемого функционала. Также можно упомянуть и возможность инкрементального сканирования, при котором сканируется именно тот участок кода, который изменился, что уменьшает время сканирования. Но нужно иметь в виду, что инструменты SAST довольно часто могут вызывать ложноположительные уведомления, так что здесь крайне важно правильно их настраивать.
Вслед за SAST появилось и динамическое тестирование безопасности приложений – DAST. Это, наверное, самая интересная часть инструментария, так как она довольно сильно отличаются от SAST. По сути, это имитация работы пользователя с приложением. Например, если это веб-приложение, то вы можете отправить запросы, имитируя работу пользователя, нажимать различные кнопки или заполнять формы, используя какие-то подготовленные данные, чтобы проверить, как приложение их обрабатывает. Также с помощью метода чёрного ящика DAST позволяет проверять различные шаблонные уязвимости и анализировать ответы сервера, например, переполнение буфера, SQL-инъекции и подобные. Стоит учитывать, что запуск таких тестов стоит проводить только на изолированном и специально выделенном для подобных тестов окружении, так как в результате запуска тестов могут случиться довольно неприятные вещи, такие как высокая нагрузка на приложение или сеть, изменение данных или даже полная поломка работы приложения. Инструменты DAST работают с уже собранным и развернутым приложением, поэтому обычно они используются на более поздних стадиях конвейера CI/CD.
CNews: Насколько быстро можно внедрить DevSecOps, и какие основные сложности возникают при его внедрении?
Игорь Никифоров: DevSecOps однозначно требует терпения и упорства, так как почти любая его полноценная реализация занимает минимум год. Потребуется уделить достаточно много времени не только планированию и проектированию, но и определению пробелов в текущем процессе, а также для исследования инструментов: от их функционала, до возможности интеграции с системой CI/CD.
Именно поэтому подход к этому процессу должен быть комплексным – процессы сканирования должны быть встроены в конвейер CI/CD и, что немаловажно, настроены правила безопасности, которые блокируют дальнейшую сборку в случае обнаружения уязвимостей. При этом трудоемкость самого внедрения инструментов DevSecOps в конвейер CI/CD зависит во многом от масштаба проекта, готовности инфраструктуры и, что самое важное, квалификации инженеров и желания самих разработчиков использовать внедряемые инструменты. Эти инструменты должны быть не только удобными, но и легко интегрируемыми в ваш конвейер CI/CD. Именно на этом этапе часто возникает достаточно много сложностей, так как существующие в компании инструменты могут попросту не справляться с поставленным задачами. Например, достаточно часто в компаниях начинают внедрение процессов CI/CD с Jenkins, потому что он популярный и бесплатный, но количество ошибок как в нём, так и в его плагинах может быть огромным, к тому же зачастую эти плагины могут просто больше не поддерживаться. Это приводит к необходимости искать разного рода обходные пути и тратить на это значительное время. Тут следует помнить, что не все инструменты обладают достаточной зрелостью, чтобы полностью покрыть все потребности.
Еще одна проблема связана с тем, что не во всех компаниях есть единый CI инструмент, под который можно будет легко написать шаблоны для различных инструментов ИБ (SAST, DAST и пр.). Обычная ситуация, когда в компании применяются сразу несколько различных решений, например, Jenkins и GitLab, которые используются или разными командами под конкретные проекты или, что ещё хуже, под разные задачи применяется свой инструмент. В этом случае сложность встраивания процессов ИБ в такой конвейер может значительно возрасти. Более того, разработчики могут просто не встраивать шаги безопасности в свой процесс или просто отключить, и у команды ИБ не останется механизмов, которые помогут контролировать и быстро выявить такую ситуацию. Другой момент связан с тем, что все ИБ инструменты имеют свой собственный процесс по работе с уязвимостями. Более того, какие-то инструменты имеют UI, для каких-то нужно проставлять комментарии в Git, а для остальных используются собственные консольные утилиты. Ну и более классическая проблема, когда специалист по ИБ один, а команд разработки может быть несколько. В результате это выливается в то, что процесс замыкается на ИБ.
Еще одна сложность связана с поддержкой устаревших (legacy) приложений. Они могут иметь критическое значение для компании, потому что поддерживают какой-то важный функционал, но, поскольку они были написаны давно, никто не может или не хочет вносить какие-либо изменения. Несмотря на это, такие приложения по-прежнему должны регулярно проверяться командой ИБ.
Тут так же стоит добавить, что DevSecOps может не быть приоритетным в компании. Так, в некоторых случаях, могут отсутствовать возможности интегрировать процессы безопасности в существующие процессы DevOps, потому что для этого требуется различные изменения в существующих скриптах или устоявшихся процессах, на что у команды может не быть времени из-за других приоритетов.
CNews: С какими самыми распространенными проблемами сталкиваются специалисты по ИБ при применении безопасной разработки, и как их можно решить?
Игорь Никифоров: На мой взгляд, самая распространенная проблема — это то, что безопасность чаще всего ближе к эксплуатации. Зачастую она располагается где-то между развертыванием самого приложения и его эксплуатацией. Простой пример, специалист по ИБ просит провести тестирование на проникновение, по результатам которого идентифицируется перечень уязвимостей, подлежащих устранению. Этот момент чаще всего вызывает негодование у команды разработки, так как полный цикл релиза уже пройден. Кроме тех разногласий с командой разработки, которые я уже отмечал ранее, это также приводит к увеличению стоимости ПО, потому что на последующее исправление тратится время и разработки, и команды ИБ.
Именно этот момент призван исправить DevSecOps, который реализует принцип «сдвиг влево» (Shift left). Он помогает команде разработки переместить задачи безопасности с конца (т.е. справа), в начало (т.е. в левую часть). В этом случае команду ИБ привлекают к разработке ПО еще на стадии проектирования. Она является активным участником процесса и отвечает за проектирование приложения и сбор функциональных требований. Их задача — убедиться в том, что каждый компонент и элемент конфигурации в стеке исправлен, настроен согласно требованиям безопасности и задокументирован.
Далее команде ИБ нужно определить точки контроля информационной безопасности (security gates), которые встраиваются в конвейер CI/CD. На этом этапе очень важен диалог с командой разработки, потому что если повсюду встроить безопасность, то можно получить огромное количество данных, которые необходимо проанализировать для принятия решения. Но это может быть не всегда нужно, так как помимо прочего такой процесс требует больших затрат человеческих ресурсов.
CNews: Нужен ли DevSecOps как отдельный человек в компании, и кто может им стать?
Игорь Никифоров: Прежде всего я бы посоветовал обратить внимание на имеющихся специалистов. Самый оптимальный способ – это найти человека их команды разработки, которому интересна информационная безопасность. Значительную часть времени необходимо будет потратить на обучение, например, рассказать про требования в области ИБ, которая применима при разработке ПО, при необходимости провести общий курс по информационной безопасности, научить пользоваться всеми необходимыми инструментами (SAST, DAST и т.д.). Так разработчик сможет понять, как автоматизировать свои процессы с точки зрения ИБ.
Основная цель – не только сформировать понимание важности обеспечения информационной безопасности у разработчика, но и предоставить ему возможности для реализации поставленных задач. Он должен уметь хорошо разбираться в вопросах безопасности, и при этом донести своё видение процессов до всех команд, которые участвуют в процессе разработки, т.е. выступать своего рода идеологом подхода.
Игорь Никифоров отмечает, что несмотря на все преимущества подходов безопасной разработки, многие компании, как и когда-то в случае с DevOps, все еще сомневаются в принятии DevSecOps, так как его идеи также требуют изменений в способе мышления. DevSecOps – это не только инструменты и процессы, которые помогают осуществлять быструю доставку ПО, а в первую очередь, культура. Вот почему для того чтобы включить вопросы безопасности в цикл разработки ПО, крайне важно создать культуру разделения ответственности. В такой среде у каждого должна быть возможность высказаться по вопросам безопасности, а также сыграть свою роль в ее реализации. Внедрение идей DevSecOps непростая задача, но они того стоят.
Источник: CNews
Новости
Смотреть все →