На последнем Международном экономическом форуме в Давосе эксперты представили рейтинг глобальных рисков, которые будут актуальны в ближайшие годы — в топ-10 попали киберугрозы. Это связано с тем, что индустрия разработки растет, сегодня она составляет уже сотни миллиардов долларов, а проблемы безопасности, которые зачастую находятся в коде, прикладе или артефактах, решаются медленно или вовсе игнорируются.
В крупных организациях соотношение разработчиков к безопасникам, именно к Application Security, катастрофическое — 100:1. При таком раскладе трудно ожидать от малочисленной команды AppSec-специалистов, что она покроет проверками весь код, который создают разработчики, выловит все уязвимости и обеспечит программным продуктам надежную защиту от существующих киберугроз. Сегодня поговорим о безопасности с Андреем Ивановым, директором по развитию бизнеса компании Swordfish Security, которая занимается построением процессов разработки безопасного ПО.
Индустриальные факторы
В рамках создания процесса безопасной разработки нужно учитывать индустриальные факторы. Прежде всего, к ним относятся бизнес, разработка и безопасность.
Бизнес
Сюда входят функции, сервисы, цифровые приложения, необходимость которых возрастает каждый день. Бизнес — драйвер возникновения таких программных продуктов, именно он стимулирует непрерывный рост количества сервисов и приложений. Как следствие, увеличивается число заказчиков, стейкхолдеров и вовлечённых людей. Что их всех волнует? Конечно, сокращение time to market (временного гэпа от начала разработки идеи до конечного запуска решения и его выхода на рынок). Как это работает в их понимании? Если они придумали идею, значит, условно уже завтра она должна быть реализована в мобильных, десктопных или веб-приложениях для конечных пользователей.
Разработка
Под воздействием бизнес-заказчиков цикл разработки в части time to market сокращается. Происходит переход на микросервисную инфраструктуру, что позволяет катить в прод нужные изменения.
Кибербезопасность
Быстрая разработка и большое количество релизов провоцируют рост технического долга и числа дефектов информационной безопасности. Если используются инструменты для отслеживания этих дефектов, количество фолсов в них тоже увеличивается вместе с числом срабатываний. Всё это вместе с дефицитом кадров создает массу проблем при выпуске безопасного ПО. Кроме этого, высокую активность проявляют злоумышленники. Как эволюционируют цифровые угрозы? Гиты, процесс разработки приклада и кодинг угрожают обходом код-ревью и компрометацией системы хранения продуктов и компонентов, позаимствованных у GitLab, GitHub и других сервисов.
Когда код оказывается на конвейере сборки, у злоумышленников также появляется много векторов для атак. Прежде всего, это возможность компрометации самой CI-системы. Если заразить ее, то всё, что через неё пройдет, также будет скомпрометировано. Еще один вектор связан с модификацией тех систем, которые являются компонентами CI. Другие возможности открываются за счет использования ПО на базе Open Source, которое также может распространяться с функциональностью CI-систем. В продукты с открытым исходным кодом часто внедряют зловреды. В качестве примера можно использовать нашумевшие истории, актуальные для России в 2022 году. Это компрометация внешних пакетов, зависимостей, которые разработчики тянут из доступных репозиториев. Участились случаи, когда в них «подселяют» malware, protestware, известные публичные уязвимости, zero day и многое другое — всё это таргетируется именно на Россию.
В конвейере доставки векторы для атак отчасти похожи на перечисленные выше, отчасти уникальны относительно CI. К ним относится компрометация систем CD и инфраструктурного окружения. Среди наиболее старых, зрелых практик злоумышленников можно выделить компрометацию конечных интерфейсов. Вот так примерно выглядит карта угроз.
Безопасная разработка позволит снизить риски, исходящие от этих векторов, и проводить регулярный анализ защищенности продуктов в процессе их создания.
Цели DevSecOps
Какие же цели преследует методология DevSecOps? Рассмотрим подробнее каждую из них.
Time to market
DevSecOps способствует сокращению ТТМ. Казалось бы, как? Ввели новые критерии приёмки, появился инструментарий проверки на уязвимости, значит, не может ТТМ уменьшаться. Но как показывает опыт, на проектах средней и длинной дистанции это показатель сокращается.
Техдолг и так есть с точки зрения информационной безопасности. Но в рамках DevSecOps у компании появится возможность находить уязвимости на самых ранних этапах разработки, устранять их быстрее и с меньшими затратами. Это окажет положительное влияние на time to market. Кроме того, заметно вырастет уровень зрелости команды разработки не только в части ИБ, но в части функциональности кода.
Compliance
Регуляторы серьёзно взялись за разработку и выпуск регламентирующих документов, которые становятся обязательными для ряда компаний. Прежде всего, к числу этих организаций относятся те, кто входит в критическую информационную инфраструктуру (КИИ) России, например банки, выпускающие свои приложения. Для других компаний ещё нет обязательных к исполнению регламентов, но со временем они появятся у всех.
Одной из целей DevSecOps как раз является приведение разработки к соответствию стандартам, поступающим от регуляторов, и лучшим индустриальным практикам с целью обеспечить высокий уровень зрелости с точки зрения документального оснащения этого процесса.
Ещё одна история, которая важна для юристов в части выполнения ограничений, накладываемых агриментами — это отслеживание лицензионной чистоты свободно распространяемых программ. Бывает такое, что компонент или библиотека бесплатные, а в лицензионном соглашении написано: каждый четверг месяца использующий ПО должен присылать автору ящик пива. И это не шутка, а абсолютно реальный пример. Но есть и более серьёзные вещи, когда, например, лицензионная политика обязывает компании, использующие общедоступный компонент, делать свое ПО свободно распространяемым.
Digital Business Continuity and Security
Внедренные практики DevSecOps предоставляют гарантию, что весь выпускаемый объём ПО компании и цифровые сервисы безопасны. Повышение киберустойчивости одной системы ДБО или двух в рамках крупного банка — это то, с чем индустрия давно справилась. Но обычно в зрелых финтех- и телеком-компаниях таких систем десятки. Не все из них покрыты подходами с точки зрения security. Как следствие, плотность дефектов не снижается. Но если постоянно отслеживать одни и те же уязвимости, рассказывать, как их не допускать, то со временем они исчезнут.
Развитие зрелости в разработке
Когда внедряется Application Security, разработчики сначала смотрят на это скептически. Им необходимо развиваться в Security, чтобы знать, как устранить конкретную уязвимость, почему она считается опасной, тот ли метод, который подсвечен инструментом или специалистом Application Security в библиотеке, используется у них в коде? В итоге внедрение подходов безопасной разработки приводит к росту зрелости самих процессов создания ПО.
Методология
Поговорим о методологии и о том, как к ней подступиться. Чтобы построить процесс безопасной разработки, нельзя фокусироваться на чем-то одном, например, только на инструментах или регламентирующих документах. Нужно работать в трёх доменах или по трём векторам — это инструменты, процессы и компетенции (то есть сами люди).
Если взять одного из представителей квадранта Gartner по статическому анализу кода и внедрить его в процесс разработки, он будет давать столько белого шума, что на второй или третий день его захочется отключить — с таким количеством фолсов работать невозможно. Эта ситуация произойдет в реальности, если не продумать процесс анализа срабатываний, не сформулировать ролевую модель (зоны ответственности, условия SLA и так далее). То есть для того, чтобы работать с таким инструментом, необходимы соответствующие компетенции.
Итак, поговорим о трёх доменах, которые мы упомянули выше. Восьмёрка, обозначенная на рисунке ниже, символизирует циклический процесс разработки, к которому многие стремятся, а некоторые уже применяют его на практике. На различных этапах производства программного обеспечения нужны разные практики или классы инструментов Application Security.
На стадии дизайна новой функции или системы, когда разработчик только набирает через ADE определенные внешние библиотеки, пригодится практика Open Source Analysis (OSA). Она позволяет не допускать попадания небезопасных компонентов в контур разработки. С учетом того, что ПО сегодня практически не пишется «с нуля», а для его создания переиспользуются внешние компоненты — это очень актуальная практика, о которой не стоит забывать.
Если говорить о разработке прикладного кода, существует одна из самых зрелых практик, которая применяется в большинстве крупных организаций. Речь идет об инструментах статического анализа кода (Static Application Security Testing, SAST) и построении древа зависимостей, определении потенциальных уязвимостей, дальнейшем разборе и устранении ошибок.
Когда код превращается в CI-системе в некий артефакт, также важно посмотреть на присутствующие в нем прямые и транзитивные зависимости с точки зрения их безопасности. Тут может возникнуть вопрос: мы уже ограничили внешние небезопасные библиотеки, они не проходят по нашему профилю защиты для попадания в контур, зачем же нам делать еще одну проверку на этапе сборки? Во-первых, уязвимости появляются в свободно распространяемых библиотеках каждый день. Во-вторых, нередки случаи, когда на этапе Open Source мы заблокировали библиотеку, а разработчик в процессе написания кода решил, что она ему всё равно нужна, и использовал ее. Такие моменты как раз отлавливаются в рамках практики Software Composition Analysis (SCA).
Идём дальше. Когда система попадает в UAT, предпрод, тест, уже можно поиграться с ней инструментами динамического анализа (Dynamic Application Security Testing, DAST), попытаться подсветить её через интерфейс, посмотреть на API-запросы, выяснить, какие из них «торчат» наружу, попытаться имитировать действия злоумышленников. Конечно, это будет не то же самое, что делают хакеры, но очевидные баги и даже не очень очевидные ошибки получится отловить с помощью инструментария и методологии.
После этого система попадает на стадию operation, где у кого-то уже выстроена микросервисная инфраструктура, а кто-то ещё режет свой монолит на «кусочки». Здесь важно думать не только об анализе самих образов контейнеров, но и об их межсетевом взаимодействии, network policies. Существует довольно много практик, которые позволяют осуществить так называемые CSP-платформы, необходимые для эффективного процесса безопасной разработки.
Application Security Orchestration and Correlation
Когда в компании появляется такой огромный набор для Application Security, возникает вопрос: как всё это запустить вовремя в CI, с какими настройками, для какой команды, как собрать информацию в рамках одного окна, как отслеживать метрики и динамику улучшения процесса? Для ответов на все эти вопросы существуют инструменты класса Application Security Orchestration and Correlation (ASOC). Разберём их подробнее немного позже.
В 2022 году из России ушли многие зарубежные компании. Что осталось из инструментария Application Security? Как работает импортозамещение?
SAST. Конечно, инструментария стало меньше, но трезвые оценки показывают, что унывать пока рано. Многие отечественные инструменты, включая Open Source, выглядят очень неплохо, и их довольно много на рынке. Кроме этого, тот же CodeQL в статическом анализе можно использовать как некую кодовую базу для написания правил для тестирования кода.
DAST. С динамикой ситуация интересная. Крупнейшие российские вендоры, например Positive Technologies, активно разрабатывают решения в этой области. У них есть определенные продукты и сканирующие ядра, поэтому можно предположить, что в самое ближайшее время они догонят такие продукты, как Netsparker и Web Inspector.
SCA. Есть как бесплатно распространяемый и активно используемый в нашей стране софт (Dependency-Track, Dependency-Сheck), так и отечественное ПО.
MAST (Mobile Application Security Testing). В этой группе есть отечественные инструменты, которым уже несколько лет. Они вполне выдерживают конкуренцию даже среди международных аналогов.
В части СА (Container Analysis)/ CSP (Container Security Platfroms), если фокусироваться только на анализе образов, есть бесплатные инструменты, которыми можно легко воспользоваться. В области CSP российский рынок отстает, но есть хорошие отечественные решения, которые активно развиваются. И это внушает оптимизм.
С ASOC также всё неплохо: здесь есть и Open Source, и отечественные инструменты, которые позволяют оркестрировать весь процесс разработки. Поэтому живём дальше.
Построение центров компетенций
Переходим ко второму домену, то есть людям. Здесь мы будем говорить о создании и развитии центров компетенций.
Прикладное обучение необходимо для разработчиков, оно расширит их знания в сфере безопасности и позволит им создавать безопасный код, не допускать ошибок в архитектуре и так далее. Также следует не забывать о программах осведомлённости — Security Awareness. С помощью них можно рассказать большому кругу людей в рамках компании о том, почему безопасность важна и зачем нужно ей заниматься. Это позволит освободить время разработчиков, сделать процесс более зрелым, улучшить работу смежных отделов. Таким образом, компания получит союзников, а не людей, которые могут устроить «итальянскую забастовку».
Кроме этого, в рамках создания центра компетенций можно активизировать работу на внутреннем портале и поместить на него единые правила, которые использует компания в части Application Security, обзоры уязвимостей, статьи по темам безопасности и так далее — всё, что может принести пользу. Казалось бы, это очевидная вещь, но зачастую в очень крупных компаниях со зрелыми процессами она не используется. Также не стоит забывать про такие инструменты, как email-рассылки, семинары, митапы, вебинары, CTF.
Активности, реализующиеся в рамках центра компетенций, полезны еще и тем, что позволяют выделить из числа обучающихся наиболее заинтересованных сотрудников, подходящих на роль Security Champions (Чемпионов безопасности). Это представители команд разработчиков, архитекторов или подразделения эксплуатации. Они выполняют роль security-проводников в своих командах, им интересна сфера ИБ, они дополнительно прокачивают себя в ней, делятся знаниями с коллегами и, таким образом, «располагают» их к безопасности. Иными словами, это люди-агенты команды security, «вербующие» в ИБ членов других подразделений, учитывая при этом необходимую глубину погружения.
Внедрить практику Security-чемпионов непросто, но компании поможет творческий подход. Можно придумать активности или награды, которые будут мотивировать людей этим заниматься. Например, назначить премию или пообещать отправить в интересную командировку.
Построение процессов
В больших компаниях, которые давно занимаются наращиванием зрелости своих процессов, встречаются ситуации, когда тома разного рода инструкций четко структурированы, написаны «красиво» и доступно, но проблема в том, что они не работают. То, что изложено на бумаге, не соответствует тому, что существует в жизни. Бывают и другие проблемы, когда не видно взаимодействия, то есть процессы не формализованы, не описаны в регламентах, нигде не закреплены.
Описанием процессов важно заниматься, но не нужно писать огромные тома документации. Будет достаточно плейбуков, коротких и понятных памяток, которые рассказывают, где и чья зона ответственности, как и по какому каналу связи обратиться в Application Security. Тогда этот инструмент будет эффективен и сможет облегчить жизнь командам.
Когда мы строим процессы, то опираемся на ряд фреймворков BSIMM, OWASP SAMM, Open SAMM, регламенты семейства ГОСТ Р и другие. Рассмотрим наш подход с использованием этих методологий на примере внедрения статического анализатора в рамках ожидания и реальности.
Ожидание. Да что там внедрять?! Выбираем инструмент, покупаем его, тиражируем на всю кодовую базу — и всё. Но так не работает.
Реальность. Вместо трёх шагов нам приходится сделать, например, порядка 30. Это определение целей, формирование тестовой команды, настройка правил, снижение показателя False Positive, тиражирование, постепенное изменение Quality Gates и много-много других вещей, без которых невозможно получить хороший результат.
Важность оркестрации
С помощью решений класса ASOC (Application Security Orchestration and Correlation) можно управлять инструментами Application Security, отслеживать метрики, коррелировать данные. Продукты, реализующие практику ASOC, позволяют максимально бесшовно (насколько это возможно) внедрить практики AppSec в существующие процессы компании.
Предпосылкой необходимости таких инструментов является то, что DevOps-ландшафт динамично развивается и становится всё сложней. Растет количество так называемых точек контроля (Quality Gates), и мы должны быть убеждены, что наш объект (код, артефакт), собранные приложения, библиотеки безопасны и соответствуют всем требованиям. Но при усложнении DevOps-ландшафта становится труднее автоматизировать практики Application Security.
Существует много примеров, когда компании пытаются делать это отдельными кусками, то есть реализуют «лоскутную» автоматизацию. Такой подход приводит к бесконечным проектам с привлечением внутренних и внешних ресурсов. Основная проблема заключается в том, что здесь нет единого окна, идеологии, инструмента, вокруг которых нужно начинать работу. Поэтому рекомендуем подход, в рамках которого используются решения, реализующие практику ASOC, они позволят оперативно встроить практики AppSec в DevOps и автоматизировать их работу.
ASOC
Так что же из себя представляют инструменты класса ASOC? В них входят три домена — это оркестрация, корреляция и аналитика.
Оркестрация
Рассмотрим этот домен сразу с точки зрения задач, которые он реализует. Подключить все сканеры с необходимыми правилами для конкретных команд. Наладить их взаимодействие с кодовыми базами, хранилищами артефактов и так далее. Настроить отслеживание изменений юнитов и объектов в этих базах. Определить точки контроля качества ПО на разных стадиях разработки. Запустить ИБ-пайплайны. — Всё это выполняется в рамках оркестрации.
Корреляция
Далее мы видим весь процесс в рамках одного окна. Сканеры ищут уязвимости, и мы можем работать с ними в контексте домена «Корреляция».
В рамках корреляции инструменты подтверждают уязвимости и исключают ложные срабатывания. Второй большой блок на этом этапе — группировка и определение корневых уязвимостей. Сканеры порой говорят об одних и тех же проблемах, но на разных языках. Здесь важно понимать, какая корневая уязвимость позволит убрать как можно больше срабатываний. Ещё здорово, если в инструментах класса ASOC есть какая-то матмодель, которая позволяет подсветить вероятность, где фоллс, а где реальное срабатывание.
Также важно сказать о двусторонней интеграции с баг-трекер системами. Сканеры отработали, выдали в единое окно весь список срабатываний. Мы отметили, что из этого является реальными проблемами. Дальше всё это уходит в баг-трекер систему в формате задачи для разработчиков на устранение уязвимостей. Здесь необходимо наладить двустороннюю синхронизацию, чтобы было понятно, действительно ли задача закрыта, будет ли подтвержден ее результат при следующем сканировании. Это также входит в задачи корреляции.
Аналитика
С помощью метрик можно объяснить себе как заказчику внутри компании, руководству и в целом командам, как развивается процесс безопасной разработки. Это позволит оценить эффективность работы в направлении ИБ и наладить управление процессом. Можно измерять всё: покрытие кодовой базы, плотность дефектов, время на их устранение, NTTR и прочие вещи. Инструменты класса ASOC позволяют это делать.
DevSecOps — платформа как Сервис
В нашей практике была вот такая ситуация. Октябрь, Q4 (начало самого главного периода продаж), высокая загруженность. И тут звонок от очень уважаемого клиента: «Всё пропало, руководство сказало нам, что у всех уже есть AppSec, а у нас нет. Надо, чтобы к концу года всё было. Можно ли так?» На самом деле можно. Но как к этому подступиться?
Если появляется задача для быстрого старта и максимально оперативного тиражирования практик Application Security, то на большую раскачку времени нет. Формирование внутреннего центра компетенций, подбор всех необходимых инструментов, пилотирование на разных командах — это правильный подход, но он занимает месяцы и порой годы.
В рамках быстрого старта можно внедрять DevSecOps в формате сервиса. Существуют экспертные команды, у которых уже есть понимание, какие инструменты для каких кодовых баз стоит использовать. Эти продукты уже развёрнуты во внутренних лабораториях, и чтобы быстро внедрить процесс безопасной разработки, можно привлечь на аутсорс такую команду. Она придёт со своим инструментарием, с базовыми документами и сразу начнёт тиражировать практики AppSec. И самое главное — эти специалисты разберут результаты, предоставленные командой компании и выдадут то, что уже реально срабатывает. Но стоит отметить, что быстрый старт стоит дороже, чем плановый подход.
Подход к реализации DevSecOps Paas-сервиса
Открыли все доступы для размещения платформы, подключили к ней команду разработки, перевели ее в промышленную эксплуатацию, дали необходимый доступ к сканерам и договорились о составе работ SLA — всё. То что нужно для быстрого старта. В нашей практике был довольно крупный клиент с несколькими тысячами разработчиков. Так вот, команда Swordfish Security вела его всего чуть больше трёх лет.
Но в рамках работ по внедрению DevSecOps, можно нарваться на коварную проблему. Компания заплатила за построение процесса безопасной разработки, получает услугу должного качества, но не наращивает внутреннюю экспертизу, не нанимает людей, не вникает в новые задачи. Это может привести к тому, что организация «подсядет» на внешнего провайдера и будет зависима от него, что приведет к дополнительным тратам.
Когда команда Swordfish Security пришла к клиенту, упомянутому выше, у него не было почти никаких инструментов Application Security. При огромном объёме кода за первый год удалось покрыть более 12% основными практиками — статикой, динамикой, внедрить оркестрацию, наладить работу с метриками. К 2021 году появилась динамика веб-приложений, а к 2022-му — все остальные практики, включая анализ микросервисной инфраструктуры. Покрытие кода составило 31% — это миллионы строк в рамках данного кейса.
На этом проекте произошла очень хорошая вещь. Параллельно, пока команда Swordfish Security выступала в роли аутсорсингового AppSec-отдела в компании и помогала ей тиражировать, внедрять практики безопасности, клиент наращивал внутренние компетенции.
Постепенно компания начала брать на себя операторство платформы безопасной разработки, редактировать документы, проводить митапы для своих внутренних команд. Со временем клиент перестал сотрудничать со Swordfish Security в большом объёме, потому что он уже сам мог выполнять практически все задачи. Компания нуждалась только в точечных консультациях по сложным вопросам.
В начале данного проекта плотность дефектов была колоссальная, но целевая очень даже хорошая. Вероятно, дойти до такой стадии, чтобы уязвимостей не существовало вообще, невозможно, но снизить плотность дефектов до минимума получится — и это важная цель.
Что касается технического долга, команда Swordfish Security за три года разобрала весь его объем. Когда инструменты Application Security только внедряются, техдолг будто бы летит из-за этого на луну. Но на самом деле, он был таким большим, просто теперь его подсветили в явном виде. На средних дистанциях видно, как этот всплеск значительно снижается и достигает некоторого плато. Конечно, с новым кодом техдолг будет снова расти из-за уязвимостей. Но этот показатель должен быть разумным, адекватным, чтобы объем не копился, а его можно было вставлять в релизе.
Как определить готовность компании к внедрению Application Security и DevSecOps?
Существует немало фреймов, в которых есть maturity models. С помощью готовых анкет возможно самостоятельно или с привлечением внешних аудиторов понять, на каком этапе зрелости сейчас находится компания. Можно составить круговую диаграмму по восьми ключевым векторам развития в области безопасности. Это позволит увидеть, что на данный момент не применяется в организации, что актуально и уже используется. Также можно сформировать дорожную карту и, опираясь на нее, двигаться вперёд.
Кто же всё-таки важнее — Dec, Sec или Ops?
DevSecOps объединяет разработку, эксплуатацию и безопасность. Часто возникает вопрос: какой из этих блоков важнее? Для начала разберемся, что волнует больше всего каждое из этих подразделений.
Разработка. У нас горят сроки, KPI! И вообще, вице-президент не получит бонус, если мы не выпустим это до такого-то числа.
Эксплуатация. Да вы с ума сошли! Нельзя выпускать столько новых функций, мы их полноценно не протестировали. Это не будет работать, мы не выдержим столько запросов от клиентов.
Безопасность. Самое главное, чтобы всё было безопасно.
Таким образом, в этом трио нельзя выделить что-то одно. Здесь все важны. В целом DevSecOps — это процесс, формирующий из разрозненных подразделений единую команду, стремящуюся сделать продукт лучше.
Выводы
Сегодня DevSecOps уже не какая-то новомодная тенденция, без которой можно спокойно обойтись. В современных условиях практики процесса обязательны к применению для всех, кто так или иначе имеет отношение к разработке ПО. Важно только определиться, в каком объёме их внедрять. Любой инструмент не silver bullet, поэтому при его встраивании важно думать о людях и существующих процессах компании, а также о возможностях их взаимодействия между собой.
Перед тем, как начинать строить процесс безопасной разработки, важно оценить уровень зрелости компании, понять, на каком этапе развития она находится и чего хочет достичь, а потом уже можно внедрять инструменты. Сегодня киберугрозы активно развиваются, и с этим нельзя ничего поделать. Но можно укреплять свои позиции и пробовать идти на опережение. С этим помогут технологии оркестрации и сформулированные метрики оценки эффективности процесса, они позволят внедрять новые практики и анализировать прогресс, то есть держать таким образом «руку на пульсе».
Кроме этого, нужно развивать внутреннюю экспертизу: обучать сотрудников, внедрять практику Security-чемпионов. Без необходимых компетенций специалистов компания не сможет вырваться вперед. А если команда пока не обладает нужными знаниями, и организации нужно срочно внедрить практики безопасности, всегда можно привлечь внешних специалистов и с их помощью выстроить все процессы, в том числе связанные с обучением сотрудников.
24 ноября начнется крупнейшая профессиональная конференция для разработчиков высоконагруженных систем Highload ++, там будет секция DevOps. Если у вас не получилось попасть туда оффлайн, то благодаря нашему генеральному партнеру 1С, вы можете сделать это онлайн. Подключайтесь к открытой трансляции Главного зала конференции.
Если сами хотите выступить, то еще можно подать на cfp.devopsconf.io. Даже если никак не получается выбрать тему, но есть классная идея выступления основанная на реальном опыте. Подавайте заявку с темой «помогите выбрать доклад» и мы поможем.
