Этой статьей мы завершим небольшой цикл о построении процесса безопасной разработки на основе SAST — статического анализа кода на безопасность. В первой части мы разобрали основные вопросы, возникающие при внедрении SAST в процесс разработки. Во второй части остановились на технических аспектах внедрения и разобрали несколько примеров выстраивания SSDLC на практике. В последней части расскажем об организационных моментах.
Для большинства компаний использование SAST — это новый процесс, а уязвимость — новая сущность. Уязвимость — это не баг и не функциональное требование, и нужно выстраивать процесс работы с новой сущностью. Нельзя забывать про историческое разделение безопасности и разработки, которое особенно обостряется, когда в процесс разработки нужно внедрять что-то новое. Масла в огонь подливают и технические особенности статического анализа, о которых мы говорили во второй части.
Как и в прошлой части, примером будет один из наших кейсов внедрения. Напомню: ~200 разработчиков, 14 команд, 232 кодовых базы с более чем 32 млн строк кода. Java, JavaScript, PHP, C#, Kotlin, Objective-C, SAP ABAP. С организационной точки зрения кейс был интересен тем, что у разных команд были очень разные процессы разработки и разные инструменты их автоматизации. Во всё это нужно было внедрить SAST и определить, как команды будут работать с уязвимостями.
Итак, ставим задачу: как можно быстрее внедрить SAST во всех командах. Получаем: два месяца разработчики исправляют тысячи найденных уязвимостей, матерясь на ложные срабатывания. CI/CD каждый день падает от загрузки со стороны SAST. Релизы сорваны, все переругались, внедрение отменено и вряд ли когда-нибудь состоится. Сценарий выглядит уж слишком преувеличенным, но с таким мы тоже сталкивались.
Мы всегда рекомендуем внедрять SAST постепенно. И для менеджмента, и для безопасников, и для разработчиков использование статического анализа — новый процесс, к которому надо привыкнуть. Постепенное внедрение даст гораздо больше выхлопа, чем резкие движения. А что такое ”постепенно”?
Во-первых, в начале пути не стоит блокировать релизы из-за наличия уязвимостей. Пока не сформировалась база знаний и экспертиза по верификации ложных срабатываний и полностью не сложилась практика исправления уязвимостей, влияние SAST на выход релизов может повернуть большую часть участников процесса против безопасности. Когда процесс будет обкатан (возможно, это займет несколько месяцев), тогда можно начинать блокировать релизы по факту выявления анализатором критических уязвимостей.
Логично начать внедрение с наиболее критичных систем — например, web-приложений и мобильных клиентов. В любом случае при первичном внедрении выявляется ряд подводных камней, которые нужно будет обойти. Когда появится опыт внедрения на нескольких кодовых базах с несколькими командами, можно будет масштабировать и подстраивать процесс под остальные. При этом при таком подходе важно не затачивать процесс под конкретную кодовую базу или команду, держа в уме общую картину в компании.
Еще раз напомню о важной рекомендации, которую уже озвучивал выше: для начала нужно исправлять только новые уязвимости, постепенно разбирая и исправляя “технический долг” — все старые уязвимости. Подробные рекомендации можно посмотреть в предыдущей статье серии.
Мы рекомендуем провести проектирование и описать детали внедрения заранее. Нужно инвентаризировать кодовые базы, процессы, регламенты разработки, системы автоматизации. Разработать и согласовать новые регламенты и технические решения, общаясь со всеми участниками процесса. А потом уже претворять в жизнь. Однако, как нас учит agile-философия, сильно затягивать с этим тоже не надо: пока проектируешь, все вокруг может измениться и результаты проектирования станут неактуальными. Изменятся используемые инструменты разработки (в нашем кейсе в процессе внедрения изменился процесс работы с Jira, CI/CD переехал с Jenkins в Gitlab CI). Изменятся сами процессы, устареют кодовые базы, появятся новые. Наконец, уйдут предыдущие руководители и придут новые.
Отдельно скажу пару слов про согласование. В разработке много участников — непосредственно разработчики, тимлиды, продакт менеджеры, безопасники, релиз-менеджеры, инфраструктура, поддержка, тестирование, бизнес. Нужно хорошо понимать и показывать выгоду SAST, чтобы “продать” новый процесс всем участникам и согласовать со всеми непротиворечивые условия. Хорошо работает “продажа” SAST через финансовую оценку эксплуатации найденных на пилоте уязвимостей. Обычно такая оценка с лихвой покрывает стоимость внедрения.
В нашем кейсе, который учитывал все приведенные рекомендации, внедрение процесса шло чуть больше года.
Обычно мы советуем составить какое-то подобие регламента процесса безопасной разработки (его формат и формальность зависит от принятой в компании процедуры описания внутренних процессов).
В регламент можно включить:
Важно помнить, что процесс, основанный на SAST, пересекается со всеми остальными процессами разработки, и необходимо синхронизировать новый регламент со всеми предыдущими (например, с регламентами разработки, выпуска релизов, регламентами по безопасности).
Нужно провести инвентаризацию процессов, чтобы понимать, с какими процессами будет пересекаться безопасная разработка. Возможно, окажется, что какие-то необходимые процессы (например, непрерывная интеграция) еще не существуют или не описаны — их создание и описание нужно будет проводить вместе с внедрением SAST.
Регламент важен с точки зрения закрепления ответственности за этапы процесса и выделение ресурсов. Вопрос, в чьей зоне ответственности должны находиться уязвимости, спорный (ИБ или разработка?). Но очевидно, что исправлять уязвимости будут разработчики. А чаще всего разработчики полностью загружены и без новых задач по исправлению проблем безопасности. Необходимо предусмотреть выделение дополнительного бюджета на исправления уязвимостей, в том числе с выводом новых сотрудников. Обычной практикой является выделение некоторого процента времени команды на исправление уязвимостей, по аналогии с закрытием технического долга.
Внедрение SAST можно условно разбить на следующие шаги:
Пункты 2-4 обычно идут вперемешку и параллельно с постепенным расширением скоупа по командам и кодовым базам.
В этой серии статей мы описали проблемы и вопросы, которые, по нашему опыту, могут возникать на каждом шаге построения процесса безопасной разработки. Оказывается, их немало. Но если их знать и следовать основным рекомендациям, то можно внедрить SAST так, чтобы код был безопасным, а разработка шла без помех.
Для большинства компаний использование SAST — это новый процесс, а уязвимость — новая сущность. Уязвимость — это не баг и не функциональное требование, и нужно выстраивать процесс работы с новой сущностью. Нельзя забывать про историческое разделение безопасности и разработки, которое особенно обостряется, когда в процесс разработки нужно внедрять что-то новое. Масла в огонь подливают и технические особенности статического анализа, о которых мы говорили во второй части.
Как и в прошлой части, примером будет один из наших кейсов внедрения. Напомню: ~200 разработчиков, 14 команд, 232 кодовых базы с более чем 32 млн строк кода. Java, JavaScript, PHP, C#, Kotlin, Objective-C, SAP ABAP. С организационной точки зрения кейс был интересен тем, что у разных команд были очень разные процессы разработки и разные инструменты их автоматизации. Во всё это нужно было внедрить SAST и определить, как команды будут работать с уязвимостями.
Сроки внедрения
Итак, ставим задачу: как можно быстрее внедрить SAST во всех командах. Получаем: два месяца разработчики исправляют тысячи найденных уязвимостей, матерясь на ложные срабатывания. CI/CD каждый день падает от загрузки со стороны SAST. Релизы сорваны, все переругались, внедрение отменено и вряд ли когда-нибудь состоится. Сценарий выглядит уж слишком преувеличенным, но с таким мы тоже сталкивались.
Мы всегда рекомендуем внедрять SAST постепенно. И для менеджмента, и для безопасников, и для разработчиков использование статического анализа — новый процесс, к которому надо привыкнуть. Постепенное внедрение даст гораздо больше выхлопа, чем резкие движения. А что такое ”постепенно”?
Во-первых, в начале пути не стоит блокировать релизы из-за наличия уязвимостей. Пока не сформировалась база знаний и экспертиза по верификации ложных срабатываний и полностью не сложилась практика исправления уязвимостей, влияние SAST на выход релизов может повернуть большую часть участников процесса против безопасности. Когда процесс будет обкатан (возможно, это займет несколько месяцев), тогда можно начинать блокировать релизы по факту выявления анализатором критических уязвимостей.
Логично начать внедрение с наиболее критичных систем — например, web-приложений и мобильных клиентов. В любом случае при первичном внедрении выявляется ряд подводных камней, которые нужно будет обойти. Когда появится опыт внедрения на нескольких кодовых базах с несколькими командами, можно будет масштабировать и подстраивать процесс под остальные. При этом при таком подходе важно не затачивать процесс под конкретную кодовую базу или команду, держа в уме общую картину в компании.
Еще раз напомню о важной рекомендации, которую уже озвучивал выше: для начала нужно исправлять только новые уязвимости, постепенно разбирая и исправляя “технический долг” — все старые уязвимости. Подробные рекомендации можно посмотреть в предыдущей статье серии.
Мы рекомендуем провести проектирование и описать детали внедрения заранее. Нужно инвентаризировать кодовые базы, процессы, регламенты разработки, системы автоматизации. Разработать и согласовать новые регламенты и технические решения, общаясь со всеми участниками процесса. А потом уже претворять в жизнь. Однако, как нас учит agile-философия, сильно затягивать с этим тоже не надо: пока проектируешь, все вокруг может измениться и результаты проектирования станут неактуальными. Изменятся используемые инструменты разработки (в нашем кейсе в процессе внедрения изменился процесс работы с Jira, CI/CD переехал с Jenkins в Gitlab CI). Изменятся сами процессы, устареют кодовые базы, появятся новые. Наконец, уйдут предыдущие руководители и придут новые.
Отдельно скажу пару слов про согласование. В разработке много участников — непосредственно разработчики, тимлиды, продакт менеджеры, безопасники, релиз-менеджеры, инфраструктура, поддержка, тестирование, бизнес. Нужно хорошо понимать и показывать выгоду SAST, чтобы “продать” новый процесс всем участникам и согласовать со всеми непротиворечивые условия. Хорошо работает “продажа” SAST через финансовую оценку эксплуатации найденных на пилоте уязвимостей. Обычно такая оценка с лихвой покрывает стоимость внедрения.
В нашем кейсе, который учитывал все приведенные рекомендации, внедрение процесса шло чуть больше года.
Регламент
Обычно мы советуем составить какое-то подобие регламента процесса безопасной разработки (его формат и формальность зависит от принятой в компании процедуры описания внутренних процессов).
В регламент можно включить:
- Подробное описание всех шагов проверки кода на уязвимости: добавление новой кодовой базы в процесс проверки, поиск уязвимостей, верификация и обсуждение, согласование сроков и трудозатрат, исправление, проверка исправления.
- Описание разделения ответственности за выполнение каждого шага и описание ролей и уровней доступа.
- Формат коммуникации в процессе поиска и исправления уязвимостей.
- SLA, где это применимо. Обычно не фиксируют SLA на исправление, так как уязвимости бывают очень разными. Но можно фиксировать SLA на оценку трудозатрат и сроков исправления.
- Схема эскалации при возникновении спорных ситуаций.
- Все дополнительные условия (например, влияет ли результат поиска уязвимостей на релизы).
Важно помнить, что процесс, основанный на SAST, пересекается со всеми остальными процессами разработки, и необходимо синхронизировать новый регламент со всеми предыдущими (например, с регламентами разработки, выпуска релизов, регламентами по безопасности).
Нужно провести инвентаризацию процессов, чтобы понимать, с какими процессами будет пересекаться безопасная разработка. Возможно, окажется, что какие-то необходимые процессы (например, непрерывная интеграция) еще не существуют или не описаны — их создание и описание нужно будет проводить вместе с внедрением SAST.
Регламент важен с точки зрения закрепления ответственности за этапы процесса и выделение ресурсов. Вопрос, в чьей зоне ответственности должны находиться уязвимости, спорный (ИБ или разработка?). Но очевидно, что исправлять уязвимости будут разработчики. А чаще всего разработчики полностью загружены и без новых задач по исправлению проблем безопасности. Необходимо предусмотреть выделение дополнительного бюджета на исправления уязвимостей, в том числе с выводом новых сотрудников. Обычной практикой является выделение некоторого процента времени команды на исправление уязвимостей, по аналогии с закрытием технического долга.Заключение
Внедрение SAST можно условно разбить на следующие шаги:
- Выбор инструмента;
- Описание процесса (регламентирование) и технических решений, согласование;
- Проведение работ по внедрению;
- Опытная эксплуатация и тиражирование процесса.
Пункты 2-4 обычно идут вперемешку и параллельно с постепенным расширением скоупа по командам и кодовым базам.
В этой серии статей мы описали проблемы и вопросы, которые, по нашему опыту, могут возникать на каждом шаге построения процесса безопасной разработки. Оказывается, их немало. Но если их знать и следовать основным рекомендациям, то можно внедрить SAST так, чтобы код был безопасным, а разработка шла без помех.