Всем привет! Меня зовут Юрий Шабалин, я ведущий архитектор ГК Swordfish Security. Уже почти 10 лет мы создаем защищенные ПО, внедряем практики DevSecOps и снижаем риски различных киберугроз. Поговорим сегодня о том, как можно построить процесс безопасной разработки.
Из-за событий февраля этого года и последующих за ними санкций в ИТ сформировались несколько тенденций. Первая: многие иностранные вендоры ушли с российского рынка или ограничили свои операции (в их числе Microsoft, Oracle, SAP, EPAM Systems, Cisco, Intel, AMD и другие). Вторая: России объявили настоящую кибервойну. За первые пять месяцев 2022 года число атак увеличилось на 38% по сравнению с аналогичным периодом прошлого года. И третья тенденция: спрос на информационную безопасность резко вырос, но кадров не хватает - дефицит ИБ-специалистов оценивается в 30 тыс. человек. Таким образом, компаниям нужно подстраиваться под новые реалии: разрабатывать собственные продукты и при этом заранее думать о защите.
А как сделать процесс создания продуктов безопасным? Один из оптимальных путей видится во внедрении DevSecOps, методики интеграции принципов безопасности в непрерывный процесс разработки программного обеспечения. Можно реализовать это в компании своими силами или привлечь специалистов со стороны. Возможно, есть еще варианты? Ниже мы разберем основные, отметим их плюсы и минусы, посчитаем примерные затраты.
Делаем сами
Хорошо, если в компании уже есть специалисты, которые смогут возглавить проект по внедрению DevSecOps и развивать его. Они уже знают процессы компании изнутри и хорошо знакомы с инструментальным стэком технологий, применяемых в разработке. Однако, если нужно будет нанять для этого команду целиком, могут возникнуть трудности. Во-первых, таких специалистов на рынке мало (тем более, в свободном доступе), во-вторых, они стоят очень дорого.
Посчитаем, сколько понадобится сотрудников, чтобы реализовать проект для компании среднего размера - на 500 разработчиков. Во главу всего необходимо поставить руководителя направления (это раз). Он должен сформулировать цель и модель законченного процесса, то есть представить, какой нужен результат. В начале внедрения будет минимум семь направлений:
- статический анализ (SAST),
- динамический анализ (DAST),
- анализ компонент с открытым исходным кодом (OSA/SCA),
- анализ мобильных приложений (MAST),
- анализ контейнеров (CA),
- интеграция инструментов (условно DevOps),
- администрирование серверов и поддержка инструментов в актуальном состоянии.
Так вот, на каждое из этих направлений нужна хотя бы пара специалистов. Таким образом, у нас уже набирается 15 сотрудников. А это только отправная точка, где мы задействуем первые команды.
Расширить этот минимум можно, а вот сокращать не стоит. Почему? Чтобы качественно запустить процесс безопасной разработки, необходимо пройти следующие этапы:
- Понять и описать стратегию развития процесса безопасной разработки.
- Сформулировать первоначальные бизнес-процессы под каждую практику, описать требования к инструментам, готовящимся к пилоту, обосновать, почему выбрали именно их, настроить и запустить инструменты в эксплуатацию.
- Контролировать срабатывания от инструментов, разбирать их, передавать разработчикам и следить, чтобы все поправки были корректными.
Всё это выглядит как очень большой объем работы, на который может уйти много времени. Есть немало примеров, где компании тратили 2-3 года на запуск только основных практик - SAST, SCA, DAST. Кроме этого, возможно, не сразу получится собрать необходимую команду. Таким образом, этот вариант подойдет тем компаниям, которые обладают нужными ресурсами и смогут удержать этот груз на собственных плечах.
Расходы
Основная статья расходов - оплата труда. Первое время можно тратить на команду примерно 1,5 млн рублей в месяц, тогда за год получится 18 млн. Но если проект растянется на три года, за это время придется заплатить не меньше 70 млн рублей. Ведь команда будет увеличиваться и развиваться, а вместе с этим вырастут расходы на ее содержание. Но здесь есть большой плюс: обученные специалисты останутся в компании и будут поддерживать процесс, поэтому звать кого-то со стороны не придется. А со временем, когда команда нарастит компетенции, можно будет предлагать ее услуги на аутсорсе. Возможно, так получится вернуть какую-то часть расходов.
Отдаем на аутсорс
Сторонние специалисты уже имеют подходящий опыт и знают, как выстраивать процессы, автоматизировать интеграции с разработкой. Если всю работу передать им, не придется нанимать свою команду, тратить на нее время и ресурсы. Это будто бы легче, чем делать всё своими силами. Проанализируем данный способ подробнее и узнаем, действительно ли это так.
Ключевое место в DevSecOps занимает процесс, который включает взаимодействие участников между собой. Чтобы построить его качественно, нужно бесшовно внедрить инструменты информационной безопасности в жизненный цикл ПО. Но проблема в том, что в каждой компании он устроен по-разному: и технически, и организационно. То есть команда на аутсорсе, взявшись за ваш проект, не будет знать всех особенностей и нюансов процессов разработки ПО, в отличие от внутренних специалистов. У нее могут быть трудности даже с элементарными вещами, например, коммуникацией и эскалацией проблем (такое случается нередко). Это значит, что на первых этапах работы не исключены ошибки со стороны компании-исполнителя. Ее команде потребуется время, чтобы изучить все стандарты и правила заказчика - это может затянуть проект.
С учетом обозначенной выше проблемы внедрить DevSecOps полностью на аутсорсе скорее всего не получится (даже у крупной компании). А стоит ли вообще это делать? Получится ли тогда выстроить качественный и эффективный процесс безопасной разработки? Те, у кого есть опыт работы с такими проектами, зачастую дают отрицательные ответы на эти вопросы.
Расходы
На первый взгляд этот способ кажется менее затратным в плане человеческих и технических ресурсов, по сравнению с первым вариантом. Но исполнитель привлечет на проект большую команду - 5-10 специалистов. Их работа будет стоить примерно 1,5-2 млн рублей в месяц и 24 млн в год. Кроме этого, придется еще заплатить за сами услуги: около 1-3 млн в месяц, или 30 млн в год. Также отдельно компенсируются затраты на встречи, командировки, переработки и другие активности. Чтобы реализовать проект, команде будет мало одного месяца, она потратит на него более четырех, а может, даже год. Таким образом, общие расходы могут составить более 50 млн рублей.
Итак, мы видим, что оба варианта имеют свои минусы и вызывают некоторые сомнения. А что будет, если объединить их? По правилам минус на минус дает плюс. Посмотрим, так ли это на практике.
Миксуем свои ресурсы и аутсорс
Смысл здесь вот в чем. Внешние компании имеют большой опыт и обширные знания, поэтому не стоит отказывать от их помощи. Внутренние специалисты хорошо знакомы с продуктами компании и ее процессами, они погружены во всё это, а значит, смогут направить проект в сторону успеха и эффективности. Главное, комбинировать два этих ресурса в правильной пропорции. Вот три основных этапа, которые нужно пройти.
1. Внутренние сотрудники становятся первым и ключевым звеном всего процесса. Они формулируют понимание результата, который должен принести проект.
2. К процессу подключается внешняя команда. Вместе с внутренними сотрудниками (ключевым звеном) она формулирует конкретные цели и задачи проекта, описывает концепцию и верхнеуровневые бизнес-процессы, определяет каких сотрудников и когда нужно нанять в команду заказчика.
3. Внешние и внутренние специалисты совместно внедряют DevSecOps.
В той модели команда аутсорсинга предоставляет опыт и ценные знания, а внутренние специалисты подстраивают их под реалии компании. То есть эти два фронта взаимодействуют в формате менторинга. Внешняя команда обучает внутреннюю, помогает ей внедрять процессы и постепенно расширяет ее компетенции. При необходимости наставник в лице аутсорса может сам полностью выполнять какие-нибудь задачи, если у специалистов компании что-то не получается. После того как процесс будет внедрен, менторинг заменяется на поддержку: внешняя команда подключается редко, если нужно решить сложную задачу, на которую у компании не хватает ресурсов.
Конечно, может быть сложно найти компанию, которая готова делиться с заказчиками своими знаниями. Ведь аутсорсингу проще держать компетенции в секрете, вести проекты самостоятельное и зарабатывать на этом деньги. Но договориться всегда можно, поэтому такой вариант сотрудничества вполне реален.
Расходы
Большой плюс этого варианта в том, что все ресурсы делятся между двумя командами. На старт и запуск проекта уходит достаточно мало времени. Весь процесс можно построить за год-полтора. При грамотном распределении времени, бюджета и человеческого ресурса общие затраты составят примерно 30-40 млн рублей.
Вывод
Конечно, компания сама решает, каким способом ей строить процесс безопасной разработки. Здесь важно не только всё просчитать и оценить с точки зрения бюджета, но и спрогнозировать развитие проекта с учетом человеческого фактора. Насколько хорошо в компании выстроены процессы управления, принятия решений, эффективно ли сотрудники взаимодействуют между собой и с внешними командами, как чувствуют себя в спринтах и т. д. - всё это важно и нужно учитывать при планировании. Но в целом, наиболее выгодным вариантом представляется гибрид аутсорсинга и собственных сил. Он позволяет распределять ресурсы между двумя фронтами, а вместе с этим растить собственную команду профессионалов. Отличные специалисты, которые останутся с вами, и налаженный процесс безопасности - верные признаки того, что бизнес будет успешным.