Методология разработки безопасных приложений вызывает множество вопросов у специалистов компаний, создающих и эксплуатирующих нетиповые, индивидуализированные решения. Мы поговорили с ведущими ИБ-экспертами о том, что такое DevSecOps, какие преимущества несёт этот подход и с какими сложностями сопряжено его внедрение в условиях отечественного рынка информационных технологий.
- Введение
- Как возникла концепция DevSecOps
- Зачем компании DevSecOps
- Нужны ли рынку специалисты по DevSecOps
- Как обосновать бизнесу необходимость DevSecOps
- С чего начинать внедрение DevSecOps
- Как проверить безопасность опенсорс-библиотек
- Выводы
Введение
Аналитический центр Anti-Malware.ru начал новую серию онлайн-конференций, посвящённую разработке безопасного программного обеспечения. В рамках проекта AM Live запланирован ряд эфиров, в которых эксперты обсудят сущность Security Development Lifecycle (SDL) и то, как он превратился в DevSecOps, расскажут о практической реализации технологии безопасной разработки. В рамках первой беседы, состоявшейся 3 февраля 2021 года, гости нашей студии обсудили базовые вопросы методологии безопасной разработки, обозначили первые шаги, необходимые для внедрения DevSecOps, оценили этот сектор отечественного рынка и дали прогнозы по его развитию.
В дискуссии приняли участие:
- Андрей Акинин, генеральный директор компании Web Control.
- Алексей Кузнецов, руководитель направления анализа защищённости компании BI.ZONE.
- Михаил Кондрашин, технический директор компании Trend Micro в СНГ, Грузии и Монголии.
- Антон Гаврилов, руководитель направления DevSecOps центра информационной безопасности компании «Инфосистемы Джет».
- Денис Ремчуков, независимый эксперт.
- Денис Кораблев, директор Positive Technologies по разработке продуктов по выявлению вредоносных объектов.
Модератор прямого эфира: Андрей Бешков, руководитель направления развития бизнеса компании 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-канал и включайте уведомления о новых публикациях.
