СофтХабрахабр

Как внедрить статический анализатор в разработку, чтобы всем было хорошо?

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

Что предстоит?

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

Какие бывают возможности по интеграции?

Обычно анализатор предполагает неграфический интерфейс (CLI, REST) для интеграции в любой процесс. Есть анализаторы с готовыми интеграциями: со средствами сборки и средами разработки, с системами контроля версий (Git, SVN), серверами CI/CD (Jenkins, TeamCity, TFS), системами управления проектами (Jira) и управления пользователями (Active Directory). Чем больше полезного для вашей компании, тем легче будет всё настроить.

Как можно построить процесс?

Рассмотрим стандартную ситуацию: в процессе участвуют отделы информационной безопасности, управления релизами и разработки. Как правило, заказчиком внедрения анализатора является информационная безопасность (ИБ). Задача — договориться, кто, когда и что будет делать. Мы выделяем следующие шаги: запустить анализ, обработать результаты анализа, создать запрос на исправление уязвимости, исправить уязвимость, проверить исправление. Рассмотрим каждый шаг подробнее.

Шаг 1. Запустить анализ

Запускать анализ можно вручную или автоматизированно. У подходов есть свои плюсы и минусы.

Вручную

Сам вспомнил про анализатор, сам загрузил код, сам пошёл и посмотрел результаты.

image

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

Автоматизированно

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

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

Например, в момент создания запроса на слияние с основной веткой или при изменении статуса задачи по данной ветке. Если над кодом работают много людей, создано много веток, часто вливаются изменения — лучше анализировать часто, но при этом не мешать разработке. Интеграция с CI/CD позволит сделать анализ одним из шагов сборки. В этом вам поможет интеграция с системой контроля версий или с системой управления проектами.

Настройте расписание так, чтобы вы успевали обрабатывать результаты.

Шаг 2. Обработать результаты анализа

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

Отсортируйте уязвимости по критичности, по языкам, файлам и директориям. Используйте фильтры. Фильтры применили, но уязвимостей всё ещё много? Более продвинутые инструменты покажут вам уязвимости только в новом коде, скроют уязвимости в сторонних библиотеках.

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

image

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

Шаг 3. Создать запрос на исправление уязвимости

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

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

Форма запроса

А для подзадач и багов используются, к примеру, GitLab Issues, доступ к которым есть только у тимлида и его группы. Есть компании, в которых большие задачи на этап фиксируются в системе управления проектами (например, Jira). У анализатора могут быть интеграции, с помощью которых вы сможете создавать нужные запросы сразу в интерфейсе. Бывает и так, что сборка невозможна без создания отдельной задачи в системе управления проектов.

И нужно подстроиться подо всех. Часто внутри одной компании с многочисленными группами разработки для каждой из них установлен свой порядок реализации рабочих задач. Возникают вопросы:

  • А стоит ли выделять под исправление уязвимостей отдельный проект или создать задачи в существующих?
  • Уязвимость — это знакомый всем «баг» или новая сущность?
  • Создавать для каждой уязвимости отдельную задачу или сгруппировать похожие?
  • Что привести в качестве описания задачи: ссылку на уязвимость в интерфейсе анализатора или на место в коде и кратко описать проблему?
  • Да и нужен ли разработчику доступ к результатам — просто отправить PDF-отчёт с текстом «см. стр 257» и хватит?

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

Обычно для отчёта можно отобрать интересные вам уязвимости и сразу отправить на нужный адрес из интерфейса анализатора. Если код пишут подрядчики, для которых доступ во внутренние системы минимален, подойдёт схема с PDF-отчётом.

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

Трудозатраты и сроки

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

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

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

Шаг 4. Исправить уязвимости

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

Исправлять уязвимости в процессе разработки — идеальный сценарий. Есть два сценария: исправлять сразу в процессе разработки или по запросу от офицера безопасности. Разработчик сканирует свою feature-ветку перед запросом на слияние с основной веткой. Сразу нашёл — сразу исправил. Это тоже можно автоматизировать с помощью интеграций: со средой разработки, со средствами сборки, системой контроля версий или с CI/CD.

Офицер безопасности или тимлид просматривает результаты и создаёт задачи на исправление уязвимостей. Другой сценарий — анализировать основную ветку разработки после всех изменений. На входе у разработчика — исходный код, задача на исправление и результаты анализа. Этот сценарий более трудоёмкий. Для разработчика задача на исправление уязвимости мало отличается от устранения бага.

Шаг 5. Проверить исправление

Нужно убедиться, что уязвимость действительно исправлена и на её месте не возникла новая. Есть результаты анализа исправленного кода. Что искать? Файл и номер строки, в которой была уязвимость? Или поискать по названию уязвимости? Можно и так. Но если код был изменён, строка с уязвимостью могла сместиться, а вхождений одной уязвимости может всё ещё быть много. Некоторые анализаторы могут показывать «устранённые» уязвимости. Согласитесь, так проверить исправление уязвимости можно быстрее (см скриншот).

image

Примеры

Приведём два возможных сценария.

Сценарий 1

Команда использует Git для контроля версий, Jira — для управления проектами и задачами. С помощью Jenkins настраивается расписание сборки. Например, раз в сутки при наличии изменений в ветке. В качестве дополнительного шага указывается запуск анализатора.

Офицер безопасности просматривает результаты анализа основной ветки (master или development), разработчики — своих feature-веток.

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

С помощью интеграции с Jira офицер безопасности создаёт задачи по устранению уязвимостей из интерфейса анализатора. Офицер безопасности просматривает результаты анализа основной ветки. Далее — согласование сроков и приоритетов.

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

Сценарий 2

Код для компании пишет группа подрядчиков. Тимлид взаимодействует с разработчиками по электронной почте и использует GitLab для контроля версий. Доступа ко внутренним системам управления проектами (Jira) у подрядчиков нет.

Доступа к анализатору у подрядчиков нет. Офицер безопасности или сам тимлид просматривают результаты анализа основной ветки разработки. Если есть уязвимости, которые нужно исправить, офицер безопасности отправляет PDF-отчёт с результатами анализа тимлиду или сразу разработчику.

Ценно, если для уязвимостей, связанных с потоком небезопасных данных (например, SQL-инъекция), в отчёт будет выгружаться схема распространения: от источника данных к их использованию в вызове функции/метода (см. Из отчёта разработчик узнает, где найдена уязвимость, в чём состоит и как можно исправить. скриншот).

image

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

Что ещё важно?

Наладить взаимодействие между ИБ и разработкой. Важно, чтобы обе стороны были заинтересованы в исправлении уязвимостей. Хорошо, если это будут не только запросы, но и живое общение.

У хорошего анализатора должна быть возможность разграничения прав. Не пренебрегайте ролями пользователей. Редактировать результаты — изменять критичность и статус — достаточно разрешить офицеру безопасности и тимлиду. Вряд ли подрядчику понадобятся права администратора или результаты анализа внутренних систем. Принцип минимальных привилегий никто не отменял.

Вы сможете переиспользовать принятые в компании роли и группы и выдавать им нужные права. Если компания большая и применяет систему управления пользователями (например, Active Directory), рассмотрите инструменты с готовой интеграцией.

Вывод

После выбора анализатора подготовьтесь к тому, что его ещё нужно правильно внедрить. Не бойтесь встреч и согласований с участниками: чем лучше вы разберётесь в процессе, тем полезнее будет результат. Важно, чтобы сценарий работы не только утвердили, но и начали ему следовать.

Автор: Елизавета Харламова, ведущий аналитик Solar appScreener

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть