Безопасная разработка: стоит ли связываться с аутсорсингом и каков профит?

Автор – Юрий Шабалин, ведущий архитектор Swordfish Security

В России сегодня дефицит специалистов по информационной безопасности оценивается в 30 тыс сотрудников. Эксперты полагают , что в ближайшее время до 100 тыс компаний столкнутся с проблемами в найме таких специалистов. Что делать? Растить своих специалистов долго, брать с рынка достаточно дорого и не всегда просто. Немного помогли в этом плане пандемия и массовый переход на удаленку: в офисе стало присутствовать необязательно, числиться среди сотрудников, чтобы быть в команде - тоже. Услуги ИБ на аутсорсинге стали популярнее, особенно в узкопрофильных направлениях, включая безопасную разработку, или DevSecOps. В данном материале Юрий Шабалин, ведущий архитектор Swordfish Security, подробно поговорит о том, реально ли построить правильный и полноценный процесс безопасной разработки на аутсорсе, а также о том, какие варианты вообще существуют в данной сфере.

И мы рассмотрим три варианта: 1) создание процесса полностью на аутсорсе, 2) переход на DevsecOps полностью за счет собственных ресурсов компании, 3) комбинированный подход. И отметим преимущества каждого, оценим недостатки, вместе разберемся, какой может быть оптимальным.

Подход 1. Процесс полностью на аутсорсе

Этот вариант по умолчанию кажется проще. Плюсы очевидны сразу: не нужно искать внутренние ресурсы и тратить время на поиск высококвалифицированного персонала, расходовать бюджет на новую команду, никого не нужно обучать и “растить“ и т.д. Мы сразу получаем полноценную команду специалистов, готовых выстроить для нас все необходимые процессы и автоматизировать все интеграции с разработкой. Звучит, как идеальный план, но на деле все обстоит несколько иначе.

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

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

Далее, расходы. Этот подход является наименее затратным с точки зрения человеческих и технических ресурсов, но заплатить в деньгах придется немало. Ведь компания, которая будет делать абсолютно всё, и стоить будет соответствующе, - команда на проект выделяется объемная (около 5-10 человек, то есть не менее 1,5-2 млн рублей ежемесячно, около 24 млн рублей в год – только на непосредственную оплату труда), сами услуги ввиду их уникальности также стоят немало (вряд ли менее 1-3 миллионов в месяц, то есть еще плюс-минус 30 млн рублей в год) плюс сопутствующие расходы (встречи, командировки, переработки и прочее). Длится процесс не один месяц (более четырех, и может затянуться вплоть до года), так что все это обойдется в несколько десятков миллионов рублей.

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

Стоит тогда посмотреть и другой вариант. К которому мы прямо сейчас и перейдем.

Подход 2. Процесс полностью внутри

Итак, вы решили выстроить весь процесс полностью внутри. Это и правда может показаться логичным. Свои собственные специалисты, знакомые как с процессами внутри компании, так и с инструментальным стэком используемых в разработке технологий, могут намного быстрее и качественнее осуществить внедрение процесса безопасной разработки. Ведь им не нужно объяснять, как заполнять заявки, по каким правилам живет разработка, к кому эскалировать проблемы в случае чего и другие вещи. Вроде все прекрасно, что может пойти не так? А дьявол, как обычно, кроется в деталях.

Главная проблема уже была упомянута - специалисты. Их мало, особенно таких, кто ищет или желает сменить место работы. Стоят они достаточно дорого, а сколько их нужно для реализации необходимого проекта в, скажем, среднего размера компании на 500 разработчиков? Как минимум, необходим руководитель направления, который бы понимал цель, у кого было бы полное видение законченного процесса, как он должен выглядеть и каким должен быть. И хотя бы несколько человек на каждое основное направление в рамках процесса, а их как минимум семь в самом начале пути:

1. статический анализ (SAST),
2. динамический анализ (DAST),
3. анализ компонент с открытым исходным кодом (OSA/SCA),
4. анализ мобильных приложений (MAST),
5. анализ контейнеров (CA),
6. интеграция инструментов (условно DevOps),
7. администрирование серверов и поддержка инструментов в актуальном состоянии

И это, на самом деле, только для старта, когда мы подключаем первые команды. Зачем столько людей, спросите вы? Все очень просто: минимальный спектр работ на первое время, чтобы грамотно запустить процесс, просто огромный. Прежде всего, это понимание и описание стратегии развития процесса безопасной разработки, которая является основой для всего. Именно в ней будут заложены основы процессов, списки инструментов и обоснование для бюджетного планирования. Еще один важный пласт - описание первоначальных бизнес-процессов под каждую практику, составление требований к инструментам, которые будут пилотироваться, и непосредственно их выбор, первоначальная настройка и эксплуатация. Следующий значимый этап - после того, как в процесс начнут заезжать команды, не утонуть в количестве срабатываний от инструментов, которые обязательно нужно разбирать, передавать в команды разработки, а потом контролировать корректность исправлений. На все это нужно время, люди и ресурсы. И набрать такую большую команду сходу зачастую очень сложно.

И нужно понимать, что в случае, если вы делаете все своими силами с нуля, времени может также уйти довольно много, даже больше, чем при аутсорсинге. Есть очень много примеров реализации подобных проектов, в которых около 2-3 лет уходило на запуск трёх основных практик (SAST, SCA, DAST), а также расходовалось немало труда и сил.

Подытоживая, отметим, что человеческие и технические ресурсы здесь занимают главное место, в отличие от первого подхода, ведь вся работа целиком ложится на плечи сотрудников и имеющихся в распоряжении инструментов. По финансовым вливаниям такой подход менее затратен, чем предыдущий, если сравнивать первый год, ведь по сути, главные расходы - это зарплата сотрудников. Здесь можно постараться не выйти за пределы 1,5 млн в месяц, что даст 18 млн рублей в год. Однако, за три года (если столько уйдет на внедрение DevSecOps) на эту статью расходов может уйти не менее 70 млн рублей, поскольку команда будет расти, развиваться, и тогда общие расходы будут даже выше, чем на год аутсорсинга. Однако, ваша обученная супер-команда останется с вами для поддержания процесса безопасной разработки, вам не нужно будет снова и снова звать экспертов со стороны. Кроме того, можно со временем самим начать предлагать специалистов на аутсорсинг, взрастив специалистов внутри. И так покрыть значительную часть расходов.

Итак, и здесь есть свои pro и contra, так где же идеальный баланс? А он как всегда где-то посередине. И ниже мы рассмотрим комбинацию первого и второго подходов, в надежде собрать больше плюсов и избавиться от минусов.

Подход 3. Комбинированный

Итак, нам нужно собрать все плюшки и не набить шишек, верно? Тогда берем и комбинируем все в правильной пропорции. Как это?

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

Внутри компании возникло понимание и желание реализовать процесс безопасной разработки. Для начала, во главе его должен встать человек из организации, который понимает (хотя бы в общих чертах), что необходимо получить от данного процесса. На этом этапе внешняя компания совместно с внутренним драйвером поможет более точно определить цели и задачи проекта, описать концепцию, верхнеуровневые бизнес-процессы. Также будет составлен план найма людей в команду (как формирование с нуля, так и расширение текущей, если она уже есть). Симбиоз здесь очень важен, поскольку необходимо сочетание опыта, идеальной модели из лучших практик с реальной жизнью организации. После этого, внутренняя и внешняя команды совместно начинают поэтапное внедрение процесса безопасной разработки, в рамках которого внешняя компания, как носитель “сакральных” знаний, щедро делится ими с внутренней командой, обучая её различным нюансам и тонкостям процесса.

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

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

А теперь про ресурсы. Этот подход является сбалансированным не только по описанию, но и по затратам. Ведь все пункты делятся между внутренней и внешней командой, а это значит, что можно более плавно распределять время, бюджет и человеческий ресурс. Если конкретнее, то временные затраты на старт и запуск комбинированного процесса достаточно малы, целиком проект может уложиться в год-полтора, денежные издержки делятся между командами, а значит, ФОТ и затраты на внешнюю компанию будут меньше (вполне можно обойтись общими затратами на проект в 30-40 млн рублей).

Заключение

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