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

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

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


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

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


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

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


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

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


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

    Вручную

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

    image

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

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

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

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

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

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

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


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

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

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

    image

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

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


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

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

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

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

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

    • А стоит ли выделять под исправление уязвимостей отдельный проект или создать задачи в существующих?
    • Уязвимость — это знакомый всем «баг» или новая сущность?
    • Создавать для каждой уязвимости отдельную задачу или сгруппировать похожие?
    • Что привести в качестве описания задачи: ссылку на уязвимость в интерфейсе анализатора или на место в коде и кратко описать проблему?
    • Да и нужен ли разработчику доступ к результатам — просто отправить 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
    Ростелеком-Солар
    355.56
    Безопасность по имени Солнце
    Share post

    Comments 15

      0
      Ожидал прочитать про Анализаторы. С примерами уязвимостей, починки, автоматизацией запуска…
      Ну, тоже, ничего. Тема интересная. Хорошо, что подняли.
        0
        Да, это вполне можно раскрыть в отдельной статье. Спасибо за идею :)
          0
          Увы, сами статические анализаторы — не более чем игрушка (однократно запустить и посмотреть, нет ли где трэша, по настроению исправить самые вопиющие случаи). Внедрить их в рабочий процесс — это адский труд, надо выделить отдельных людей на обработку и фильтрацию результатов. Попытки переложить эти задачи на плечи рядовых разработчиков обычно кончаются ничем. Имхо, внедрять их имеет смысл только там, где безопастность ставится во главу угла, всем остальным эти временные и трудовые затраты просто не окупаются.
            +1

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

              0
              По моему опыту, даже это проблематично (настраивал оповещение только о новых проблемах, которых не было при прошлом прогоне), всё равно сильно нарушался обычный рабочий ритм — требуется время на переключение туда-обратно с текущих задач, выяснение зоны ответственности, приоритета проблемы и прочее. В итоге начинают срываться сроки текущих задач — я не могу точно распланировать, так как не знаю, сколько за день прилетит проблем от анализатора. Пришлось отказаться, ибо неясно, сколько я могу сэкономить на статическом анализаторе в будущем (за счет проблем, которые удавлены в зародыше), но совершенно точно проигрываю в настоящем. Я не знаю способа оценить выгоду от анализатора, но по субьективным ощущениям, она меньше, чем без него. Нет предсказуемости в сроках, и тяжело сосредоточится на текущих проблемах — всё время на нервах из-за ожидания что прилетит очередное оповещение. Так что либо отдельные люди, либо запускать вручную в свободное время.
                +1
                Хм… А какой статический анализатор использовала команда?

                Кстати, а почему не настроить анализ для проверки коммитов, чтобы код с дефектами нельзя было заложить в основную ветку разработки? Пример на тему PVS-Studio.

                Ну или почему бы ошибки не править тем самым программистам, которые заложили этот код? Они сделают это быстро, так как сами написали этот код вчера (если мы говорим про запуск анализатора при ночных сборках). Задачи можно даже не создавать, а ограничиться письмами. Оповещение команд разработчиков на примере PVS-Studio.
                  0
                  На работе cppcheck, для pet-проекта пробовал прикрутить ваш пвс через TravisCI. Отчасти проблема в ложных срабатываниях, отчасти в тоннах легаси, которое как-то работает и лопатить его чревато, как ошибками, так и просадками производительности.
                  Править предупреждения при пуше — тоже не всегда возможно (на работе), там нередки случаи когда надо выдать вотпрямщас результат, вылизывать времени нет. Для пет-проекта возможно и попробуем.
                    0
                    Править предупреждения при пуше — тоже не всегда возможно (на работе), там нередки случаи когда надо выдать вотпрямщас результат, вылизывать времени нет.
                    Согласен, при подходе «херакс херакс и в продакшн», статический анализ только помеха :)
                      0
                      Когда платят не за качество кода, а за скорость внесения изменений, такой подход неизбежен. Более того, скажу еретическую мысль, для клиента важна скорость исправления выявленных багов, а не их потенциальное отсутствие:)
              0
              Всё не так страшно. Есть как минимум два подхода, которые позволяют безболезненно внедрять статический анализ даже в большие старые проекты.
              1. «Метод храповика», о котором хорошо рассказывает Иван Пономарёв в своём докладе "Непрерывный статический анализ кода".
              2. "База разметки", которую мы предлагаем пользователям и клиентам, которые используют наш анализатор кода PVS-Studio. Общая идея в следующем. Пользователь запустил анализатор и получал 100500 предупреждений. Раз проект, разрабатываемый 10 лет, жив, развивается и приносит деньги, то, скорее всего, в отчёте не будет много предупреждений, ссылающихся на критические дефекты. Другим словами, критические баги так или иначе уже поправлены более дорогими способами или благодаря фидбеку от клиентов. Соответственно, всё что сейчас находит анализатор, можно считать техническим долгом, который непрактично стараться устранить сразу. Поэтому можно указать PVS-Studio считать эти предупреждения пока неактуальными (отложить технический долг на потом), и чтобы он больше не показывал их. Анализатор создаёт специальный файл, где сохраняете информацию о пока неинтересных ошибках. И теперь PVS-Studio будет выдавать предубеждения только на новый или измененный код. Причем все сделано умно. Если, например, в начало некоего .cpp файла будет добавлена пустая строка, то анализатор понимает, что, по сути, ничего не изменилось и по-прежнему будет молчать. Этот файл разметки можно заложить в систему контроля версий. Файл большой, но это не страшно, так как часто его закладывать смысла нет. И теперь все программисты будут видеть предупреждения, относящиеся только к новому или изменённому коду. Таким образом, анализатор можно начать использовать, что называется со следующего дня. Ну а к техническому долго можно будет возвращаться затем постепенно и исправлять предупреждения и донастраивать анализатор.

              Ну и ещё, как вариант, можно перепоручить работу по интеграции статического анализа (настроить, поправить ошибки :). Пример: "Как команда PVS-Studio улучшила код Unreal Engine".
                0
                Первый смотреть долго, по второму отпишусь сразу. Он всё равно требует человека, который бы следил за актуальностью базы разметки. И на работе, и в хобби такого человека нет, а самому с этим возиться не хочется ни там ни там.
                  +1

                  Классика: есть время фиксить баги, но нет времени заниматься анализатором :). Затраты на сопровождение анализатора сильно преувеличиваются. Как раз недавно я опубликовал статью про это: "Работа с возражениями: статический анализ будет отнимать часть рабочего времени".
                    0
                    Вот без обид, у вас в этой статье только постулаты, без каких либо доказательств или измерений. Даже в статье про ROI только теоретические расчеты www.viva64.com/ru/b/0606

                    А реально измерить выгоду от использования анализатора весьма затруднительно. Если это вообще возможно…
            0
            Непонятно, почему тут статический анализ привязан непременно к уязвимостям. А освбождение памяти, а проверка на null, а локализация строк? Это только навскидку.
              0
              А они сознательно из статьи в статью смешивают понятия :). Они называют все дефекты (потенциальные уязвимости), сразу уязвимостями. Видимо так страшнее звучит.

            Only users with full accounts can post comments. Log in, please.