Максим Козлов, GitFlic: «РБПО нужно начинать с построения процессов»

— Максим, с помощью каких инструментов, методологий, правил сегодня организована «правильная» разработка ПО? Достаточно ли их для того, чтобы создавать безопасные продукты?

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

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

Процессы усложняются, возникает потребность в автоматизации. Значит, команде нужно иметь четко регламентированный процесс, в котором описан каждый этап, а в каждом этапе описаны его шаги. В рамках разработки программного обеспечения для построения автоматизации за это отвечает конвейер CI/CD (Continuous Integration – Continuous Delivery/Deployment). Существует множество инструментов, которые помогают его реализовать: средства компиляции, автотестирования, сканирования на уязвимости и другие. Они начали широко применяться в начале-середине 2000-х годов, когда технологии достигли определенного уровня зрелости и у разработчиков появилась возможность создания и масштабирования веб-сервисов.

Немногим позже появился термин DevOps (Development & Operations). По сути, программисту всё равно, что будет с его кодом после того, как он его скомпилировал. Он, как художник, написал то, что посчитал нужным и красивым, код работает, а кто и с какой целью будет запускать это приложение, его не интересует. DevOps появился на стыке эксплуатации и разработки – как ответ на эту проблему: системные администраторы попытались ближе взаимодействовать с разработчиками, рассказывать про свои задачи и проблемы, а разработчики начали их слушать. Соответственно, через автоматизацию развертывания и конвейер CI/CD это удалось сделать: ПО стало лучше отвечать требованиям и системных администраторов, и конечных потребителей.

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

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

Соответственно, по аналогии с DevOps возникло понятие DevSecOps (Development & Security Operations), подразумевающее более тесное и прозрачное взаимодействие специалистов по ИБ с разработчиками, наличие инструментов, которые позволят ИБ-специалисту влиять на разработчика, не позволяя тому выкатывать код прежде, чем он устранит все выявленные уязвимости.

Я считаю, что DevOps и DevSecOps – это не методологии и даже не подходы, а внутренняя культура компании. Условно говоря, если в компании разработчики, системные администраторы и безопасники дружат – культура есть, а если не дружат – нет. Это было всегда, просто в определенный момент этому придумали название.

Технический директор GitFlic Максим Козлов
Фото: «Группа Астра»

— Какие в России были предпосылки к регулированию процессов разработки и к появлению стандартов РБПО?

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

Я, например, как преподаватель программной инженерии, объясняю ребятам на втором курсе, что для того, чтобы выполнить запрос в базу данных с параметрами, нельзя передавать эти параметры напрямую в сырой SQL-запрос, а необходимо пользоваться специальными функциями передачи параметров, которые предоставляет драйвер для БД, – иначе открывается прямой путь для SQL-инъекции. Или говорю о том, что нужно обязательно обрабатывать ошибки в написанном коде, потому что иначе в ходе эксплуатации приложения злоумышленник сможет это приложение выключить и остановить бизнес-процесс. И если такие правила повторять изо дня в день, они глубоко закрепляются в подсознании.

Семь-восемь лет назад в России начался всплеск цифровизации всех отраслей экономики, банки пошли в Бигтех. Разработчики сосредоточились на скорейшем выводе продуктов на рынок (time to market). Соответственно, резко подскочил спрос на ИТ-специалистов, они нужны были всем прямо сейчас и в большом количестве. Как следствие, появились многочисленные краткосрочные курсы подготовки ИТ-кадров, после которых за три месяца бывший курьер или менеджер вдруг становился серьезным разработчиком.

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

Ситуация усугубилась в 2022–2023 годах, когда многие квалифицированные ИТ-специалисты уехали за границу, забрав с собой и опыт построения процессов. При этом зарубежное ПО осталось без поддержки и обновлений, а значит, в нем стало появляться всё больше уязвимостей. Заказчики начали переходить на отечественный софт — но оказалось, что уязвимости есть и там. Выяснилось, что отечественное ПО разрабатывается на иностранном стеке.

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

— Можно ли сказать, что РБПО – это некая задокументированная, обязательная культура DevSecOps в компании?

— Я бы не сказал, что РБПО – это культура. Всё-таки это просто свод документов, классический ГОСТ, который описывает те процессы, которые должны быть в компании. Но сами процессы он не описывает. Как я уже говорил, нельзя ничего автоматизировать, если оно не регламентировано.

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

При этом и безопасность в разработке была изначально. Любой опытный разработчик всегда проводит как минимум статический анализ написанного кода. Когда процесс CI/CD развит, это появляется само собой. С точки зрения конвейера разработки для соответствия РБПО у компаний есть все необходимые методологии и инструменты.

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

— Насколько сегодня готова нормативная база, регулирующая РБПО?

— Существующий ГОСТ по РБПО носит, скорее, рамочный характер. Например, в нем утверждается, что разработчики должны сканировать код статическим и динамическим анализаторами, но не указано, как это делать, для чего, где границы этого сканирования. Создается впечатление, что надо сканировать всё, тогда как на практике статический анализатор подходит для Java, C++, C#, C, однако для JavaScript применяется с трудом и местами дает неточные результаты в силу специфики языка. Такие нюансы ГОСТ не предусматривает.

— Какие преимущества получает разработчик от внедрения РБПО?

— Какие преимущества получает разработчик от внедрения РБПО?Процессы РБПО обязаны внедрить, в первую очередь, разработчики, создающие средства защиты информации, компоненты средств защиты, решения для КИИ. Сертификация безопасной разработки от ФСТЭК дает им конкурентное преимущество.

На самом деле для программистов и системных администраторов подходы и инструменты для обеспечения безопасности, прежде всего, помогают более эффективно выполнять свою работу. Например, GitFlic, как часть экосистемы «Группы Астра», придерживается концепции РБПО. Мы понимаем, что этого требует конъюнктура рынка, процессы должны быть регламентированы, внедрены, зафиксированы на бумаге. Но эти же выстроенные процессы у нас были и до этого. Более того, GitFlic – единственная российская DevOps-платформа, разработанная самостоятельно «с нуля». В итоге соблюдение РБПО дает нам не просто спокойствие при разработке: средства РБПО помогают не только обеспечивать безопасность продукта, но и систематически выявлять ошибки и дефекты — а это способствует профессиональному росту всей команды.

— Какие преимущества получает разработчик от внедрения РБПО? Насколько тяжело разработчику перестроить процессы под РБПО?

— Какие преимущества получает разработчик от внедрения РБПО?На самом деле, на уровне конвейера разработки, автоматизации процесса это сделать несложно. Тот же GitFlic позволяет сделать это «из коробки», как и GitLab, Jenkins и другие. CI/CD так или иначе реализован у всех, средства статического, динамического, композиционного анализа, фаззинга применяет каждый разработчик. Даже если у компании нет возможности приобрести коммерческий продукт – существует большое количество проверенных Open Source анализаторов.

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

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

То же самое касается регламентов, которые необходимо описать максимально четко. Не случайно первыми на рынке РБПО внедрили крупные корпорации: у них просто есть достаточное количество персонала, который готов сформировать этот огромный объем документации, проверить ее на непротиворечивость и согласованность.

Информация о том, как разработчику перейти от AS IS к TO BE, частично есть в сети, можно сгенерировать ее с помощью LLM, многим специалистам она знакома, однако какой-то единой инструкции нет. Мы планируем создать такой документ, разработать шаблоны CI/CD под разные языки программирования и выложить в общий доступ.

— Какие преимущества получает разработчик от внедрения РБПО? Насколько меняется рынок разработки и в целом ИТ-рынок с появлением РБПО?

— Какие преимущества получает разработчик от внедрения РБПО?Рынок разработки не сильно меняется: инструменты для разных видов анализа кода появились давно. Более важно то, что отечественные программные продукты действительно становятся всё более зрелыми и качественными, интерес заказчиков к ним растет, и это увеличивает ответственность за их безопасность.

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

Также важно понимать, что РБПО нужно начинать с построения процессов. Если «навесить» множество анализаторов на «дырявый» конвейер CI/CD, РБПО никогда не получится. А вот если выстроить правильный конвейер, то даже без анализаторов основа для РБПО будет положена. Иначе компания просто получит бумажную безопасность: регламенты, которые никогда не будут исполняться теми, кто пишет код.