devsecops что это такое

Консалтинговые услуги DevSecOps

Философия интеграции методов безопасности в процесс DevOps

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

Несмотря на огромную популярность, одного DevOps недостаточно в случаях, требующих безопасной доставки кода. Это привело к развитию нового подхода (известного, как DevSecOps), интегрирующего методы безопасности с DevOps.

В чем необходимость DevSecOps?

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

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

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

Различия между DevOps и DevSecOps

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

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

Что такое DevSecOps?

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

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

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

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

В среде IT нет единогласного мнения по поводу названия DevSecOps, иногда вы можете встретить DevOpsSec, SecDevOps или Rugged DevOps.

Основные компоненты DevSecOps

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

На практике подход DevSecOps включает в себя шесть основных компонентов:

Внедрение стратегии DevSecOps

Переход от DevOps к DevSecOps — не самая простая задача, но вполне выполнимая при наличии хорошего плана действий.

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

Основные инструменты DevSecOps

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

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

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

DevSecOps — главный приоритет бизнеса

Элемент безопасности в DevOps — это не исключительно технический инструмент, он также включает деятельность людей и отлаженное функционирование всех процессов. Наряду с укреплением безопасности, успешное внедрение DevSecOps подразумевает анализ всех возможных бизнес-рисков. Ожидается, что в глобальном масштабе рынок DevSecOps вырастет на 33.7% в период с 2017 до 2023 года.

Сервисы DevSecOps обеспечивают не только безопасную, но и значительно более быструю доставку приложений.

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

Влияние DevSecOps на бизнес в цифрах

Как внедрить DevSecOps?

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

5 признаков успешной реализации DevSecOps:

Бизнес-преимущества DevSecOps

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

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

Некоторые дополнительные преимущества также являются результатом внедрения DevSecOps, например:

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

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

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

Источник

От малого до энтерпрайза: коллекция статей по DevSecOps

Споры на тему «DevOps — это человек или методология?» уже неактуальны: всем надоело. Зато появился DevSecOps. И хотя термин не нов (первая конференция DevSecOps Summit прошла в 2016 году), его точное содержание бывает не до конца понятно и новичкам, и бывалым айтишникам.

Если за бывалых мы не волнуемся (разберутся сами), то новичкам нужен вводный курс. Поэтому я, DevOps-инженер Сергей Печенко (@tnt4brain), собрал коллекцию статей. Поговорим о том, что такое DevSecOps, какие инструменты существуют для внедрения этой методологии на уровне команды, а затем и на уровне компании.

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

Для нас внедрение DevSecOps стало естественным процессом — DevSecOps-практики пришли с развитием DevOps в компании, и мы растём синхронно с остальными направлениями. Ведь нельзя просто взять и перейти на DevSecOps независимо от других процессов: разработка и DevOps тоже эволюционируют.

Особенность неклассической парадигмы: если из набора «DevOps, разработка, DevSecOps» затормозилось что-то одно, то два других направления тоже застрянут.

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

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

Рекомендую книги, которые погружают в тему DevSecOps и описывают важные процессы современной разработки:

— Мирко Херинг, «DevOps для современного предприятия». Книга интересно описывает полезные процессы и практики DevOps, поможет взглянуть на ваш проект по-новому. В ней описывается вся важность выстраивания процессов.

— Крис Ричардсон, «Микросервисы. Паттерны разработки и рефакторинга». Если вы разрабатываете микросервисы, эта книга для вас. Автор рассказывает о важных паттернах разработки и архитектуры современных микросервисных решений. Важно, что Крис Ричардсон показывает красивые варианты решения весьма сложных задач.

— Серия книг «DevOps Toolkit» от Viktor Farcic поможет построить качественные пайплайны непрерывной интеграции и доставки. Рекомендую читать самую свежую версию — первые издания несколько устарели. Помимо книг, автор ведёт полезный YouTube-канал.

Источник

Какая разница между DevOps и DevSecOps?

DevOps – это методология, нацеленная на взаимодействие программистов и системных администраторов, которые в тесном взаимодействии разрабатывают продукт. DevOps engineer — специалист, который работает на стыке этих двух должностей. Основная цель работы DevOps инженера — максимально увеличить предсказуемость, эффективность и безопасность разработки ПО. DevSecOps – развитие концепции DevOps, где помимо автоматизации затрагиваются вопросы обеспечения качества и надёжности кода.

Методология DevOps

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

Методология DevOps включает в себя:

Что из себя представляет DevOps engineer

Так как профессия появилась совсем недавно, в конце 00-х годов, какого-то точного определения для этой профессии не устоялось. Можно его сформулировать так: DevOps-engineer – это человек, который занимается внедрением методологии DevOps.

Есть несколько вещей, с которыми должен быть знаком DevOps-engineer:

Далее обсудим тот вопрос, с которого мы начали эту заметку.

DevSecOps: что это и в чем отличие от DevOps

В основе подхода DevOps плотно закрепилась автоматизация. DevSecOps тоже стремится автоматизировать все, в том числе и аудит безопасности.

Для того, чтобы стимулировать внедрение DevSecOps, компания Cloud Security Alliance выделила шесть категорий, на которые следует обратить внимание.

Практические шаги трансформации DevOps в DevSecOps

Трансформация DevOps в DevSecOps требует понимания определенных технологий и методов обеспечения безопасности программ. Остановимся на этом моменте подробнее и посмотрим, какие конкретно технологии нам тут пригодятся.

Для начала предлагаю рассмотреть возможность встраивания средств динамического тестирования безопасности приложений, DAST. Динамические анализаторы программного кода позволяют выявлять уязвимости в коде, например, SQL-инъекции, переполнение буфера и подобные, методом черного ящика. Использование динамических анализаторов при разработке позволит сделать шаг навстречу DevSecOps практикам.

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

Интерактивное тестирование безопасности приложений, IAST. Технология IAST анализирует приложение изнутри во время его работы. IAST отслеживает выполнение кода в памяти и ищет конкретные события, которые могут привести к уязвимости. Далее эти события анализируются с целью проверить, все ли с ними хорошо и не закралась ли какая-либо уязвимость.

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

Заключение

Подытожим, что же у нас в итоге получилось.

DevSecOps – это способ интегрировать задачи безопасности в методологию DevOps. Вопросы автоматизации безопасности в DevOps – это та вещь, которая требует новых подходов, технологий и инструментов. DevSecOps можно считать продолжением методологии DevOps, так как DevSecOps основан на методологии последних. Чтобы ознакомиться подробнее, предлагаю следующие ссылки:

Источник

Кому и для чего нужен DevSecOps?

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

Введение

Аналитический центр Anti-Malware.ru начал новую серию онлайн-конференций, посвящённую разработке безопасного программного обеспечения. В рамках проекта AM Live запланирован ряд эфиров, в которых эксперты обсудят сущность Security Development Lifecycle (SDL) и то, как он превратился в DevSecOps, расскажут о практической реализации технологии безопасной разработки. В рамках первой беседы, состоявшейся 3 февраля 2021 года, гости нашей студии обсудили базовые вопросы методологии безопасной разработки, обозначили первые шаги, необходимые для внедрения DevSecOps, оценили этот сектор отечественного рынка и дали прогнозы по его развитию.

В дискуссии приняли участие:

Модератор прямого эфира: Андрей Бешков, руководитель направления развития бизнеса компании Softline.

Как возникла концепция DevSecOps

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

Денис Ремчуков пояснил, что в ИТ-отрасли существует три исторически конфликтующих между собой сферы: разработка, эксплуатация и безопасность. Разработчики заинтересованы в скорейшем создании продукта и сдаче его в эксплуатацию, а администраторы, отвечающие за эксплуатацию системы, наибольшее значение придают её стабильности. Методология DevOps была призвана сгладить эти противоречия — в инструменты разработки были добавлены средства тестирования, программисты и администраторы наладили обмен информацией, а также договорились о ключевых показателях, свидетельствующих о работоспособности кода. Другими словами, они сформировали единое пространство разработки и эксплуатации с общей зоной ответственности за конечный результат.

Служба информационной безопасности в процессе DevOps выступает как третья сторона, которая выдвигает свои требования и зачастую конфликтует и с разработкой, и с эксплуатацией. DevSecOps нужна для того, чтобы устранить противостояние и включить ИБ в общее информационное поле создания и эксплуатации системы. Цели такой практики — ускорить разработку и внедрение, а также снизить количество случаев возврата кода на доработку.

Михаил Кондрашин добавил, что концепцию SDL упрощённо можно представить в виде интеграции ИБ-специалистов во все этапы разработки системы. DevOps и DevSecOps призваны минимизировать цену ошибки программиста и ускорить процесс разработки инновационных систем. Если в коде есть недостаток, он с большой вероятностью будет найден на этапе эксплуатационного или ИБ-тестирования и быстро исправлен.

Антон Гаврилов назвал четыре столпа DevOps: культура, автоматизация, обмен опытом, метрики.

Вслед за обсуждением путей возникновения методологии DevSecOps среди экспертов развернулась оживлённая дискуссия о том, кто должен отвечать за безопасность разработки в компании. Мы задали такой же вопрос зрителям прямого эфира и узнали, что в 30 % случаев эта функция разделена в организациях между разработчиками и специалистами по информационной безопасности. В компаниях 26 % респондентов за безопасность разработки отвечает ИБ, а 20 % ответивших считают, что это входит в сферу интересов разработчиков. Только у 1 % организаций безопасность разработки отдана на аутсорсинг. Затруднились ответить на этот вопрос 23 % зрителей онлайн-конференции.

Рисунок 1. Кто в вашей компании отвечает за безопасность разработки?

Зачем компании DevSecOps

Далее эксперты онлайн-конференции затронули важную тему: что является движущей силой рынка безопасной разработки? Что заставляет компании внедрять эту методологию и какие существуют альтернативы для создания безопасного софта внутри компании?

Отвечая на последний вопрос, Денис Кораблев высказал мысль, что часть проблем, связанных с безопасностью приложений, могут снять решения класса Web Application Firewall (WAF), которые позволяют выпускать продукт с ещё непропатченной уязвимостью — её «закроет» файрвол. Вместе с тем, как точно подметил Андрей Аникин, WAF не избавляет от необходимости всё же решать проблему — исправлять уязвимость. Затраты на разработку системы не уменьшатся, однако передать её в эксплуатацию можно будет быстрее.

Спикеры указали, что риски могут стать движущей силой внедрения методов безопасной разработки. Стоимость одной и той же уязвимости может отличаться в зависимости от страны, сферы деятельности и размера компании. Ещё несколько лет назад для российских компаний риски утечки данных были не столь значимыми, как сейчас, однако проникновение ИТ в технологические и бизнес-процессы заставило многие организации пересмотреть подходы к разработке. Безопасность кода сейчас напрямую влияет на те сферы деятельности компании, которые связаны с генерацией прибыли. Как сказал Михаил Кондрашин, автоматизироваться начинает всё.

Более того, банки, страховые компании, службы такси, доставка продуктов и множество других бизнесов становятся полноценными ИТ-компаниями, в которых информационные системы играют ключевую роль. В рамках этой тенденции интерес к DevOps и его безопасности будет расти. Важно понимать, что драйвером развития DevSecOps сейчас является не «желание» разработчиков, администраторов и ИБ-специалистов найти общий язык, а совокупность насущных потребностей бизнеса.

Мы, в свою очередь, поинтересовались у зрителей прямого эфира тем, какие меры предпринимаются в их компаниях для безопасной разработки приложений. Оказалось, что в организациях 26 % наших респондентов этот процесс не налажен, а разработка и безопасность существуют в разных мирах. Столько же ответивших находятся на другом полюсе мнений — они разработали требования по ИБ к разработке софта, используют автоматизацию, устраняют дефекты и проводят обучение. Примерно треть опрошенных — 32 % — предпринимает первые шаги в DevSecOps: сканирует исходный код, устраняет дефекты. Ещё 16 % участников опроса используют более трёх инструментов для повышения защищённости кода.

Рисунок 2. Какие меры вы принимаете для безопасной разработки приложений?

Нужны ли рынку специалисты по DevSecOps

Зрители прямого эфира онлайн-конференции AM Live спросили экспертов о том, какие навыки нужны для того, чтобы перейти в DevSecOps, и востребованны ли такие специалисты на рынке. Автор другого вопроса хотел узнать, имеет ли смысл заниматься безопасностью разработки человеку в возрасте 35 лет и старше.

Как пояснили наши гости, DevSecOps начинается тогда, когда в компании появляется человек, который за это отвечает. Поэтому такие сотрудники будут востребованны на рынке в ближайшее время. Заниматься DevSecOps «после 35» весьма перспективно, поскольку такой специалист должен иметь бэкграунд и в разработке, и в информационной безопасности, а также определённые коммуникативные навыки. «Вилка» зарплат специалиста по DevSecOps согласно статистике HH.ru лежит в пределах от 250 до 350 тыс. рублей.

Как обосновать бизнесу необходимость DevSecOps

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

Денис Ремчуков: сокращение сроков разработки за счёт уменьшения количества кода, возвращаемого на доработку, а значит, меньшая стоимость разработки.

Денис Кораблев: аргументы зависят от того, кому «продаёшь» DevSecOps. Руководителю уровня CIS можно напомнить о возможных уязвимостях в «самописных» системах, которые есть почти в каждой крупной организации. Для топ-менеджеров большее значение будет иметь риск убытков, например от утечки информации через корпоративный веб-ресурс.

Андрей Аникин: DevSecOps легко продавать после инцидента — когда обнаружено несоответствие, произошла утечка данных или иное ИБ-событие, которое повлекло за собой потери для бизнеса. Однако если ничего не происходит, убедить руководство бывает сложно.

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

С чего начинать внедрение DevSecOps

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

По мнению Алексея Кузнецова, необходимо сначала оценить риски, после чего определить наиболее эффективный инструмент контроля безопасности разработки. Михаил Кондрашов высказал идею, что в случае обнаружения уязвимости нет необходимости искать конкретного виновного — нужно просто добавить в систему разработки инструменты, которые предотвратят возникновение подобных ошибок в будущем. Что касается конкретных шагов, то их должен определить специалист, отвечающий в компании за DevSecOps. Если такового нет, то первым шагом его следует нанять. Как подметил Денис Ремчуков, безопасность — это не результат, а процесс.

Антон Гаврилов отметил, что для автоматизации контроля безопасности разработки имеет смысл обратить внимание на опенсорс-решения. Это даст возможность «примерить» инструментарий DevSecOps без дополнительных затрат. Однако другие спикеры возразили эксперту, что большего эффекта можно достичь взяв тестовую версию коммерческого софта.

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

Рассуждая на тему того, какой инструмент DevSecOps стоит внедрить в первую очередь, эксперты сошлись во мнении, что это должен быть сканер исходного кода, который будет отсекать часть недостатков. Ещё один полезный инструмент — решение класса Software Composition Analysis (SCA), которое позволит оценить уязвимость сторонних библиотек и других заимствованных элементов системы. При этом не нужно переоценивать значение средств автоматизации: важнейшая часть внедрения методологии безопасной разработки — это работа с сотрудниками, повышение их вовлечённости в проект.

Зрители онлайн-конференции в ответах на вопрос «Какой элемент DevSecOps наиболее важен для вашей компании?» указали, что наибольшее значение имеет анализ исходного кода. Такой вариант выбрали 35 % участников опроса. Ещё 17 % считают самым важным элементом DevSecOps аудит безопасности, а 12 % — тестирование на проникновение. Варианты «Проверка скомпилированных версий» и «Threat Intelligence» набрали 7 % и 5 % соответственно. Оставшиеся 23 % респондентов считают наиболее важной другую составную часть процесса обеспечения безопасности разработки.

Рисунок 3. Какой элемент DevSecOps наиболее важен для вашей компании?

Как проверить безопасность опенсорс-библиотек

Одним из важных вопросов создания безопасного продукта является контроль качества библиотек с открытым исходным кодом, входящих в его состав. По разным оценкам доля стороннего кода в специализированных, нетиповых разработках может достигать 80 %, поэтому анализ этих элементов на наличие уязвимостей является обязательной частью DevSecOps. Это — весьма сложный процесс, иногда предполагающий ручную обработку полученных данных: ведь в большом проекте могут использоваться несколько версий одной и той же библиотеки.

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

Что же касается зрителей, наблюдавших за прямым эфиром AM Live, то на вопрос «Проводите ли вы аудит безопасности опенсорсных пакетов?» 34 % ответили утвердительно. Примерно столько же — 36 % — не анализируют безопасность сторонних библиотек. Оставшиеся 30 % не обладают информацией по этому вопросу.

Рисунок 4. Проводите ли вы аудит безопасности опенсорсных пакетов?

Выводы

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

Михаил Кондрашин считает, что с точки зрения разработки приложений российский рынок ничем не отличается от мирового. Если отечественный сектор DevSecOps попадёт в сферу внимания регуляторов, это сильно его изменит. Поскольку ИБ часто следует за ИТ, то перспективу роста рынка наш спикер видит в более активном использовании DevOps, за которым неизбежно последует развитие DevSecOps.

Антон Гаврилов добавил, что одной из интересных тенденций в этой сфере является синергия DevSecOps и облака. В России на данный момент такое явление — редкость, однако эксперт надеется, что развитие отечественных облачных провайдеров даст ему импульс в будущем.

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

Денис Кораблев подчеркнул, что на отечественном рынке существует заметный разрыв между компаниями, которые используют DevSecOps, и предприятиями, готовыми тратить на него деньги. Отечественные заказчики DevSecOps, обладающие бюджетом, существенно отличаются от западных. Зачастую в российских компаниях взаимодействие специалистов по информационной безопасности с разработчиками налажено слабо, методологии выбора специализированных программ не существует. Эксперт выразил надежду, что в будущем разрыв между отечественными и зарубежными компаниями в этой сфере будет сокращён.

Андрей Акинин выразил уверенность, что по мере роста российского бизнеса и повсеместной цифровизации будет увеличиваться спрос и на безопасность. Как только компания переносит значимые для неё активы в цифровое пространство, немедленно возникает вопрос об информационной безопасности.

Андрей Бешков отметил, что рост средств автоматизации процесса разработки, в том числе облачных решений, может снизить спрос на специалистов в сфере DevSecOps, однако эксперты в студии не согласились с ним. По мнению спикеров конференции, в будущем возможна смена специализации таких сотрудников — с большим акцентом на облачные технологии.

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

В рамках проекта AM Live мы обязательно вернёмся к теме DevSecOps и обсудим с экспертами вопросы реагирования на инциденты, интеграцию различных инструментов, поговорим о сохранении целостности цепочки безопасной разработки и других темах. Чтобы не пропустить новые материалы, подписывайтесь на наш YouTube-канал и включайте уведомления о новых публикациях.

Источник