Безопасная разработка с нуля: опыт «LADA Цифра»

Почему безопасная разработка перестала быть опцией

Как вы пришли к безопасной разработке ИТ-продуктов в компании?

Наша компания была основана в 2023 году, а уже через год вышел профильный ГОСТ по безопасной разработке, представляющий собой полноценный чек-лист. В этом смысле «LADA Цифра» оказалось проще, чем другим компаниям. Отсутствие легаси и старого кода, который нужно переделывать под новые требования, упростило заход в безопасную разработку.

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

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

Ещё пять лет назад объяснить бизнесу важность этого направления было очень сложно. Но развитие систем оркестрации процессов безопасной разработки (платформ ASOC) позволило более наглядно показать, из чего DevSecOps состоит. Кроме того, как я уже говорил выше, вмешались регуляторы — появился соответствующий ГОСТ. Стало проще демонстрировать, что дефект исправлять выгоднее сразу, чем после выхода релиза.

Уже и во многих тендерах появились требования чётко указывать подтверждение наличия процесса безопасной разработки. Заказчики просят предоставить рекомендательные письма и артефакты. Так что сегодня соответствие требованиям безопасной разработки становится рыночным условием.

Какая доля в безопасной разработке отдана ИИ в вашей компании и как вы контролируете этот процесс и связанные с ним риски?

Мы уже используем ИИ для проверки качества кода и код-ревью. Кроме того, наша компания совместно с партнёрами приступила к созданию полноценной ИИ-платформы. Так что роль ИИ в процессах разработки будет увеличиваться.

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

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

Безопасная разработка в новых реалиях

Как повлияла на безопасную разработку недоступность некоторых иностранных сервисов? Вы сталкивались с проблемами из-за этого?

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

Какие существуют альтернативы для создания безопасного софта внутри компании?

Не стоит искать альтернативы. Если изучить ГОСТ, то оказывается, что около 80% требований реализуются на базе open-source-решений. Важно провести инвентаризацию активов и продуктов, убедиться, что код централизован (не разбросан по нескольким репозиториям), и настроить ролевую модель.

ГОСТ позволяет начать процесс прямо сейчас и получить результат. Коммерческие решения дают больше удобства и упрощают внедрение (например, настройку policy gate), но оценить их можно только после того, как процесс будет испробован на бесплатных инструментах.

Как изменился подход к безопасной разработке за последние два-три года в условиях развития атак на цепочку поставок?

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

Возвращаясь к теме использования ИИ для написания кода: объём кода, сгенерированного с использованием LLM, огромен, и он часто тянет за собой не всегда безопасные библиотеки. Попадая в собственные репозитории, такой код упрощает реализацию атак через цепочки поставок. По сути, каждая модель ИИ выполняет работу подрядчика: ей даётся техническое задание, она выдаёт результат. Эта аналогия вполне работает.

А как был скорректирован ваш подход в связи с новыми требованиями регуляторов, которые возникли в последние несколько лет?

Наша компания не является объектом КИИ. Основное регуляторное давление связано со 152-ФЗ, поскольку разрабатывается b2c и B2B-платформа. Риски, связанные с персональными данными, остаются прежними, но их актуальность растёт.

В требованиях 152-ФЗ нет указаний на организацию безопасной разработки. Дополнительные требования возникают именно при продаже решений — в тендерах появляется необходимость наличия процесса. Также появилась сертификация (лицензирование) по новому ГОСТу.

У нас есть отдельное направление по управлению персональными данными и актуализации локальных нормативных актов. Основной продукт — маркетплейс, поэтому для нас защита клиентских данных сразу стала приоритетом. Есть интеграции с банком в контуре фрода. Цель — единая клиентская платформа. Наибольший осязаемый риск — репутационный, связанный с утечкой личных данных. Поэтому это направление сразу закрепили функционально.

ИТ + ИБ

Какую долю от ИТ-бюджета на ИБ вы бы рекомендовали выделять?

В среднем по рынку это около 10-20% от общего ИТ-бюджета. Но численно специалистов ИБ значительно меньше, чем разработчиков. Нужно учитывать, что несмотря на это, ИБ-команды обеспечивают защиту всей инфраструктуры, продуктов и всех процессов компании. Так что расходы на ИБ не должны быть пропорциональны численности сотрудников подразделения. Небольшая команда ИБ зачастую требует дорогостоящих средств защиты, мониторинга, аудита, тестирования и соответствия требованиям регуляторов. Бюджет на безопасность должен быть соразмерен значимости других ИТ-направлений и рассматриваться как обязательная часть инвестиций в технологии.

Как построить процесс безопасной разработки без сопротивления ИТ-команды?

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

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

Чем вы измеряете это «лучше или хуже»?

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

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

К чему стоит стремиться, так это к настройке policy gate, когда релиз блокируется до устранения уязвимости. Но если процессы создаются с нуля, даже бесплатные инструменты дадут огромный бэклог. Учтите, что нельзя запустить жёсткие политики сразу — так вы рискуете остановить работу компании. К высоким требованиям нужно идти постепенно.

По каким метрикам можно судить, безопасная ли разработка продукта?

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

На самом деле основная метрика — время устранения дефектов. В неё укладываются и софт-скиллы, и кросс-командное взаимодействие. Именно эта метрика показывает, удалось ли выстроить работу с командой разработчиков.

На начальном этапе, когда процесс только строится, показатели не будут укладываться в установленные сроки (два, три, семь дней). Пугаться этого не стоит.

Как организована ваша команда и где вы берёте кадры?

В нашей команде безопасной разработки четыре человека, включая лида. Основной источник кадров — коллеги, занимающиеся аудитом ИБ и пентестами. Они знакомы с инструментальным анализом, работали с опенсорсными инструментами, что-то дописывали под себя. Дефекты и уязвимости для них — привычная область.

К тому же пентесты мы проводим силами собственного подразделения аудита. «LADA Цифра» выступает центром ИБ-обеспечения для ряда дочерних обществ АвтоВАЗа. Мы понимаем все преимущества взгляда со стороны сторонних команд, но качественный аудит дорог, и это сейчас недоступно для нашей отрасли. А заказывать плохой не хочется.

Возвращаясь к теме ИИ, какие уроки прошлого может взять на вооружение современный кибербез?

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

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

По вашему мнению, как изменилась российская киберкультура за последние годы?

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