Отчет о состоянии DevSecOps в мире за 2023 год

в общих чертах

О компании Synopsys в 2023 годуDevSecOpsОтчет об исследовании текущей ситуации

Synopsys в начале 2023 годаинформационная безопасностьИсследовательский центр (CyRC) совместно с международной консалтинговой компанией Censuswide провел опрос 1000 ИТ-специалистов, отвечающих за безопасность. Среди респондентов были разработчики, специалисты по AppSec, инженеры DevOps, CISO и in-tech,информационная безопасностьи приложения/программное обеспечение
Эксперты, занимающие различные должности в сфере развития, интервьюируемые из США, Великобритании, Франции, Финляндии, Германии, Китая, Сингапура и Японии.
В опросе могли принять участие все респонденты, независимо от их отрасли или размера компании. Одна из трудностей при разработке этого опроса заключалась в том, что термин "DevSecOps" охватывает множество дисциплин, многие из которых имеют свои собственные уникальные роли. В опросе хотели принять участие люди с разным профессиональным опытом, включая как разработчиков, которые "непосредственно" пишут код, так и тех, кто на уровне CISO занимается вопросами безопасности программного обеспечения.

О DevOps и DevSecOps

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

DevSecOps - это расширение методологии DevOps, призванное привить культуру безопасности в различных командах и обеспечить раннее и последовательное решение проблем безопасности в среде DevOps, всегда интегрируя практики безопасности в разработку программного обеспечения.
Жизненный цикл (SDLC) и конвейеры CI, DevSecOps призван превратить безопасность из отдельного этапа в часть жизненного цикла разработки.

DevSecOps завоевал популярность среди организаций, занимающихся разработкой программного обеспечения, а исследование SANS State of DevSecOps Survey 2023 показывает, что DevSecOps стал важной бизнес-практикой и подходом к управлению рисками. Однако в прошлом команды безопасности и разработчиков часто расходились во мнениях, пытаясь внедрить безопасность в свои процессы, во многом из-за этого

Практика будет использовать традиционныеБезопасность приложенийИнструменты тестирования (AST) входят в жизненный цикл разработки программного обеспечения (SDLC). Разработчики часто жалуются, что инструменты AST слишком сложны, трудны для изучения, имеют низкую производительность и генерируют много "шума", который создает "трение" ⸺, то есть то, что мешает разработчикам легко и быстро создавать код в процессе разработки программного обеспечения. Разработчики не могут легко и быстро создавать код в процессе разработки программного обеспечения. Большинство респондентов выразили общую неудовлетворенность инструментами AST, которые они используют.

Преимущества автоматизации

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

• консистенция
  Автоматизированное тестирование обеспечивает последовательное выполнение проверок безопасности при каждой сборке и развертывании. Ручное тестирование может привести к несогласованности процессов тестирования и охвата.
• масштабируемость
  По мере роста сложности программного обеспечения ручное тестирование становится непрактичным. Автоматизированное тестирование легко масштабируется и позволяет проводить большое количество тестов для различных компонентов.
• Непрерывная интеграция и непрерывное развертывание (CI/CD)
  Автоматизированное тестирование очень важно в конвейерах CI/CD, где происходит быстрое и частое изменение кода. Автоматизированное тестирование позволяет быстро проверить изменения и предотвратить попадание ошибочного кода в производственную среду.
• постоянное совершенствование
  Автоматизированное тестирование предоставляет данные и сведения, которые могут помочь командам разработчиков и специалистов по безопасности со временем улучшить свои методы защиты, позволяя систематически анализировать и устранять уязвимости.
• рекорд (в спорте и т.д.)
  Автоматизированное тестирование позволяет документировать весь процесс тестирования, что облегчает отслеживание и аудит мер безопасности и требований соответствия.
• Сокращение количества человеческих ошибок
  Ручное тестирование чревато ошибками из-за усталости или невнимательности. Автоматизированное тестирование следует заранее определенным сценариям и позволяет снизить риск человеческих ошибок.
• Экономия времени и средств
  Выявление и устранение проблем безопасности на поздних этапах разработки или в процессе производства требует много времени и средств. Автоматизированное тестирование сводит эти затраты к минимуму.
• Улучшение опыта разработчиков
  Автоматизированное тестирование безопасности приложений позволяет разработчикам применять проактивный, целостный подход к решению проблем безопасности, что способствует изучению и совершенствованию знаний и навыков в области безопасности, тем самым повышая опыт разработчиков и, в конечном счете, улучшая безопасность и эффективность программного обеспечения в процессе разработки.

Растущее использование ASOC/ASPM в DevSecOps

В этом отчете рассматриваются организации, находящиеся на разных стадиях зрелости DevSecOps, их характеристики, а также инструменты/практики безопасности, которые они применяют. На основе полученных результатов мы дадим им рекомендации, которые помогут им в дальнейшем повышении уровня безопасности программного обеспечения.
Интересно, что результаты исследования показывают, что использование Application Security Orchestration and Correlation (ASOC), которое сейчас принято называть Application Security Situation Management (ASPM), становится все более распространенным. По мнению Gartner, ASPM должно быть приоритетом для любой организации, использующей множество инструментов разработки и безопасности.

Решения ASPM позволяют управлять широким спектром рисков, связанных с приложениями, от разработки до развертывания, включая обнаружение, корреляцию и определение приоритетов проблем безопасности. Инструменты ASPM могут получать данные из различных источников, затем коррелировать и анализировать их для упрощения интерпретации, классификации и устранения последствий.
ASPM также выступает в качестве уровня управления и оркестровки инструментов безопасности для поддержки контроля и применения политик безопасности. ASPM имеет консолидированное представление результатов безопасности приложений, что позволяет получить полное представление о состоянии безопасности и рисках всего приложения или системы.
Учитывая, что большинство из этих 1000 респондентов в целом были недовольны используемыми AST-инструментами - жаловались на невозможность определить приоритетность исправлений на основе потребностей бизнеса (35%) или объединить/сопоставить данные для решения проблем (29%), - вполне логично, что ASOC/ Вполне логично, что использование ASPM демонстрирует тенденцию быстрого роста.

Основные результаты исследования "Состояние DevSecOps 2023", проведенного компанией synopsys

Большинство DevOps-команд в той или иной степени внедрили DevSecOps: в общей сложности 911 TP3T респондентов отметили, что включили определенные меры безопасности для осуществления DevSecOps-деятельности в свой конвейер разработки ПО. Можно с уверенностью сказать, что внедрение методологий DevSecOps стало частью разработки программного обеспечения.
В организациях с более развитыми программами безопасности есть люди, занимающиеся вопросами безопасности.291 Респонденты TP3T отметили, что у них есть кросс-функциональные команды DevSecOps - совместные команды, состоящие из представителей отделов разработки, безопасности и эксплуатации, - которые являются важным фактором успеха их программ безопасности. Люди, занимающиеся вопросами безопасности и работающие с разработчиками/программистами и/или QA и тестированием, скорее всего, будут находиться на переднем крае тестирования безопасности в организациях с развитыми программами безопасности.

Существует множество препятствий для эффективного внедрения DevSecOps

Более 331 тп3т респондентов назвали в качестве основного препятствия отсутствие подготовки по вопросам безопасности. За ним следуют нехватка персонала в сфере безопасности (311 TP3T), отсутствие прозрачности в разработке/операциях (311 TP3T) и изменение приоритетов (301 TP3T).

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

Устранение серьезных уязвимостей на поздних этапах SDLC может существенно подорвать достигнутые результаты

Более 80% респондентов указали, что серьезные уязвимости/проблемы безопасности в развернутом программном обеспечении в той или иной форме повлияли на ход их работы в 2022-2023 годах.
28% респондентов заявили, что их организации требуется до трех недель для исправления основных рисков/уязвимостей безопасности в развернутых приложениях; еще 20% заявили, что на это может уйти до месяца
Эти цифры особенно тревожны, если учесть, что уязвимости эксплуатируются быстрее, чем когда-либо прежде. Недавние исследования показывают, что более половины всех уязвимостей используются в течение недели после раскрытия.

Более 70% респондентов Таблица 1 показывает типы автоматизированных мер сканирования, которые обычно используются для проверки кода на наличие дыр в системе безопасности и других дефектов. В категории "полезность инструментов/процессов" первое место заняли "уточнение требований безопасности на этапе поиска требований в SDLC" и "формальная оценка плана обеспечения безопасности ПО с помощью таких моделей, как BSIMM и SAMM". За ними следуют "Уточнение требований безопасности на этапе выявления требований в SDLC" и "Формальная оценка планов обеспечения безопасности ПО с помощью таких моделей, как BSIMM и SAMM".

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

Большинство из 1000 респондентов в качестве основной проблемы назвали широкий спектр проблем, связанных с инструментами AST, включая неспособность этих инструментов определять приоритеты исправлений на основе потребностей бизнеса (35%) и неспособность объединять/сопоставлять данные для решения проблем (29%).
52% Специалисты по безопасности начали активно сотрудничать с ИИ на мероприятиях DevSecOps, но более трех четвертей обеспокоены использованием ИИ, сообщает
Результаты исследования свидетельствуют о том, что службы безопасности активно используют ИИ, машинное обучение, обработку естественного языка и нейронные сети. Однако все более широкое использование генеративных инструментов ИИ, таких как советы по кодированию на основе ИИ, привело к возникновению ряда проблем с интеллектуальной собственностью, авторскими правами и лицензированием кода, созданного ИИ, а в некоторых случаях даже к судебным разбирательствам.

Обзор состояния DevSecOps в 2023 году

Развертывание DevSecOps

Более трети из 1000 респондентов считают, что их программа безопасности достигла уровня зрелости 3, когда процессы безопасности документированы, повторяемы и стандартизированы в рамках всей организации. Еще 251 TP3T респондентов считают, что их программа безопасности достигла уровня 4, где процессы безопасности также документированы, контролируются и оцениваются.
В общей сложности 911 респондентов TP3T указали, что они применяют тот или иной вид деятельности DevSecOps в процессе разработки программного обеспечения, и внедрение DevSecOps, похоже, стало неотъемлемой частью DevOps.

На каком уровне зрелости, по вашему мнению, находится текущий проект/программа по обеспечению безопасности программного обеспечения в вашей организации?

Внедрение методов обеспечения безопасности представляет собой более высокий уровень зрелости

Другой показатель зрелости DevSecOps, показанный на рисунке, свидетельствует о том, что респонденты применяют широкий спектр методов обеспечения безопасности, от непрерывного мониторинга и оценки (30%) до автоматизированного тестирования (28%).
Управление рисками безопасности, на которое ссылаются 358 респондентов (35,1%), включает в себя интеграцию соображений безопасности на каждом этапе процесса разработки для выявления, оценки и смягчения потенциальных рисков безопасности, связанных с программными приложениями. В рамках SDLC общее управление рисками безопасности охватывает следующие виды деятельности.

• Анализ требований. Выявление требований и ограничений безопасности на ранних этапах SDLC и определение целей безопасности.
• Дизайн. Включите принципы безопасности в архитектуру и дизайн системы, чтобы гарантировать, что приложения разработаны с соответствующими мерами защиты от распространенных уязвимостей.
• Разработка. Внедряйте методы безопасного кодирования и придерживайтесь стандартов кодирования, учитывающих вопросы безопасности. Используйте интегрированные средства тестирования безопасности, такие как статическое тестирование безопасности приложений (SAST) и анализ состава программного обеспечения (SCA), для выявления уязвимостей при написании кода и внедрении открытого кода или кода сторонних разработчиков.
• Тестирование. Выполнение различных видов тестирования безопасности для выявления уязвимостей в приложениях, таких как SAST, динамическое тестирование безопасности приложений (DAST), SCA и тестирование на проникновение.
• Развертывание. Безопасная настройка среды, в которой будет работать приложение. Реализуйте контроль доступа, сетевую безопасность и соответствующие механизмы аутентификации и авторизации.
• Мониторинг и оценка. Постоянный мониторинг приложений в производственной среде на предмет событий и аномалий безопасности. Внедряйте решения для ведения журналов и мониторинга, чтобы обнаружить
• Обнаружение и реагирование на потенциальные нарушения.301 Респонденты TP3T указали, что это основная практика безопасности, принятая в их организации.
• Реагирование и устранение последствий. Разработайте план реагирования на инциденты, чтобы быстро и эффективно справляться с ними. Устраните проблемы, обнаруженные на этапе тестирования.
• Прозрачность и безопасность. Установите четкие нормы, стандарты и стратегии и сообщайте о рисках безопасности и допустимых рисках.
• Обучение. Проводите обучение команд разработчиков по вопросам безопасного кодирования, распространенных уязвимостей и лучших практик безопасности, чтобы разработчики могли проактивно решать проблемы безопасности. К сожалению, 341 респондентTP3T назвал "Недостаточное/неэффективное обучение разработчиков/инженеров по вопросам безопасности" одним из основных препятствий для эффективного внедрения DevSecOps в своих организациях.
• Непрерывное совершенствование. Периодически пересматривать и улучшать процессы и практики безопасности в рамках SDLC.

Какие методы обеспечения безопасности использует ваша организация? (отметьте все, что применимо)

Оценка плана обеспечения безопасности

Около 701 респондента TP3T отметили, что им было бы полезно оценить свою программу безопасности с помощью инструмента оценки, такого как модель зрелости архитектуры безопасности ПО (BSIMM), причем более трети респондентов назвали такую оценку "очень полезной".
Внешняя оценка уровня безопасности поможет вам проанализировать свою программу безопасности программного обеспечения и сравнить ее с другими организациями и аналогами. Такие инструменты, как BSIMM, предоставляют объективный анализ, основанный на данных, на основе которого вы можете принимать решения о ресурсах, времени, бюджете и приоритетах. Если вы только начинаете программу безопасности или адаптируете существующую программу к изменяющимся потребностям бизнеса и безопасности, сравнение вашей программы безопасности программного обеспечения с другими может стать руководством для вашей стратегии.
Если вы отвечаете за программу безопасности программного обеспечения или только начинаете ее разрабатывать, понимание тенденций в области AppSec среди ваших коллег поможет вам внести стратегические улучшения в ваши усилия по обеспечению безопасности. Если вы управляете программой безопасности с технической точки зрения, вы можете использовать информацию, полученную в результате оценки BSIMM или Software Assurance Maturity Model (SAMM), для разработки тактических улучшений для людей и процессов, например, для развития программы Security Champions.

На самом деле, согласно отчету BSIMM, одна из первых задач, которую решают многие команды по безопасности ПО, - это выявление людей, которые являются движущей силой безопасности ПО, но не связаны напрямую с командой по безопасности ПО. Эти люди, известные под общим названием "сторонники безопасности ПО", могут поддерживать и стимулировать усилия по обеспечению безопасности ПО. Например, сторонники безопасности в команде инженеров могут поощрять инженеров брать на себя ответственность за безопасность их собственных программных продуктов.331 Респонденты TP3T назвали разработку программы сторонников безопасности одним из ключевых факторов успеха программы безопасности ПО.

Эффективность формальной оценки безопасности программного обеспечения с помощью таких моделей, как BSIMM и SAMM.

Важность кросс-функциональных команд для успеха DevSecOps

Респонденты 29% отметили, что кросс-функциональная команда DevSecOps - совместная команда разработчиков, специалистов по безопасности и операционного персонала - является ключом к успеху программы безопасности (см. Приложение Q16). Специалисты по безопасности в сотрудничестве с разработчиками/программистами и/или командами QA и тестирования (независимо от того, являются ли они формальной частью команды DevSecOps или нет) могут стать первой линией обороны для тестирования безопасности, помогая организациям создавать более зрелые программы безопасности.
Единая система тестирования до и после развертывания, осуществляемая командой безопасности, уходит в прошлое. В современной среде разработки программного обеспечения тестирование безопасности входит в обязанности всей инженерной команды, включая команды обеспечения качества, разработки и эксплуатации, и большинство команд встраивают защиту в свое программное обеспечение на различных этапах жизненного цикла разработки программного обеспечения.
331 респондент TP3T указал, что их организации также привлекают внешних консультантов для проведения тестирования безопасности. Лучшей практикой здесь является проведение регулярных аудитов безопасности. Привлечение стороннего аудитора или тестировщика на проникновение для проведения таких тестов имеет неоценимое значение для получения объективного представления о состоянии безопасности организации в целом.

Кто отвечает за тестирование безопасности в вашей организации? (отметьте все, что применимо)

Сочетание ручного и автоматизированного тестирования для достижения оптимальных результатов

Результаты опроса показывают, что большинство респондентов считают, что сочетание ручного и автоматизированного тестирования безопасности обеспечивает более комплексный подход к оценке безопасности критически важных для бизнеса приложений. Хотя автоматизированное тестирование важно для обеспечения последовательности, масштабируемости, а также экономии времени и средств, участие человека может добавить уровень проницательности и адаптивности, который необходим для выявления сложных и тонких проблем безопасности. Например, как и тестирование "черного ящика" (т. е. тестирование без знания внутреннего устройства приложения), DAST требует участия в процессе тестирования как разработчиков, так и разработчиков.эксперт по безопасностиВалидация и классификация результатов испытаний.
Аналогично, тот факт, что внешнее тестирование на проникновение рассматривается 441 респондентомTP3T как ключевой компонент тестирования безопасности, доказывает, что тестирование на проникновение является важным дополнением к внутреннему тестированию. Внешнее тестирование на проникновение часто проводится в соответствии с отраслевыми нормами и стандартами и может принести дополнительные преимущества, такие как объективная оценка уровня безопасности вашей организации и точное моделирование потенциальных угроз и уязвимостей, которые могут быть использованы внешними злоумышленниками.

Как вы оцениваете или тестируете безопасность критически важных для бизнеса приложений? (Выберите все, что применимо)

Ключевые показатели эффективности

В ходе опроса респондентам было предложено выбрать три ключевых показателя эффективности (KPI) для оценки успеха их программы DevSecOps. На первом месте оказался показатель "Общее сокращение числа открытых уязвимостей", на который указали 295 респондентов (29%), за ним следует показатель "Сокращение числа проблем, связанных с безопасностью, обнаруженных на поздних этапах SDLC", на который указали 288 респондентов (28%), а на третьем месте - "Сокращение числа проблем, связанных с безопасностью, обнаруженных на поздних этапах SDLC", на который указали 288 респондентов (28%). За ним следует "Сокращение количества проблем, связанных с безопасностью, обнаруженных на поздних этапах SDLC", на которое указали 288 респондентов (281 TP3T), а на третьем месте - "Время на решение проблем", на которое указал 281 респондент (281 TP3T).

Как показывают результаты опроса, время, производительность и затраты - это три общие черты предыдущих KPI и проблем, с которыми сталкиваются организации при внедрении безопасного SDLC. Или, другими словами, три основные проблемы, с которыми сталкиваются участники DevSecOps.

• Как уменьшить количество уязвимостей/проблем, с которыми мы сталкиваемся?
• Как найти уязвимости на более ранних этапах SDLC?
• Как сократить время решения проблем, чтобы уменьшить задержки при сборке и повысить эффективность разработки?

Какие основные KPI вы используете для оценки успешности деятельности DevSecOps? (выберите не более 3)

Какие инструменты AST вы используете? Полезны ли они?

Результаты исследования показывают, что успешные стратегии DevSecOps используют полный набор инструментов безопасности для решения проблем качества кода и безопасности на протяжении всего жизненного цикла разработки программного обеспечения, включая динамическое тестирование безопасности приложений (DAST), интерактивное тестирование безопасности приложений (IAST), статическое тестирование безопасности приложений (SAST) и инструменты анализа состава программного обеспечения (SCA).
Результаты опроса показали, что SAST является самым популярным инструментом AST: 72% респондентов сочли его полезным. За ним следуют IAST (69%), SCA (68%) и DAST (67%).
SAST и DAST используют разные методологии тестирования для разных этапов SDLC, причем SAST критически важен для обнаружения и устранения уязвимостей в собственном коде на ранних этапах SDLC (т.е. до развертывания приложения), а DAST подходит для обнаружения проблем в процессе эксплуатации, например, проблем аутентификации и конфигурации сети, после развертывания. SAST критически важен для обнаружения и устранения уязвимостей в собственном коде на ранних этапах SDLC (т. е. до развертывания приложения), в то время как DAST подходит для обнаружения проблем в процессе эксплуатации, таких как недостатки аутентификации и конфигурации сети, после развертывания, а IAST сочетает в себе некоторые функции как SAST, так и DAST для обнаружения существенных недостатков безопасности, которые невозможно выявить с помощью других типов тестирования.
SCA подходит для выявления и управления рисками безопасности и лицензирования открытого кода, что является ключевым требованием при разработке современного программного обеспечения, особенно когда более трех четвертей кода в любом приложении может быть с открытым исходным кодом. Поскольку многие организации используют пакетное программное обеспечение, приобретенное у независимых поставщиков, а также устройства Интернета вещей (IoT) и встроенное микропрограммное обеспечение, им также может потребоваться проведение бинарного анализа SCA в той или иной форме в рамках своего инструментария AST.

Являются ли полезными следующие средства обеспечения безопасности приложений, используемые вашей организацией (если таковые имеются)?

Когда проводить тестирование? Когда будут применяться исправления? Как это повлияет на наш рабочий график?

Частота тестирования безопасности приложений зависит от ряда факторов, включая критичность приложения для бизнеса на ежедневной основе, отрасль и ландшафт угроз. Как показывают результаты нашего опроса, очень критичные приложения должны оцениваться на регулярной основе (рис.). Большинство организаций-респондентов, принявших участие в этом опросе, указали, что проводят сканирование уязвимостей критически важных для бизнеса приложений в среднем два-три дня в неделю.
На первый взгляд, данные о том, что организациям с 281 TP3T требуется до трех недель для исправления основных уязвимостей (Рисунок I), могут показаться тревожными, но это следует рассматривать в контексте других факторов. Существует ошибочное мнение, что легендарные разработчики способны залатать все уязвимости, но никто не просит разработчиков копаться в несущественных уязвимостях без веской причины.
Стоит отметить, что основным препятствием для внедрения DevSecOps 311 TP3T респондентов назвали "отсутствие прозрачности в Dev/Ops", а 291 TP3T - "организационное разделение между Dev, Ops и безопасностью" (рис. 1). и 291 TP3T респондентов отметили "организационное разделение между разработкой, операциями и безопасностью" (рисунок). Оба эти фактора указывают на проблемы коммуникации между командами безопасности и разработки, а также на необходимость быстрого оповещения и автоматизации политик безопасности.
В любом случае приоритетность исправления уязвимостей должна быть согласована с бизнес-важностью исправляемого актива, его критичностью и риском его эксплуатации, особенно в последнем случае. Исследования показывают, что более половины всех уязвимостей используются в течение недели после раскрытия.

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

Сколько времени в среднем требуется вашей организации для исправления/устранения значительных рисков/уязвимостей безопасности в развернутых или используемых приложениях?

В результате организациям необходимо определять приоритеты устранения уязвимостей на основе оценок Common Vulnerability Scoring System (CVSS), информации Common Weakness Enumeration (CWE) и возможности использования уязвимостей не только в "нулевой день" раскрытия уязвимости, но и на протяжении всего жизненного цикла приложения.
Балл CVSS - это отраслевой стандарт для оценки серьезности угрозы. Каждая уязвимость в Национальной базе данных уязвимостей (NVD) имеет базовый балл, который помогает рассчитать серьезность уязвимости и определяет приоритетность ее устранения. CVSS score - это комплексный базовый балл, учитывающий возможность эксплуатации и влияние уязвимости.
Временной балл - это метрика, учитывающая изменения со временем, вызванные внешними по отношению к уязвимости событиями. Уровень исправления (есть ли официальная программа исправления?) и доверие к отчетности (подтвержден ли отчет?). и доверие к отчету (подтвержден ли отчет?). могут помочь скорректировать общий балл CVSS до соответствующего уровня риска.
В информации CWE перечислены дефекты программного или аппаратного обеспечения, имеющие последствия для безопасности, и CWE сообщает разработчикам, какие дефекты могут быть использованы (при наличии уязвимостей). Эта информация помогает командам безопасности и разработчиков понять, на чем следует сосредоточить обучение разработчиков по безопасности, какие дополнительные средства контроля безопасности следует внедрить в SDLC и на производстве, и нужно ли добавлять механизмы оценки степени риска. Например, команда разработчиков может присваивать различные приоритеты SQL-инъекциям, переполнениям буфера или отказу в обслуживании в зависимости от данных, с которыми работает приложение, места его развертывания и других факторов среды и безопасности.

Наличие уязвимости повышает оценку риска и помогает рабочей группе определить приоритетность исправлений для уязвимостей, представляющих наибольший риск. После оценки общего риска еще одним ключевым элементом информации, который необходимо учитывать, является знание того, доступны ли исправления, смягчения или компенсирующие элементы управления. Например, если у вас есть две уязвимости среднего риска, но неиспользуемые, то, какую из них исправить первой, может зависеть от того, есть ли для нее исправление или решение.
Серьезная проблема безопасности или уязвимости в развернутом приложении часто имеет каскадный эффект, который влияет не только на бизнес-операции организации (или ее клиентов), но и на SDLC в целом, как показано на диаграмме.
Проблемы могут быть незначительными, если они обнаружены на ранних этапах разработки, но они могут стать серьезными проблемами, требующими "всех сил", если они обнаружены в развернутом приложении. Автоматизированные средства тестирования безопасности, интегрированные в IDE и конвейеры CI, могут выявлять уязвимости и дефекты в коде сразу после (или даже до) его фиксации, позволяя разработчикам устранять проблемы до того, как они распространятся по сети.

За последний год (2022-2023 гг.) насколько сильно повлияло (если повлияло вообще) решение серьезной проблемы безопасности/уязвимости на план поставки программного обеспечения в вашей организации?

Проблемы, мешающие эффективному DevSecOps

Нехватка специалистов в области кибербезопасности - одна из основных проблем DevSecOps, как показано на рисунке К. Многие организации не могут нанять квалифицированных специалистов на ключевые должности в области кибербезопасности. По данным некоторых исследований, в мире насчитывается 3,5 миллиона вакансий в сфере кибербезопасности. По мере роста рынка квалифицированных специалистов по кибербезопасности дефицит предложения приведет к повышению заработной платы квалифицированных специалистов, что сделает их недоступными для многих государственных учреждений и малых и средних предприятий (МСП). Однако, как показано на рисунке K, "недостаточная подготовка разработчиков/инженеров в области безопасности" остается главной проблемой.
Проверенная стратегия решения этих проблем - создание программы чемпионов по безопасности, которая представляет собой группу людей из разных подразделений организации, проявляющих интерес к безопасности или обладающих навыками выше среднего уровня (и уже использующих свой опыт для поддержки команд разработки, обеспечения качества, эксплуатации и сопровождения). Поборники безопасности могут предлагать идеи и обратную связь по новым проектам, а также помогать командам безопасности или инженерам объединять навыки безопасности программного обеспечения со знаниями в области новых или быстро меняющихся технологий, которых им может не хватать. Тренеры по Agile, мастера scrum и инженеры DevOps - все они являются отличными кандидатами на роль сторонников безопасности, особенно в плане выявления и устранения трений в процессе.

Какие проблемы/барьеры стоят на пути внедрения DevSecOps в вашей организации? (Выберите все, что применимо)

Как уже упоминалось ранее в этом отчете, такие инструменты АСТ, как SAST, DAST, IAST и SCA, широко используются респондентами, однако эффективная увязка этих инструментов с потребностями бизнеса остается сложной задачей.
Многие опрошенные жаловались на то, что используемые ими инструменты тестирования безопасности не могут определить приоритетность мер по устранению уязвимостей на основе таких факторов, как подверженность, возможность использования и серьезность уязвимостей; они слишком медлительны для того, чтобы учесть быстрые циклы выпуска/непрерывного развертывания; а также неточны и ненадежны.
Не имея возможности консолидировать или соотнести результаты различных тестов безопасности, команды безопасности и DevOps тратят слишком много времени на выявление уязвимостей, которые необходимо устранить в первую очередь, что может быть одной из причин того, что почти три четверти респондентов отметили, что их организации требуется от двух недель до месяца для исправления известных критических уязвимостей.
Неспособность быстро устранить уязвимости затрагивает фундаментальные интересы. Более 80% респондентов отметили, что устранение серьезных уязвимостей или связанных с ними проблем безопасности в развернутом программном обеспечении повлияло на их рабочий график в 2022-2023 годах.

Фрагментация и медленное устранение проблем с помощью инструментов AST - это то, что призваны решить проблемы Application Security Orchestration and Correlation (ASOC) и Application Security Situation Management (ASPM). Gartner отмечает, что ASOC/ASPM могут выступать в качестве уровня управления для оркестровки нескольких инструментов AST, автоматизируя корреляцию и контекстуализацию обнаруженных проблем для ускорения и оптимизации процесса устранения.

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

Какие основные проблемы связаны с инструментами тестирования безопасности приложений, используемыми в вашей организации? (выберите не более 3)

Обещания и проблемы искусственного интеллекта

Результаты исследования показывают, что ИИ проник в программы безопасности программного обеспечения многих организаций: более 501 TP3T респондентов заявили, что активно используют ИИ в своей практике DevSecOps.541 TP3T респондентов используют ИИ для повышения эффективности и точности своих мер безопасности.481 TP3T респондентов используют ИИ для сокращения ручного анализа тестов безопасности. тестов вручную.
Это имеет смысл, если учесть основные преимущества, которые ИИ может потенциально предоставить DevSecOps. Команды AppSec часто оказываются перед дилеммой между необходимостью полного и последовательного тестирования безопасности и необходимостью идти в ногу с командами разработчиков, использующих методологии DevOps и конвейеры CI. Когда сроки поджимают, разработчики легко пропускают критически важные процессы оценки рисков безопасности.
В качестве двух основных целей внедрения ИИ в SDLC по безопасности респонденты назвали "Повышение точности и эффективности мер безопасности" (54%) и "Сокращение необходимости ручного просмотра и анализа данных по безопасности" (48%). Две основные цели внедрения ИИ в SDLC безопасности заключаются в следующем
Однако следует отметить, что участники интервью также отметили, что, по их мнению, ИИ "повысит сложность и технические требования к безопасности программного обеспечения" и что может наступить момент, когда единственным субъектом, способным адекватно проверять созданный ИИ код, будет сам ИИ.

Внедрение ИИ в DevSecOps сопряжено с дополнительными проблемами, такими как обеспечение качества данных и решение вопросов безопасности и конфиденциальности. Поскольку инструменты ИИ все чаще интегрируются в конвейеры DevOps, они почти наверняка станут главными мишенями для угроз безопасности. Работа с конфиденциальными данными, используемыми для обучения ИИ, также вызывает вопросы конфиденциальности.
Использование ИИ сопряжено с рядом потенциальных рисков, например, при кодировании с помощью ИИ могут возникнуть проблемы с правом собственности, авторским правом и лицензированием кода, созданного ИИ.
В конце 2022 года против компаний GitHub, Microsoft и OpenAI был подан коллективный иск, в котором утверждается, что GitHub Copilot - облачный инструмент искусственного интеллекта, предоставляющий разработчикам автоматические дополнительные предложения при кодировании, - нарушает закон об авторском праве и требования лицензирования программного обеспечения, а открытый исходный код, используемый для обучения Copilot. Открытый исходный код, используемый для обучения сервисов Copilot, также нарушает права разработчиков. В иске также утверждается, что код, предлагаемый Copilot, использует лицензионные материалы без указания авторства, уведомлений об авторских правах или соблюдения условий оригинальной лицензии.

Генеративные ИИ-чатботы, основанные на крупномасштабных языковых моделях, такие как ChatGPT и Google Bard, также страдают от проблемы случайного генерирования "иллюзий", то есть ответов, которые, хотя и кажутся достоверными и уверенными, на самом деле неверны - или, выражаясь обывательским языком, "лживы". "Ложь".
Галлюцинации ИИ явно угрожают безопасности цепочки поставок программного обеспечения. Исследователи обнаружили, что ChatGPT может предлагать иллюзорные, несуществующие кодовые базы или пакеты программного обеспечения. Злоумышленники могут создавать пакеты с таким же названием, наполнять их вредоносным кодом, а затем распространять среди ничего не подозревающих разработчиков, которые следуют советам ИИ. Это может оказать разрушительное воздействие на киберпреступников, позволив им обойти более традиционные и легко обнаруживаемые методы, такие как опечатки или маскировка. Исследователи обнаружили, что пакеты вредоносного ПО, созданные на основе призрачных советов ChatGPT, уже существуют в популярных менеджерах пакетов, таких как PyPI и npm.
Эта угроза не теоретическая, она реальна и имеет место быть. Независимо от того, исходит ли атака на цепочку поставок от галлюцинации ИИ или от злоумышленника, для защиты от нее крайне важно понимать источник кода, проверять личность разработчиков и сопровождающих и загружать пакеты только от надежных поставщиков или источников.

Извлеченные уроки

Несмотря на то, что большинство организаций в значительной степени внедрили некоторые практики DevSecOps, они по-прежнему сталкиваются с проблемами при их эффективном применении. Исследование показало, что проблемы сосредоточены в двух основных областях.
- Интегрировать и согласовывать результаты многочисленных инструментов тестирования безопасности приложений (AST) с приоритетами бизнеса.
- Сокращение времени, необходимого для устранения критических уязвимостей
28% респондентов отметили, что их организации требуется до трех недель для исправления основных рисков/уязвимостей безопасности в развернутых приложениях. Еще 20% респондентов отметили, что на исправление уязвимостей может уходить до месяца, но большинство уязвимостей эксплуатируется в течение нескольких дней после раскрытия. Респонденты отметили, что больше всего их беспокоит неспособность инструментов AST определять приоритетность исправлений уязвимостей в зависимости от потребностей бизнеса.
Как отмечалось во введении к этому отчету, одной из проблем при разработке анкеты было то, что термин "DevSecOps" охватывает целый ряд различных дисциплин, многие из которых имеют свои собственные уникальные роли. Что касается "бизнес-приоритетов", то разные роли могут по-разному понимать этот термин.
Например, руководители компаний больше всего заинтересованы в получении информации об эффективности инструментов AppSec, они хотят иметь полное представление о процессе и о том, как он может повысить эффективность работы их команд. Команды разработчиков и операторов хотят, чтобы AppSec помог им централизованно просматривать все проблемы и выявлять наиболее ценные мероприятия по обеспечению безопасности. Специалисты по безопасности хотят избавиться от шума, чтобы быстро определять приоритеты и решать критические проблемы.
Решение Application Security Posture Management (ASPM) может обеспечить необходимые усовершенствования для организаций, которые пытаются объединить разрозненные инструменты безопасности и удовлетворить потребности бизнеса, автоматически организуя, контекстуализируя и определяя приоритеты разрозненных инструментов, чтобы организации могли сосредоточиться на вопросах безопасности приложений, которые наиболее важны для бизнеса.
- ASPM может быть интегрирован с инструментами разработки и тестирования безопасности, а также с инструментами мониторинга операций и обслуживания, чтобы обеспечить интегрированное единое представление информации, связанной с безопасностью, в рамках всей организации.
- Соотнося и группируя данные из различных инструментов, анализирующих конкретные приложения и уязвимости, ASPM может предоставить комплексное представление о состоянии безопасности приложения в целом. Команды DevSecOps могут генерировать данные, соответствующие их ролям и обязанностям, а ASPM может представить эти данные таким образом, чтобы они были понятны линейным менеджерам и другим лицам, которым нужна более широкая перспектива. Команда DevSecOps может генерировать данные, соответствующие их ролям и обязанностям, а ASPM может представлять эти данные таким образом, чтобы они были понятны линейным менеджерам и другим лицам, которым нужна более широкая перспектива.
- ASPM позволяет разрабатывать и применять политики безопасности, направленные на устранение специфических рисков, связанных с конкретными приложениями и уязвимостями. ASPM также позволяет выявлять и устранять проблемы безопасности на самых ранних стадиях при интеграции с инфраструктурой разработки или эксплуатации.
В отчете Gartner за 2021 год говорится следующее. Примерно 51 TP3T опрошенных организаций внедрили ASPM или его предшественника, инструмент Application Security Orchestration and Correlation (ASOC), и Gartner ожидает, что темпы внедрения будут быстро расти. Этот прогноз подтверждается результатами исследования 2023 года, в котором 281 TP3T опрошенных организаций уже начали использовать ASOC/ASPM. Gartner также отмечает, что ранние последователи, как правило, являются командами с развитыми программами DevSecOps и используют несколько инструментов безопасности, что характерно и для наших респондентов, участвовавших в опросе DevSecOps.

Характеристика респондентов

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

Отраслевое распределение респондентов