Подземелье и драконы: что общего между метро и разработкой

Привет, я Светлана Газизова, и, как несложно догадаться, я работаю в Positive Technologies. Занимаюсь я всяческим AppSec и всем, что к нему близко. Занимаюсь я этим серьезное количество времени — уже пятый год.

Сегодня хочу рассказать вам, насколько развитие AppSec и DevSecOps (да и вообще в целом практика безопасной разработки) похоже на то, как развивалось метро в Москве. Да‑да, именно метро!

Мне кажется, многих это сравнение может немного смутить. Но на самом деле в этих двух явлениях обнаруживается большое количество похожих паттернов. Поэтому я думаю, что мы с вами сегодня вместе к этому придем.

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

Так что устраивайтесь поудобнее — сегодня у нас будет необычная экскурсия. С одной стороны — в мир безопасной разработки со всеми его AppSec’ами и DevSecOps’ами. С другой — в московское метро с его кольцами, диаметрами и постоянно растущей сетью станций. Готовы? Тогда поехали!

Как я оказалась в AppSec и что это вообще такое

Я пришла в AppSec из разработки, хотя последний раз код писала очень много лет назад. Большую часть карьеры до AppSec я проработала системным аналитиком и системным архитектором. Поэтому, когда мы говорим про secure by design, это мне прям очень близко и понятно.

Был у меня и год в роли единственного безопасника в компании. Теперь я могу гордо называть себя экс‑CISO, но те, кто был единственным безопасником в организации, понимают: это значит делать абсолютно все — от настройки СКУД до восстановления упавшего кластера файрволов. Опыт, конечно, интересный, но потом я нашла свою золотую середину и стала заниматься AppSec.

Собственно, активно занимаюсь безопасной разработкой с конца 2020 года, веду телеграм‑канал AppSec Journey — там есть и мемы (многие подписываются именно из‑за них), и разные прикольные исследования, и полезные материалы для обучения. В общем, стараюсь делать контент, который самому было бы интересно читать.

AppSec и DevSecOps: вечная путаница

Если начать с классической application security, она же AppSec, то это то самое понятие, которое первым приходит в голову при словах «безопасная разработка».

Представьте:

• Мы написали код

• Проверили его

• Собрали билд — запустили какой‑нибудь dependency check

• Протестировали приложение — автоматом или вручную

• И только потом выпустили в продакшен

DevSecOps — это почти то же самое, но автоматизированное. Тот же самый пайплайн, только все проверки запускаются по триггеру. Сделал pull request — побежали проверки. Это как разница между ручным управлением поездом и автопилотом.

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

Что нужно для безопасной разработки приложений

Если мы говорим про то, как приблизиться к идеальному состоянию DevSecOps (хотя «идеальное» — это громко сказано), то я бы выделила два ключевых этапа. Речь о ситуации, когда безопасность становится естественной частью деятельности разработчиков, без постоянного надзора со стороны, — команда разработки полностью берет на себя ответственность за кибербезопасность. По‑моему, это вполне достойная цель.

Первый этап: базовые вещи, которые должны быть в арсенале

1. Автоматизированные штуки в IDE
   Ну вы понимаете, о чем я: это всякие плагины, линтеры, которые прямо там, в вашей среде разработки, помогают сразу ловить косяки. Это может быть и Copilot (хотя его, кстати, тоже нужно проверять — вот ирония!), и другие инструменты, которые умеют анализировать код на лету и подсказывать, где что‑то пошло не так.

2. Обучение безопасному кодингу
   Причем не просто «вот вам список уязвимостей», а с объяснением, зачем это нужно, почему мы делаем именно так, а не иначе. Чтобы разработчики понимали суть, а не просто ставили галочки.

3. Secure by design как философия
   Это четкое понимание: как мы проектируем системы, какие принципы используем, за что отвечаем. У нас, например, есть целая карта таких принципов: сначала их было штук десять, они были разрозненные, а за год как‑то сами собой сложились в систему. Причем это не догма — всегда можно посмотреть другие методологии, но важно иметь какую‑то основу.

4. «Золотые образы»
   Эталонные контейнеры, проверенные архитектурные решения, гайды по аутентификации (что можно, что нельзя). Можно идти от белого списка, можно от черного — главное, чтобы это где‑то жило и было доступно. Особенно это важно для новых разработчиков — сразу видят, как принято делать у нас. Хотя сеньоры, конечно, и так все знают — они же сами это придумывали.

Второй этап: вовлечение команд

1. Обучение разбору уязвимостей
   Казалось бы — разработчики и так должны это уметь. Но на практике, когда получаешь отчет сканера с кучей false positive, нужно понимать, как это все разметить. Особенно актуально, когда AppSec‑специалистов мало, а разработчиков много. Фишка в том, чтобы дать им самостоятельность — да, ты можешь прийти и спросить, но в целом ты сам отвечаешь за свой код. Это психологически комфортнее, чем когда кто‑то стоит над душой.

2. Настоящее вовлечение разработчиков
   Это именно совместная, вдумчивая настройка инструментов. Хотим application firewall или защиту от ботов — кто лучше разработчика знает, что действительно нужно? Давайте вместе решать, как это внедрять. Это же их продукт, в конце концов!

3. QA + Security = любовь
   QA‑инженеры — вообще темные лошадки. У них почти тот же инструментарий, что и у специалистов по безопасности, только используют они его по‑другому. Возьмем тот же фаззер: безопасники смотрят на уязвимости, QA — на баги. А инструмент‑то один! Да и мышление у QA подходящее — они же профессиональные искатели косяков.

4. Инструменты безопасности для пользы разработки
   Вот смотрите: статический анализатор может не только искать проблемы в защите, но и показывать, где код избыточный. Динамический анализ — находить QA‑проблемы. Получается двойная польза!

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

Что общего между разработкой и метро

Метро и разработка — казалось бы, что может быть общего? Когда я только переехала в Москву в 2012 году, метро казалось мне огромным.

Я жила на «Планерной», и доехать до «Выхино» было целым путешествием. Тогда не было ни МЦК, ни половины современных веток. А начиналось‑то все с одной линии и маленького ответвления!

Так же и с безопасной разработкой. Помните, как раньше было? Сделали продукт, проверили разок перед сдачей — и все. Как та первая линия метро — есть, но толку немного. Потом появились эти ужасные 300-страничные гайды от Microsoft — ну точь‑в-точь как первое кольцо метро, которое пыталось соединить разрозненные станции.

Как развивалось метро и AppSec

1. 1930-е. Первые «пентесты». Как первые линии метро — всего несколько станций, но уже начало.

   

2. 1990–2000-е. Методология Waterfall. Долгий процесс согласований с «каскадными» проверками в конце.

3. 2005-е. Microsoft SDL. Появление первых методологий — как кольцевая линия, соединяющая все.

4. 2010-е. BSIMM, SAMM. Развитие стандартов и практик — новые ветки и переходы.

5. 2020-е. Платформы. Интеграция всего и вся — современные сложные развязки.

Сейчас смотрю на схему метро — глаза разбегаются. Кольца, диаметры, пересадки… Но если вникнуть — все логично.

Так же и с AppSec: из отдельных инструментов все собирается в целые платформы. SAST, DAST, SCA — теперь это не отдельные штуки, а единый процесс. Как те же МЦК с МЦД, которые связали всю систему воедино.

Самое забавное — как одинаково все растет. Метро полезло в область, AppSec вышел за рамки просто проверки кода. Теперь и API смотрим, и контейнеры, и мониторинг. Автоматизация вообще отдельная песня: в метро турникеты вместо контролеров, у нас — автоматические проверки вместо ручных тестов.

Вот и получается, что безопасная разработка — это как метро. Кажется запутанным, пока не поймешь систему. А понял — и все, попал в матрицу. Теперь везде вижу эти параллели!

Три главных сходства

1. Укрупнение
   Метро когда‑то состояло из отдельных линий — теперь это единая система с общими стандартами. То же произошло и с AppSec: от разрозненных инструментов — к целым платформам, где все работает в комплексе.

2. Разрастание
   Новые станции появляются в самых неожиданных местах. В AppSec аналогично — если раньше проверяли только код, теперь смотрят и API, и контейнеры, и процессы мониторинга, и даже защиту от ботов.

3. Автоматизация
   Эскалаторы вместо лестниц, турникеты вместо контролеров. В DevSecOps та же история: чем больше процессов работает «по кнопке», тем эффективнее вся система.

Взгляд в 2030-й

Что будет дальше? Ну, метро‑то планирует новые ветки и кольца. У нас то же самое: вот эти все AI‑ассистенты, инструменты для автоматической проверки архитектуры на угрозы, глубокая интеграция кибербезопасности в процессы. Сначала смотришь — и кажется, что все сложно, но потом понимаешь, что все очень логично!

А самое забавное — если посмотреть, как менялись приоритеты в BSIMM за эти годы. Вот, например, контейнерная безопасность — помните, когда она только появилась? Сначала ее вообще не было, потом добавили как что‑то второстепенное, а сейчас — бац! — и она уже на первых местах по важности. Прямо как новая ветка метро: сначала одна станция на окраине, а через пару лет — ключевой транспортный узел.

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

А что будет в 2030-м? Ну, если продолжать аналогии с метро… Наверное, нас ждет:

• полная интеграция AI‑ассистентов прямо в процесс разработки — как эти умные станции с распознаванием лиц;

• автоматический threat modeling станет стандартом — как автопилот в поездах;

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

Но это все догадки. По правде говоря, я не знаю, что именно нас ждет. Может, придумают что‑то совсем уж неожиданное — как в свое время придумали МЦД. Поэтому вопрос «что будет с AppSec в 2030 году?», скорее, ко всем нам. Как думаете, в какую сторону повернем? Может, у вас есть свои прогнозы?