Приходится на пальцах объяснять программисту, почему это важно: кто такие DevSecOps и за что им много платят

На канале «АйТиБорода» вышло интервью с Products Director компании Positive Technologies Денисом Кораблевым. Positive Technologies специализируется на разработке собственных продуктов в сфере информационной безопасности.

В почти двухчасовом видео Денис Кораблев рассказал про относительно новое направление в индустрии — DevSecOps, зачем оно нужно и как его внедрить. Мы послушали и записали самые интересные моменты.

Что такое DevSecOps

Если говорить абстрактно, то есть две силы:

• Разработчики, которые деливерят продукт, обслуживают его, админят и так далее.
• Безопасники, которые стараются не допустить каких-то страшных рисков.

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

Аббревиатуру DevSecOps в свое время застолбили за собой Microsoft, и они же первые начали говорить о том, что секьюрити-вопросы нужно решать как можно раньше, еще на этапе разработки и проектирования. Например, заниматься безопасностью уже при выборе библиотеки — чтобы не выбрать «дырявую», которую не защитит ни одна система. 

Но Microsoft применяли новый метод к водопадному подходу, который сейчас много где заменил Agile. В результате, аббревиатура DevSecOps прижилась в контексте ролей и инструментов для секьюрити. Они, в свою очередь, появляются в пайплайне разработки уже на начальных этапах.

DevOps — это история про то, чтобы сделать продукт, который деплоится куда-то, доставляется и работает. А Sec в середине означает, что мы будем учитывать еще и секьюрити.

Почему разработчики не думают об уязвимостях

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

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

Кто использует DevSecOps и кому оно нужно в перспективе

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

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

Почему нужно развивать секьюрити

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

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

Как внедрить в команду DevSecOps

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

Но для начала нужно поговорить с CEO или CTO продукта, который мы разрабатываем. Главный вопрос: чего мы боимся? Ответы могут быть очень разные. Например, что взломают сайт и разместят на нем информацию, из-за которой акции компании упадут. Или другие моменты, о которых вы даже не задумывались. Задача: заставить оценить реальные риски и понять, от чего мы защищаемся.

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

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

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

Когда CEO понимает зачем это нужно, наступает этап работы с командой. Здесь работает единственный кейс: когда ты на пальцах объясняешь программисту, почему это важно. Второй шаг: рассказать, что это тренд и через пару лет будет обязательным навыком для собеседований и работы. Вот как сейчас с тестами. Скажи на собеседованиях, что не хочешь их писать, как на тебя посмотрят?

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

Как DevSecOps меняет процессы команды

В первую очередь появляются новые типы багов — уязвимости. Также появляется новая роль — верифицировать эти баги. Задача в том, чтобы проверять false positive баги, потому что иногда то, что воспринимается как уязвимость ей не является. Когда программист получает эту чистую верифицированную багу, ему нужно ее пофиксить и отдать обратно.

У DevOps специалистов появляются новые шаги в пайплайне: запустить дополнительные сканеры и проанализировать результаты. Также появляется дополнительная работа у QA: исправленные баги от разработчиков отправляются на проверку именно им.