Количество ИБ-инцидентов непрерывно растет с каждым годом. Это предъявляет дополнительные требования к защищенности используемых сервисов и стало драйвером для развития методологии DevSecOps (Development, Security, Operations), согласно которой проверки кода на уязвимости — неотъемлемый этап разработки ПО. Поэтому все чаще компании применяют различные решения для безопасной разработки.

Меня зовут Игорь Игнатьев. Я руководитель направления защиты приложений в VK. В этой статье я расскажу о типовых потребностях команд разработки и ИБ в контексте создания безопасных приложений и познакомлю с решением для автоматизации проверок безопасности кода от VK Cloud.

Типовые потребности команд разработки и ИБ

В контексте информационной безопасности у команд, создающих продукты и сервисы, потребности отличаются в зависимости от их зоны ответственности. 

Так, со стороны IT-вертикали:

• тимлидам важно иметь возможность быстро получить общее состояние здоровья продукта, учитывая текущие дефекты; 

• разработчики, создавая исходный код, нуждаются в простом доступе к информации о его безопасности в созданных приложениях;

• DevOps-инженеров больше интересует окружение, в котором приложения будут запущены, и уязвимости, привнесенные в контейнеры.

В свою очередь, у команды ИБ смежные задачи:

• CISO/BISO проводят overview безопасности всех продуктов;

• AppSec отвечают за контроль безопасности продукта и триаж уязвимостей;

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

Нюанс в том, что классически команды разработки и ИБ решают схожие задачи – «сделать успешный и безопасный продукт», но работают независимо, что зачастую создает разрыв между подразделениями и не позволяет выстроить прозрачный процесс создания ПО. Решения для безопасной разработки устраняют эту дистанцию, объединяя разработку и проверки безопасности в единый автоматизированный процесс. 

Запрос команды VK

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

• множество языков программирования: Java, PHP, C#, Go, Python, Scala, JS/TS, Ruby и другие;

• множество технологий: GitLab, GitLab CI, Bitbucket, Jenkins, SVN, Team City, самописные системы;

• разные производственные процессы: релиз из master, релиз из daily-веток, on-prem релизы и другие.

При этом нам было важно, чтобы разрабатываемое решение позволяло:

• обеспечить полное покрытие всей кодовой базы: 40 тысяч репозиториев в VK и более 1 млрд строк кода;

• подключаться к проектам максимально быстро (через встраивание в CI/CD, автосканирование из VCS или с помощью API);

• исключить зависимость от конкретного анализатора, чтобы иметь возможность подключать новые анализаторы plug&play без изменения окружения;

• снизить затраты на анализ.

Ответом на эти запросы стала разработка Security Gate.

Знакомство с Security Gate

Security Gate — платформа, которая позволяет автоматизировать проверку безопасности кода в процессе разработки. Решение помогает найти уязвимости в коде и ошибки, которые могут влиять на безопасность разрабатываемого ПО. 

Security Gate консолидирует возможности анализаторов разного типа, что позволяет ему решать большой пул задач, среди которых:

• сканирование контейнеров;

• анализ уязвимостей в библиотеках;

• анализ исходного кода;

• динамический анализ;

• выявление секретов в репозиториях.

Для покрытия всей имеющейся кодовой базы и автоматической проверки нового кода в репозиториях Security Gate получил поддержку нескольких видов интеграций:

• API. Интеграция через API оптимальна, когда нет CI/CD и системы контроля версий, а есть только код, который нужно проверить, либо если нужны кастомные процессы проверки.

• CI/CD Client. Интеграция через CI/CD Client позволяет реализовать традиционный подход, встроить проверку в пайплайн разработки.

• GitLab WebHooks. Подключение через GitLab WebHooks работает несколько иначе. В этом случае любой коммит в VCS проверяется на наличие закрытых ключей, токенов и паролей.

• GitLab (full Inventory). Этот вариант подразумевает полную интеграцию с системой контроля версий.

Например, в случае полной интеграции Security Gate с системой контроля версий реализуется удобный для ИТ и ИБ процесс:

• Security Gate автоматически подключается к инстансу GitLab;

• происходит автоматическая инвентаризация всех существующих и создаваемых репозиториев;

• выполняется регистрация всех репозиториев в Security Gate;

• подключается автоматическое сканирование всех репозиториев по расписанию;

• всем участникам репозитория назначаются права доступа к результатам анализа.

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

«Под капотом» Security Gate: технические аспекты работы

Чтобы проверка кода на уязвимости была не только эффективной, но и рациональной с точки зрения затрат, в Security Gate реализована и доступна:

• кроссветочная обработка результатов;

• приоритезация уязвимостей. 

Кроссветочная обработка результатов

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

В Security Gate эта проблема решена, поскольку: 

• реализован специальный механизм дедупликации для режима кроссветочного триажа;

• все уязвимости по сканированным веткам можно посмотреть в одном месте;

• вердикт по уникальной сработке указывается 1 раз в рамках кроссветочного триажа (выявленную проблему достаточно отработать один раз).

Приоритезация уязвимостей

Множество анализаторов переоценивают критичность обнаруженных дефектов в коде. Это приводит к проблеме «мусорного» срабатывания на уровнях High+ и скрывает наиболее значимые результаты. Более того, это смещает фокус разработчиков и ИБ-специалистов.

В свою очередь, Security Gate выполняет:

• приоритезацию правил SAST;

• оценку критичности CVE;

• динамическую приоритезацию Secret.

Такой комплексный подход позволяет приоритезировать уязвимости более точно и снизить количество фиксируемых High и Crit уязвимостей, оставив на этом уровне критичности только значимые для безопасности приложения результаты.

Здесь важно, что Security Gate не подразумевает, что High и Crit уязвимости, которые ошибочно определяют другие приоритезаторы, удаляются или игнорируются. Просто за счет правильного ранжирования их приоритет снижается, позволяя команде сфокусироваться на устранении более критичных проблем.

Процесс сканирования

В Security Gate процесс сканирования подразумевает несколько этапов и сводится к простому алгоритму.

• При инициализации сканирования любым из методов (API, CI/D, инвентаризация) Security Gate запускает разбор приложения на используемые технологии (из чего состоит, какие языки используются и не только).

• Следующим шагом проводится динамический выбор инструментов сканирования.

• Далее запускается сканирование. Примечательно, что код проверяется сразу несколькими анализаторами. Это могут быть как несколько SAST-анализаторов, так и несколько инструментов обнаружения секретов, поиска уязвимых зависимостей.

• Затем проводится дедупликация зависимостей между сканерами и ветками, а также кросс-веточная дедупликация. Такой многослойный подход позволяет найти и сгруппировать все идентичные уязвимости, чтобы сделать их устранение удобнее для разработчиков и специалистов по ИБ.

От теории к практике: как работать с Security Gate 

Теперь перейдем к обзору возможностей Security Gate.

Платформа доступна в личном кабинете VK Cloud, в разделе «Сервисы безопасности».

Сейчас на платформу загружено несколько предварительно подготовленных, уязвимых репозиториев, на которых можно протестировать возможности инструмента.

Чтобы посмотреть детальную информацию по каждому репозиторию, можно выбрать любой из них.

Здесь все выявленные уязвимости будут собраны и отсортированы по типам:

• SAST;

• Secrets;

• SCA.

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

Также можно изучить подробную информацию о проблеме.

И узнать, что по поводу найденной уязвимости может рассказать подключенная модель LLM.

Здесь же доступен раздел с выявленными секретами. Примечательно, что информация о секретах дополнительно «затирается», чтобы не «светить» чувствительные данные даже в интерфейсе.

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

Для реагирования на каждую из уязвимостей пользователям доступно несколько операций. Так, можно:

• подтвердить срабатывание;

• отклонить срабатывание и указать причину отклонения;

  

• подтвердить исправление (если проблема исправлена, при следующем сканировании срабатывание закроется автоматически);

• оставить комментарий;

• увидеть, в каких ветках встречается уязвимость;

  

• посмотреть версию, историю, задачу в Jira и не только.

Помимо этого, в рамках теста пользователи также могут просканировать свой проект.

Для этого достаточно перейти в Security Gate, выбрать раздел «Мой проект» и нажать «Добавить».

Здесь надо указать название проекта, загрузить ссылку на репозиторий или архив с проектом. 

Время сканирования зависит от размера проекта и количества кода. Но, например, на сканирование небольшого проекта достаточно 5 минут.

Что в итоге

Благодаря возможностям Security Gate можно решать многие задачи команд, занимающихся разработкой ПО и выстраивать DevSecOps процессы, необходимые вашей организации. Например, платформа подойдет, когда:

• в компании есть in-house разработка;

• компания в процессе внедрения или улучшения практик DevSecOps;

• у команды есть сложности в масштабировании практик безопасной разработки во всех проектах;

• есть запрос на внешнюю экспертизу, методологии, лучшие практики;

• необходим выбор инструментов для разнородной кодовой базы;

• рассматривается привлечение продуктовых команд к совместной с ИБ работе над безопасностью кода.

При этом демо-версия Security Gate уже доступна всем пользователям VK Cloud, а первые сканирования ПО с помощью Security Gate бесплатны в рамках лимитов на каждый проект.