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

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

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

Мы как шеф-повара рекомендуем приправить DevOps опцией Sec. Эта специя поможет минимизировать стоимость и повысить скорость исправления ошибок. О DevSecOps-разработке мы и расскажем в статье. 

Из чего же сделан DevSecOps?

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

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

Авторы библиотек, выкладываемых в общедоступные репозитории, не всегда известны. Потенциально они могут быть хакерами, сотрудниками спецслужб недружественных государств. Таким образом, можно инвестировать в средства защиты, обложиться межсетевыми экранами, VPN-шлюзами, антивирусами, системами классов DLP, PAM и тому подобным, но «троянский конь» в виде используемых в программном коде библиотек позволит злоумышленникам незаметно проникнуть внутрь компании и завладеть данными, вмешаться в работу автоматизированных производств и убить инфраструктуру.

Как добавить Sec в процесс приготовления нашего салата?

Безопасность ― это вам не чили. Щепотки будет недостаточно. Не скупитесь и сыпьте щедро. Но сначала… Договоритесь о недопустимых событиях, об уровне риск-аппетита с бизнесом, разработайте модель угроз. Некоторым необходимо наличие собственного доверенного репозитория, другим достаточно GitHub, GitLab и т.д.

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

Можно начать с внедрения SAST, SCA и DAST, причем с бесплатных инструментов (применимых к текущим технологиям DevOps), а потом уже внедрять платные.

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

При внедрении DevSecOps стоит учитывать затраты на разделение сред Dev, Test и Prod. Это не входит в концепцию по западным лекалам. Однако от руководства компаний-клиентов нам часто поступают запросы на усиление безопасности разработки, поскольку разработчик перепутал стенд, после чего важнейшие системы компании пострадали. Вынести в облако Dev и Test и оставить у себя Prod кажется хорошей идеей (или наоборот). Для некоторых она способна полностью решить вышеупомянутую проблему.

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

И помните: DevSecOps – это безостановочные мониторинг и улучшение с постоянным обновлением стандартов ИБ и поиском идеальных практик.

Подведём итоги

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

Уже существуют реестр отечественного ПО (ведется под патронажем Минцифры), реестр сертифицированных средств защиты ФСТЭК России, реестр ФСБ России, реестр отечественных ПАК (ведётся Минпромторгом). В ближайшие годы для попадания во все эти реестры для разработчиков будет важно учитывать требования по безопасной разработке, показывать это на практике.

Итак, инструменты ждёт улучшение.

Людей ― просветление.

А процессы… мы поможем выстроить.

Ведь нам не всё равно, какое ПО появится на отечественном рынке.