В процессе работы нам часто задают вопрос: как внедрить статический анализатор в разработку, чтобы всё всем было хорошо. О том, почему для безопасной разработки необходим статический анализатор, мы уже рассказывали. Эта статья будет полезна, если вы выбираете статический анализатор или уже собираетесь его внедрять. Как наладить процесс, чтобы обнаруженные в коде уязвимости стали наконец исправляться? В этой статье мы попробуем помочь вам разобраться с этим вопросом.
Внедрить анализатор так, чтобы уязвимости стабильно исправлялись — дело небыстрое. По опыту можем сказать, что это занимает от пары недель до нескольких месяцев. Если вы внедряете анализатор в крупную компанию, приготовьтесь к череде согласований. Ведь это сотни кодовых баз, которые нужно анализировать, и десятки команд со своими порядками разработки.
Чтобы добавить новый этап разработки — статический анализ, придётся изучить, как устроен процесс у каждой команды, и предложить удобное для всех решение. В небольших компаниях установленного порядка разработки может не быть вовсе. Внедрение анализатора можно сделать поводом для построения процесса. Чтобы интеграция прошла мягче, советуем выяснить, какие у анализатора есть для этого возможности.
Обычно анализатор предполагает неграфический интерфейс (CLI, REST) для интеграции в любой процесс. Есть анализаторы с готовыми интеграциями: со средствами сборки и средами разработки, с системами контроля версий (Git, SVN), серверами CI/CD (Jenkins, TeamCity, TFS), системами управления проектами (Jira) и управления пользователями (Active Directory). Чем больше полезного для вашей компании, тем легче будет всё настроить.
Рассмотрим стандартную ситуацию: в процессе участвуют отделы информационной безопасности, управления релизами и разработки. Как правило, заказчиком внедрения анализатора является информационная безопасность (ИБ). Задача — договориться, кто, когда и что будет делать. Мы выделяем следующие шаги: запустить анализ, обработать результаты анализа, создать запрос на исправление уязвимости, исправить уязвимость, проверить исправление. Рассмотрим каждый шаг подробнее.
Запускать анализ можно вручную или автоматизированно. У подходов есть свои плюсы и минусы.
Вручную
Сам вспомнил про анализатор, сам загрузил код, сам пошёл и посмотрел результаты.
Если проектов в компании около десятка и следить за безопасностью поручено одному офицеру безопасности, такой сценарий возможен. Если проектов около сотни — нужно настраивать автоматизацию.
Автоматизированно
Определитесь, как часто и в какой момент вам нужно анализировать код. Например, перед выходом в продуктивную среду, по заданному расписанию (раз в неделю) или после каждого изменения.
Если приложение обновляется редко, но за его безопасностью тоже нужно следить, настройте анализ при наличии изменений.
Если над кодом работают много людей, создано много веток, часто вливаются изменения — лучше анализировать часто, но при этом не мешать разработке. Например, в момент создания запроса на слияние с основной веткой или при изменении статуса задачи по данной ветке. В этом вам поможет интеграция с системой контроля версий или с системой управления проектами. Интеграция с CI/CD позволит сделать анализ одним из шагов сборки.
Настройте расписание так, чтобы вы успевали обрабатывать результаты.
Не поручайте разработчикам сразу исправить все найденные уязвимости. Пусть сначала офицер безопасности их верифицирует. Результаты первого анализа могут показаться плачевными: десятки критических, сотни менее критичных уязвимостей и тысячи ложных срабатываний. Как тут поступить? Рекомендуем исправлять уязвимости постепенно. Конечная цель — добиться отсутствия уязвимостей как в старом коде, так и в новом. На начальном этапе верифицировать критические (всё же с ними небезопасно) и новые уязвимости (новый код легче исправить).
Используйте фильтры. Отсортируйте уязвимости по критичности, по языкам, файлам и директориям. Более продвинутые инструменты покажут вам уязвимости только в новом коде, скроют уязвимости в сторонних библиотеках. Фильтры применили, но уязвимостей всё ещё много?
Просмотрите наиболее вероятные уязвимости. Есть анализаторы, которые оценивают вероятность ложного срабатывания. Если уязвимостей много, а уровень критичности почти у всех одинаковый, отфильтруйте результаты с использованием этой метрики. Так вы быстрее обработаете самые вероятные уязвимости (см. скриншот ниже).
Используйте статусы верификации. Чтобы зафиксировать результаты верификации, обычно анализаторы предлагают поработать со статусами для уязвимости: подтвердить или отклонить как ложное срабатывание. Как правило, проделанная работа должна сохраняться при пересканировании.
Если разработчик сам запускает анализ своего кода и сразу исправляет уязвимости, то создавать лишние запросы, конечно, не нужно.
Если результаты просматривает и верифицирует офицер безопасности, то для дальнейшего исправления подтвержденных уязвимостей обычно нужно поставить задачу. Мы не раз сталкивались с тем, что именно на этом шаге возникали трудности.
Форма запроса
Есть компании, в которых большие задачи на этап фиксируются в системе управления проектами (например, Jira). А для подзадач и багов используются, к примеру, GitLab Issues, доступ к которым есть только у тимлида и его группы. Бывает и так, что сборка невозможна без создания отдельной задачи в системе управления проектов. У анализатора могут быть интеграции, с помощью которых вы сможете создавать нужные запросы сразу в интерфейсе.
Часто внутри одной компании с многочисленными группами разработки для каждой из них установлен свой порядок реализации рабочих задач. И нужно подстроиться подо всех. Возникают вопросы:
Конечно, это зависит от того, как налажен процесс в команде, какие системы отслеживания ошибок используются.
Если код пишут подрядчики, для которых доступ во внутренние системы минимален, подойдёт схема с PDF-отчётом. Обычно для отчёта можно отобрать интересные вам уязвимости и сразу отправить на нужный адрес из интерфейса анализатора.
Если же в компании невозможен ни один шаг без создания проекта под определённый вид задач с определённым объёмом ресурсов, то стоит поискать инструмент с интеграцией для вашей системы. Наиболее гибкие интеграции сгенерируют за вас описание задачи (не забудут даже про ссылку на исходный код в системе контроля версий) и позволят заполнить все обязательные поля. Выбрать тип задачи, указать родительскую, исполнителей и даже версию релиза.
Трудозатраты и сроки
Если в команде принято давать оценку трудозатрат для каждой задачи, то с задачей по исправлению уязвимости нужно проделать то же самое. Попутно разработчики верифицируют уязвимости. Иногда на этом шаге выясняется, что уязвимость ложная или её невозможно эксплуатировать.
Но как правило, ресурсов всё равно недостаточно, чтобы сразу исправить все уязвимости. Поэтому нужно согласовать ещё и их приоритеты.
У задач определились трудозатраты и приоритеты — дальше ответственные за сроки релиза (это может быть руководитель проекта или тот же тимлид) решают, что и когда исправлять. На первых порах использования анализатора советуем не откладывать релиз, если не все уязвимости исправлены.
Как правильно распределить ресурсы: подключить новых людей или поручить тем, кто и так занят разработкой, — вопрос бюджета. Верно одно: если компания выделяет ресурсы на установку анализатора, нужно подготовиться к затратам на устранение уязвимостей. Возможный путь — закладывать процент времени на исправление уязвимостей как на работу с техническим долгом.
Есть два сценария: исправлять сразу в процессе разработки или по запросу от офицера безопасности. Исправлять уязвимости в процессе разработки — идеальный сценарий. Сразу нашёл — сразу исправил. Разработчик сканирует свою feature-ветку перед запросом на слияние с основной веткой. Это тоже можно автоматизировать с помощью интеграций: со средой разработки, со средствами сборки, системой контроля версий или с CI/CD.
Другой сценарий — анализировать основную ветку разработки после всех изменений. Офицер безопасности или тимлид просматривает результаты и создаёт задачи на исправление уязвимостей. Этот сценарий более трудоёмкий. На входе у разработчика — исходный код, задача на исправление и результаты анализа. Для разработчика задача на исправление уязвимости мало отличается от устранения бага.
Нужно убедиться, что уязвимость действительно исправлена и на её месте не возникла новая. Есть результаты анализа исправленного кода. Что искать? Файл и номер строки, в которой была уязвимость? Или поискать по названию уязвимости? Можно и так. Но если код был изменён, строка с уязвимостью могла сместиться, а вхождений одной уязвимости может всё ещё быть много. Некоторые анализаторы могут показывать «устранённые» уязвимости. Согласитесь, так проверить исправление уязвимости можно быстрее (см скриншот).
Приведём два возможных сценария.
Команда использует Git для контроля версий, Jira — для управления проектами и задачами. С помощью Jenkins настраивается расписание сборки. Например, раз в сутки при наличии изменений в ветке. В качестве дополнительного шага указывается запуск анализатора.
Офицер безопасности просматривает результаты анализа основной ветки (master или development), разработчики — своих feature-веток.
Разработчики при необходимости исправляют уязвимости. Если анализатор умеет фильтровать уязвимости по запросу: показать только новые уязвимости или не показывать уязвимости в сторонних библиотеках, показать уязвимости в конкретной директории или файле — разработчик сможет быстро просмотреть интересные ему результаты. А значит, вероятность исправления выше.
Офицер безопасности просматривает результаты анализа основной ветки. С помощью интеграции с Jira офицер безопасности создаёт задачи по устранению уязвимостей из интерфейса анализатора. Далее — согласование сроков и приоритетов.
Когда уязвимость будет исправлена и новый код пройдёт все внутренние этапы разработки (ревью от тимлида, пользовательское и регрессионное тестирование), офицер безопасности должен убедиться, что уязвимости больше нет. Автор закрывает выполненную задачу.
Код для компании пишет группа подрядчиков. Тимлид взаимодействует с разработчиками по электронной почте и использует GitLab для контроля версий. Доступа ко внутренним системам управления проектами (Jira) у подрядчиков нет.
Офицер безопасности или сам тимлид просматривают результаты анализа основной ветки разработки. Доступа к анализатору у подрядчиков нет. Если есть уязвимости, которые нужно исправить, офицер безопасности отправляет PDF-отчёт с результатами анализа тимлиду или сразу разработчику.
Из отчёта разработчик узнает, где найдена уязвимость, в чём состоит и как можно исправить. Ценно, если для уязвимостей, связанных с потоком небезопасных данных (например, SQL-инъекция), в отчёт будет выгружаться схема распространения: от источника данных к их использованию в вызове функции/метода (см. скриншот).
После исправления уязвимости тимлид сообщает офицеру безопасности, что пора проверять результаты повторного сканирования.
Наладить взаимодействие между ИБ и разработкой. Важно, чтобы обе стороны были заинтересованы в исправлении уязвимостей. Хорошо, если это будут не только запросы, но и живое общение.
Не пренебрегайте ролями пользователей. У хорошего анализатора должна быть возможность разграничения прав. Вряд ли подрядчику понадобятся права администратора или результаты анализа внутренних систем. Редактировать результаты — изменять критичность и статус — достаточно разрешить офицеру безопасности и тимлиду. Принцип минимальных привилегий никто не отменял.
Если компания большая и применяет систему управления пользователями (например, Active Directory), рассмотрите инструменты с готовой интеграцией. Вы сможете переиспользовать принятые в компании роли и группы и выдавать им нужные права.
После выбора анализатора подготовьтесь к тому, что его ещё нужно правильно внедрить. Не бойтесь встреч и согласований с участниками: чем лучше вы разберётесь в процессе, тем полезнее будет результат. Важно, чтобы сценарий работы не только утвердили, но и начали ему следовать.
Автор: Елизавета Харламова, ведущий аналитик Solar appScreener
Что предстоит?
Внедрить анализатор так, чтобы уязвимости стабильно исправлялись — дело небыстрое. По опыту можем сказать, что это занимает от пары недель до нескольких месяцев. Если вы внедряете анализатор в крупную компанию, приготовьтесь к череде согласований. Ведь это сотни кодовых баз, которые нужно анализировать, и десятки команд со своими порядками разработки.
Чтобы добавить новый этап разработки — статический анализ, придётся изучить, как устроен процесс у каждой команды, и предложить удобное для всех решение. В небольших компаниях установленного порядка разработки может не быть вовсе. Внедрение анализатора можно сделать поводом для построения процесса. Чтобы интеграция прошла мягче, советуем выяснить, какие у анализатора есть для этого возможности.
Какие бывают возможности по интеграции?
Обычно анализатор предполагает неграфический интерфейс (CLI, REST) для интеграции в любой процесс. Есть анализаторы с готовыми интеграциями: со средствами сборки и средами разработки, с системами контроля версий (Git, SVN), серверами CI/CD (Jenkins, TeamCity, TFS), системами управления проектами (Jira) и управления пользователями (Active Directory). Чем больше полезного для вашей компании, тем легче будет всё настроить.
Как можно построить процесс?
Рассмотрим стандартную ситуацию: в процессе участвуют отделы информационной безопасности, управления релизами и разработки. Как правило, заказчиком внедрения анализатора является информационная безопасность (ИБ). Задача — договориться, кто, когда и что будет делать. Мы выделяем следующие шаги: запустить анализ, обработать результаты анализа, создать запрос на исправление уязвимости, исправить уязвимость, проверить исправление. Рассмотрим каждый шаг подробнее.
Шаг 1. Запустить анализ
Запускать анализ можно вручную или автоматизированно. У подходов есть свои плюсы и минусы.
Вручную
Сам вспомнил про анализатор, сам загрузил код, сам пошёл и посмотрел результаты.
Если проектов в компании около десятка и следить за безопасностью поручено одному офицеру безопасности, такой сценарий возможен. Если проектов около сотни — нужно настраивать автоматизацию.
Автоматизированно
Определитесь, как часто и в какой момент вам нужно анализировать код. Например, перед выходом в продуктивную среду, по заданному расписанию (раз в неделю) или после каждого изменения.
Если приложение обновляется редко, но за его безопасностью тоже нужно следить, настройте анализ при наличии изменений.
Если над кодом работают много людей, создано много веток, часто вливаются изменения — лучше анализировать часто, но при этом не мешать разработке. Например, в момент создания запроса на слияние с основной веткой или при изменении статуса задачи по данной ветке. В этом вам поможет интеграция с системой контроля версий или с системой управления проектами. Интеграция с CI/CD позволит сделать анализ одним из шагов сборки.
Настройте расписание так, чтобы вы успевали обрабатывать результаты.
Шаг 2. Обработать результаты анализа
Не поручайте разработчикам сразу исправить все найденные уязвимости. Пусть сначала офицер безопасности их верифицирует. Результаты первого анализа могут показаться плачевными: десятки критических, сотни менее критичных уязвимостей и тысячи ложных срабатываний. Как тут поступить? Рекомендуем исправлять уязвимости постепенно. Конечная цель — добиться отсутствия уязвимостей как в старом коде, так и в новом. На начальном этапе верифицировать критические (всё же с ними небезопасно) и новые уязвимости (новый код легче исправить).
Используйте фильтры. Отсортируйте уязвимости по критичности, по языкам, файлам и директориям. Более продвинутые инструменты покажут вам уязвимости только в новом коде, скроют уязвимости в сторонних библиотеках. Фильтры применили, но уязвимостей всё ещё много?
Просмотрите наиболее вероятные уязвимости. Есть анализаторы, которые оценивают вероятность ложного срабатывания. Если уязвимостей много, а уровень критичности почти у всех одинаковый, отфильтруйте результаты с использованием этой метрики. Так вы быстрее обработаете самые вероятные уязвимости (см. скриншот ниже).
Используйте статусы верификации. Чтобы зафиксировать результаты верификации, обычно анализаторы предлагают поработать со статусами для уязвимости: подтвердить или отклонить как ложное срабатывание. Как правило, проделанная работа должна сохраняться при пересканировании.
Шаг 3. Создать запрос на исправление уязвимости
Если разработчик сам запускает анализ своего кода и сразу исправляет уязвимости, то создавать лишние запросы, конечно, не нужно.
Если результаты просматривает и верифицирует офицер безопасности, то для дальнейшего исправления подтвержденных уязвимостей обычно нужно поставить задачу. Мы не раз сталкивались с тем, что именно на этом шаге возникали трудности.
Форма запроса
Есть компании, в которых большие задачи на этап фиксируются в системе управления проектами (например, Jira). А для подзадач и багов используются, к примеру, GitLab Issues, доступ к которым есть только у тимлида и его группы. Бывает и так, что сборка невозможна без создания отдельной задачи в системе управления проектов. У анализатора могут быть интеграции, с помощью которых вы сможете создавать нужные запросы сразу в интерфейсе.
Часто внутри одной компании с многочисленными группами разработки для каждой из них установлен свой порядок реализации рабочих задач. И нужно подстроиться подо всех. Возникают вопросы:
- А стоит ли выделять под исправление уязвимостей отдельный проект или создать задачи в существующих?
- Уязвимость — это знакомый всем «баг» или новая сущность?
- Создавать для каждой уязвимости отдельную задачу или сгруппировать похожие?
- Что привести в качестве описания задачи: ссылку на уязвимость в интерфейсе анализатора или на место в коде и кратко описать проблему?
- Да и нужен ли разработчику доступ к результатам — просто отправить PDF-отчёт с текстом «см. стр 257» и хватит?
Конечно, это зависит от того, как налажен процесс в команде, какие системы отслеживания ошибок используются.
Если код пишут подрядчики, для которых доступ во внутренние системы минимален, подойдёт схема с PDF-отчётом. Обычно для отчёта можно отобрать интересные вам уязвимости и сразу отправить на нужный адрес из интерфейса анализатора.
Если же в компании невозможен ни один шаг без создания проекта под определённый вид задач с определённым объёмом ресурсов, то стоит поискать инструмент с интеграцией для вашей системы. Наиболее гибкие интеграции сгенерируют за вас описание задачи (не забудут даже про ссылку на исходный код в системе контроля версий) и позволят заполнить все обязательные поля. Выбрать тип задачи, указать родительскую, исполнителей и даже версию релиза.
Трудозатраты и сроки
Если в команде принято давать оценку трудозатрат для каждой задачи, то с задачей по исправлению уязвимости нужно проделать то же самое. Попутно разработчики верифицируют уязвимости. Иногда на этом шаге выясняется, что уязвимость ложная или её невозможно эксплуатировать.
Но как правило, ресурсов всё равно недостаточно, чтобы сразу исправить все уязвимости. Поэтому нужно согласовать ещё и их приоритеты.
У задач определились трудозатраты и приоритеты — дальше ответственные за сроки релиза (это может быть руководитель проекта или тот же тимлид) решают, что и когда исправлять. На первых порах использования анализатора советуем не откладывать релиз, если не все уязвимости исправлены.
Шаг 4. Исправить уязвимости
Как правильно распределить ресурсы: подключить новых людей или поручить тем, кто и так занят разработкой, — вопрос бюджета. Верно одно: если компания выделяет ресурсы на установку анализатора, нужно подготовиться к затратам на устранение уязвимостей. Возможный путь — закладывать процент времени на исправление уязвимостей как на работу с техническим долгом.
Есть два сценария: исправлять сразу в процессе разработки или по запросу от офицера безопасности. Исправлять уязвимости в процессе разработки — идеальный сценарий. Сразу нашёл — сразу исправил. Разработчик сканирует свою feature-ветку перед запросом на слияние с основной веткой. Это тоже можно автоматизировать с помощью интеграций: со средой разработки, со средствами сборки, системой контроля версий или с CI/CD.
Другой сценарий — анализировать основную ветку разработки после всех изменений. Офицер безопасности или тимлид просматривает результаты и создаёт задачи на исправление уязвимостей. Этот сценарий более трудоёмкий. На входе у разработчика — исходный код, задача на исправление и результаты анализа. Для разработчика задача на исправление уязвимости мало отличается от устранения бага.
Шаг 5. Проверить исправление
Нужно убедиться, что уязвимость действительно исправлена и на её месте не возникла новая. Есть результаты анализа исправленного кода. Что искать? Файл и номер строки, в которой была уязвимость? Или поискать по названию уязвимости? Можно и так. Но если код был изменён, строка с уязвимостью могла сместиться, а вхождений одной уязвимости может всё ещё быть много. Некоторые анализаторы могут показывать «устранённые» уязвимости. Согласитесь, так проверить исправление уязвимости можно быстрее (см скриншот).
Примеры
Приведём два возможных сценария.
Сценарий 1
Команда использует Git для контроля версий, Jira — для управления проектами и задачами. С помощью Jenkins настраивается расписание сборки. Например, раз в сутки при наличии изменений в ветке. В качестве дополнительного шага указывается запуск анализатора.
Офицер безопасности просматривает результаты анализа основной ветки (master или development), разработчики — своих feature-веток.
Разработчики при необходимости исправляют уязвимости. Если анализатор умеет фильтровать уязвимости по запросу: показать только новые уязвимости или не показывать уязвимости в сторонних библиотеках, показать уязвимости в конкретной директории или файле — разработчик сможет быстро просмотреть интересные ему результаты. А значит, вероятность исправления выше.
Офицер безопасности просматривает результаты анализа основной ветки. С помощью интеграции с Jira офицер безопасности создаёт задачи по устранению уязвимостей из интерфейса анализатора. Далее — согласование сроков и приоритетов.
Когда уязвимость будет исправлена и новый код пройдёт все внутренние этапы разработки (ревью от тимлида, пользовательское и регрессионное тестирование), офицер безопасности должен убедиться, что уязвимости больше нет. Автор закрывает выполненную задачу.
Сценарий 2
Код для компании пишет группа подрядчиков. Тимлид взаимодействует с разработчиками по электронной почте и использует GitLab для контроля версий. Доступа ко внутренним системам управления проектами (Jira) у подрядчиков нет.
Офицер безопасности или сам тимлид просматривают результаты анализа основной ветки разработки. Доступа к анализатору у подрядчиков нет. Если есть уязвимости, которые нужно исправить, офицер безопасности отправляет PDF-отчёт с результатами анализа тимлиду или сразу разработчику.
Из отчёта разработчик узнает, где найдена уязвимость, в чём состоит и как можно исправить. Ценно, если для уязвимостей, связанных с потоком небезопасных данных (например, SQL-инъекция), в отчёт будет выгружаться схема распространения: от источника данных к их использованию в вызове функции/метода (см. скриншот).
После исправления уязвимости тимлид сообщает офицеру безопасности, что пора проверять результаты повторного сканирования.
Что ещё важно?
Наладить взаимодействие между ИБ и разработкой. Важно, чтобы обе стороны были заинтересованы в исправлении уязвимостей. Хорошо, если это будут не только запросы, но и живое общение.
Не пренебрегайте ролями пользователей. У хорошего анализатора должна быть возможность разграничения прав. Вряд ли подрядчику понадобятся права администратора или результаты анализа внутренних систем. Редактировать результаты — изменять критичность и статус — достаточно разрешить офицеру безопасности и тимлиду. Принцип минимальных привилегий никто не отменял.
Если компания большая и применяет систему управления пользователями (например, Active Directory), рассмотрите инструменты с готовой интеграцией. Вы сможете переиспользовать принятые в компании роли и группы и выдавать им нужные права.
Вывод
После выбора анализатора подготовьтесь к тому, что его ещё нужно правильно внедрить. Не бойтесь встреч и согласований с участниками: чем лучше вы разберётесь в процессе, тем полезнее будет результат. Важно, чтобы сценарий работы не только утвердили, но и начали ему следовать.
Автор: Елизавета Харламова, ведущий аналитик Solar appScreener
