Анализ безопасности исходного кода как ключевой элемент DevSecOps

Анализ безопасности исходного кода как ключевой элемент DevSecOps

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

 

 

 

  1. Введение
  2. Зачем проверять код на безопасность
  3. Использовать ли сканеры с открытым исходным кодом
  4. Что такое SAST, DAST, IAST и с чего нужно начинать внедрение анализа безопасности исходного кода
  5. Что мешает внедрять средства анализа безопасности кода
  6. Перспективы рынка: уйдёт ли анализ кода на безопасность в облако
  7. Выводы

Введение

Мы продолжаем обсуждать различные аспекты методологии DevSecOps в рамках цикла онлайн-конференций AM Live. В феврале ведущие эксперты рынка рассказали зрителям об основах безопасной разработки, а очередная встреча, прошедшая в конце марта, была посвящена обеспечению безопасности исходного кода. Мы собрали группу экспертов, чтобы обсудить, какие сканеры безопасности исходного кода представлены на рынке, чем отличаются решения классов SAST, DAST и IAST и что такое RASP-инструменты, а также порассуждать о перспективах отрасли.

В студии Anti-Malware.ru собрались:

  • Анна Архипова, ведущий менеджер по развитию продуктовых решений компании ITD Group.
  • Сергей Деев, менеджер продукта Solar appScreener компании «Ростелеком-Солар».
  • Дарья Орешкина, директор по развитию бизнеса компании Web Control.
  • Алексей Жуков, эксперт отдела систем защиты приложений компании Positive Technologies.
  • Валерий Куваев, архитектор решений Fortify компании Micro Focus.
  • Артём Синицын, старший руководитель программ ИБ в Центральной и Восточной Европе компании Microsoft.

Модерировал беседу Андрей Бешков — руководитель направления развития бизнеса компании Softline.

 

 

Зачем проверять код на безопасность

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

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

Алексей Жуков поделился мнением, что компании уже научились управлять уязвимостями в периметре безопасности, устанавливая патчи на типовые, массовые программы — операционные системы и базы данных. Однако наряду с ними в организации могут использоваться уникальные приложения, написанные специально под определённые задачи — например, веб-сайты. Чтобы такие программы не стали точкой входа для злоумышленников, необходимо найти и устранить в них уязвимости.

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

Чем раньше наступит стадия, когда компания начинает думать о безопасности кода, тем меньше времени, денег и других ресурсов потребуется на патчинг. Как отметили наши эксперты, чем раньше начнёшь анализ кода, тем меньше заплатишь в итоге. Существуют сервисы и приложения, которые напрямую связаны с выручкой компании — например, финансовые и торговые программы. Цена компрометации таких систем несёт не только репутационные, но и прямые денежные убытки для компании. Статический анализ позволяет решить задачу обеспечения безопасности кода на самых ранних этапах. Безусловно, это — не единственный инструмент безопасной разработки, но первый и необходимый шаг.

Сканирование кода на безопасность позволяет разработчику лучше контролировать процесс, после выпуска патча такой возможности практически не существует и создатель обновления не может управлять его использованием. Идеология Shift Left (смещение вопросов связанных с безопасностью как можно ближе к началу разработки) позволяет снизить потенциальные издержки от проблем и для разработчика, и для заказчика.

Использовать ли сканеры с открытым исходным кодом

Ещё один вопрос, который обсудили спикеры онлайн-конференции AM Live, — насколько допустимо использовать бесплатные (open-source) продукты для анализа кода. Как отметили эксперты, такие разработки могут обеспечить некоторый базовый уровень безопасности, однако для поиска уязвимостей второго порядка чаще всего необходимы специализированные ИБ-продукты. Платные инструменты часто обладают расширенной рекомендательной функциональностью. Это важно, поскольку в ряде случаев мало сообщить о проблеме, надо ещё и объяснить, что необходимо сделать, вплоть до автоматического исправления проблемного кода. Детальное описание уязвимостей и разработка рекомендаций по их исправлению требуют очень больших усилий и затрат от разработчиков сканеров, а опенсорс-команды часто ими не обладают.

Как отметил Артём Синицын, не бывает полностью бесплатного ПО и тем более не бывает дешёвой безопасности. В то же время нельзя говорить, что лучше — коммерческий сканер или бесплатный; можно говорить о том, какой инструмент лучше подходит для решения определённой задачи. Можно комбинировать различные ядра для анализа кода на разных стадиях проекта, а также применять разные сканеры для разных разработок.

Мы поинтересовались у зрителей прямого эфира, анализируют ли они исходный код своих проектов на предмет безопасности. Как оказалось, в организациях 30 % респондентов действует специальный регламент по проверке кода. Ещё 20 % опрошенных сообщили, что код анализируется, но этот процесс не поставлен на регулярную основу. Не анализируют код 17 % наших зрителей, а 18 % из них уверены в чистоте используемого в их проектах кода. Отдали процесс обеспечения безопасности кода на аутсорсинг 15 % опрошенных.

 

Рисунок 1. Анализируете ли вы исходный код своих проектов на безопасность?

Анализируете ли вы исходный код своих проектов на безопасность?

 

Что такое SAST, DAST, IAST и с чего нужно начинать внедрение анализа безопасности исходного кода

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

Анна Архипова:

— Каждый инструмент используется на своём этапе DevSecOps. Статический анализатор поможет при написании кода и определении архитектуры приложения, динамическая проверка и, возможно, IAST будут полезны при сборке и тестировании программы. Ни один из инструментов не обеспечивает полной безопасности кода, но в комплексе они дают хороший результат.

Валерий Куваев:

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

Сергей Деев:

— Компании по-разному подходят к разработке, но если стоит цель сделать этот процесс безопасным, то SAST — это один из базовых инструментов. Однако стоит не противопоставлять статический и динамический анализ, а использовать все доступные инструменты, чтобы сделать код безопасным. Некоторые типы уязвимостей можно определить только в статике, некоторые — только в динамике, а целый ряд проблем находится на стыке возможностей этих двух инструментов.

Дарья Орешкина:

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

Артем Синицын:

— Чтобы понять текущую классификацию решений для сканирования кода, достаточно запомнить пять аббревиатур. Исторически существуют статический (SAST) и динамический (DAST) анализ, а также гибридный подход (IAST). Кроме того, существует FAST, или фаззинг — подраздел динамического тестирования на основе обратной связи. Наконец, нельзя забывать и о RASP (Runtime Application Self-Protection), технологии, которая скорее является внутренним файрволом приложения и используется для анализа и блокировки атак в реальном времени.

Алексей Жуков:

— В контексте безопасности приложений необходимо помнить об ещё одной технологии: WAF (Web Application Firewall). Это — накладное средство безопасности, которое позволяет заблокировать определённые известные уязвимости и выпустить программу дав разработчику время для исправления проблемы.

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

Зрители онлайн-конференции AM Live считают, что в первую очередь необходимо уделять внимание статическому анализу кода. За это в ходе проведённого нами опроса высказались 69 % респондентов. Ещё 21 % опрошенных отдают предпочтение динамическому анализу. За анализ сторонних компонентов и интерактивный анализ (IAST) отдали свои голоса 7 % и 3 % соответственно.

 

Рисунок 2. На какие способы анализа безопасности приложений вы обращаете внимание в первую очередь?

На какие способы анализа безопасности приложений вы обращаете внимание в первую очередь?

 

Что мешает внедрять средства анализа безопасности кода

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

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

На вопрос «Что ограничивает вас во внедрении анализа безопасности исходного кода?» 28 % зрителей онлайн-трансляции ответили, что им мешает сопротивление внутри компании. Столько же голосов набрал вариант «Дефицит внутренних ресурсов». Высокая стоимость технологий анализа исходного кода на безопасность ограничивает 20 % опрошенных, а увеличение срока выхода релизов — 8 % респондентов. Наконец, 16 % наших зрителей сообщили, что в их компании этот процесс находится на стороне подрядчика.

 

Рисунок 3. Что ограничивает вас во внедрении анализа безопасности исходного кода?

Что ограничивает вас во внедрении анализа безопасности исходного кода?

 

Перспективы рынка: уйдёт ли анализ кода на безопасность в облако

В завершение беседы ведущий конференции AM Live предложил гостям в студии порассуждать о перспективах рынка и, в частности, обсудить то, будут ли анализаторы кода мигрировать в облако. Эксперты отметили, что на западном рынке этот процесс уже идёт и вендоры получают до 50 % своей прибыли от облачных систем безопасности кода. В России этот тренд также заметен, хотя и не так значим. Некоторое недоверие к облачным технологиям в нашей стране обусловлено в том числе и слабой нормативной базой, которая, впрочем, сейчас активно развивается.

Мы спросили у зрителей конференции, готовы ли они отдать анализ исходного кода в облако. Большинство участников опроса — 62 % — отрицательно отнеслись к такой возможности. Готовы использовать облачные технологии в том случае, если серверы находятся на территории России, 19 % респондентов; столько же доверяют анализу кода в облаке без дополнительных условий.

 

Рисунок 4. Готовы ли вы производить анализ безопасности исходного кода в облаке?

Готовы ли вы производить анализ безопасности исходного кода в облаке?

 

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

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

По итогам конференции мы поинтересовались у зрителей тем, как изменилось их мнение относительно технологий анализа кода после просмотра прямого эфира. Почти четверть опрошенных — 24 % — заинтересовались анализаторами и выразили готовность начать их тестирование. Чуть больше — 28 % респондентов — считают, что такое решение будет избыточно для их компании. Почти треть участников опроса уже используют сканеры исходного кода — за этот вариант отдали свои голоса 32 % зрителей. Ещё 4 % опрошенных выразили мнение, что спикеры онлайн-конференции не смогли доказать необходимость таких инструментов, а 12 % вообще не поняли, о чём шла речь.

 

Рисунок 5. Каково ваше мнение относительно анализаторов безопасности исходного кода?

Каково ваше мнение относительно анализаторов безопасности исходного кода?

 

Выводы

Мы планируем продолжить обсуждение различных аспектов DevSecOps с экспертами в этой сфере. Кроме того, зрителей ждут новые выпуски конференции AM Live, посвящённые и другим актуальным для отечественного рынка информационной безопасности вопросам. Чтобы оставаться в курсе ключевых тенденций, иметь возможность в прямом эфире наблюдать дискуссии лидеров мнений и общаться с ними в процессе онлайн-трансляции, подписывайтесь на наш YouTube-канал и включайте уведомления о новых материалах. До встречи на конференции AM Live!

Полезные ссылки: 
Anti-Malware Яндекс ДзенПодписывайтесь на канал "Anti-Malware" в Telegram, чтобы первыми узнавать о новостях и наших эксклюзивных материалах по информационной безопасности.

RSS: Новые статьи на Anti-Malware.ru