Когда Ник Вудхед общался с Business Insider, он не спал почти 48 часов, занимаясь устранением критических уязвимостей в PHP. Технический директор Rothco и Compubox помогал своим командам обновлять системы, проверять логи на наличие признаков взлома и защищать старые инсталляции в ожидании бэкпортированных исправления. У его организации уже была инфраструктура для развертывания патчей, однако ликвидация последствий всё равно потребовала значительных ручных усилий.

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

Управлять этими требованиями становится еще сложнее, когда поступает несколько уведомлений одновременно. В своем анализе от 22 октября «После PHP и eMudhra наступает очередь Node.js» компания Checkmarx Zero рассмотрела релиз безопасности Node.js, в котором за ту же неделю устранялись десять уязвимостей. Командам, отвечающим за обе технологии, пришлось оценивать еще один набор обновлений, в то время как их текущая работа по безопасности приложений продолжала ожидать своей очереди.

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

Инцидент с PHP также иллюстрирует, почему меры реагирования должны соответствовать типу уязвимости. В рекомендации по безопасности PHP описывается вектор атаки, который может реализоваться до того, как запустится код приложения, поэтому затронутые инсталляции требуют обновления среды выполнения. Сканирование приложений не может заменить этот патч. Более широкий урок для AppSec заключается в том, чтобы проанализировать работу, которую можно оптимизировать в рамках собственных результатов поиска: определить, является ли уязвимый путь доступным для атаки, подготовить предлагаемое изменение и предоставить разработчику достаточно доказательств для его проверки.

Такой подход согласуется с рекомендациями Checkmarx Zero по укреплению безопасности приложений: Даррен Мейер (Darren Meyer) призывает к получению обратной связи по безопасности на более ранних этапах разработки, приоритизации на основе возможности эксплуатации, а также к помощи ИИ при триаже и устранении уязвимостей с последующим одобрением человека. Внедрение этих практик в повседневные рабочие процессы помогает командам устранять проблемы до того, как они накопятся, и снижает объем расследований, необходимых для тех задач, которые попали в бэклог.

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

Сократите объем работы, попадающей в бэклог

Лучшее время для устранения недавно появившейся проблемы в коде — пока у разработчика открыт соответствующий файл. Checkmarx Developer Assist интегрирует анализ безопасности и рекомендации по исправлению в поддерживаемые среды IDE и рабочие процессы ИИ-кодинга, помогая разработчикам находить проблемы в коде, созданном людьми и ИИ, вносить изменения и повторно сканировать свой код. В поддерживаемых автономных рабочих процессах инструмент может работать совместно с агентом кодирования для повторного устранения уязвимостей и сканирования. Решение проблем на этом этапе снижает объем работ по расследованию, передаваемых в AppSec, благодаря чему меньше рутинных находок конкурируют за внимание, когда критическое уведомление требует срочного реагирования.

По мере того как код переходит в пул-реквесты (pull requests) и конвейеры CI/CD, качество результатов начинает определять нагрузку на команду. Ложные срабатывания отнимают время на расследование, в то время как пропущенные уязвимости остаются вне плана исправления, и то и другое влияет на людей, отвечающих как за рутинную безопасность приложений, так и за срочное реагирование.

Checkmarx Fusion SAST объединяет проверенный анализ безопасности Checkmarx с рассуждениями передовых моделей (frontier-model reasoning) для выявления дополнительных уязвимостей, в то время как модуль Findings Analysis Engine оценивает и консолидирует их результаты, снижая уровень шума от ложноположительных срабатываний и дублирующихся находок.

Опубликованные показатели F1 компании Checkmarx отражают это улучшение: 0,64 для ее основы Next-Gen SAST и 0,74 для Fusion SAST. F1 объединяет точность (precision — доля реальных уязвимостей среди заявленных) и полноту (recall — доля обнаруженных реальных уязвимостей). Измерение обоих показателей позволяет учесть как риски, пропущенные сканером, так и лишнюю работу, которую могут создать его находки.

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

Сделайте следующий шаг в принятии решений более обоснованным

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

Анализ может установить статус находки как «Подтверждено» (Confirmed), когда проблема доступна и может быть проэксплуатирована, или как «Предположительно не эксплуатируемо» (Proposed Not Exploitable), когда определяется отсутствие любого из этих условий. Статус «Предположительно не эксплуатируемо» остается рекомендацией для проверки, поэтому команда может изучить обоснование, прежде чем принимать решение о том, как поступить с находкой. Обоснование остается доступным рядом с находкой в Risk Orchestration вместе с историей изменения статуса. Разработчики и последующие проверяющие могут видеть, как был сделан такой вывод, что помогает им продолжить работу без повторного расследования.

Начните подготовку исправления без дополнительных ручных запросов

Как только находка выбрана для устранения, следующим шагом становится подготовка изменений, которые разработчик может оценить. Решение Remediation Assist генерирует предлагаемые исправления для поддерживаемых уязвимостей, а необходимые рекомендации доступны прямо в интерфейсе Checkmarx One.

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

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

Интегрируйте исправление в большее число рабочих процессов разработки

Лучшее время для устранения недавно обнаруженной проблемы в коде — пока разработчик еще не закрыл соответствующий файл. Checkmarx Developer Assist переносит анализ безопасности и рекомендации по исправлению в поддерживаемые среды IDE и рабочие процессы ИИ-кодинга, помогая разработчикам находить проблемы как в написанном человеком, так и в созданном ИИ коде, вносить изменения и повторно сканировать свой код. В поддерживаемых автономных рабочих процессах он может взаимодействовать с агентом кодинга для повторного исправления и сканирования. Устранение проблем на этом этапе сокращает объем расследований, передаваемых в отдел AppSec, благодаря чему меньше рутинных находок конкурируют за внимание, когда критическое раскрытие информации требует срочного реагирования.

По мере того как код переходит в пул-реквесты и конвейеры CI/CD, качество находок начинает формировать рабочую нагрузку команды. Ложноположительные результаты отнимают время на расследование, в то время как пропущенные уязвимости остаются вне плана исправления, и то и другое влияет на людей, отвечающих как за ручную безопасность приложений, так и за оперативное реагирование.

Checkmarx Fusion SAST сочетает проверенный анализ безопасности Checkmarx с рассуждениями передовых моделей для выявления дополнительных уязвимостей, в то время как Findings Analysis Engine оценивает и объединяет их результаты, сокращая количество ложных срабатываний и дублирующихся находок.

Опубликованные показатели F1 для Checkmarx отражают улучшение: 0,64 для фундаментальной платформы Next-Gen SAST и 0,74 для Fusion SAST. F1 объединяет точность (долю реальных находок среди всех заявленных) и полноту (долю обнаруженных реальных уязвимостей). Измерение обоих показателей учитывает как риски, которые пропускает сканер, так и ненужную работу, которую могут создать его находки. Для руководителя AppSec практический вывод заключается в том, что размер бэклога сам по себе дает неполную картину прогресса. Более мощное обнаружение может первоначально увеличить количество известных уязвимостей за счет выявления проблем, которые уже присутствовали, в то время как меньшая очередь может также скрывать пробелы в покрытии. Поэтому командам необходимо понимать, какой реальный риск они находят, сколько усилий уходит на отклонение недействительных находок и как быстро подтвержденные проблемы продвигаются к исходу.

Сделайте следующее решение более обоснованным

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

Анализ может установить статус находки как Confirmed (Подтверждено), когда проблема достижима и уязвима для эксплуатации, или Proposed Not Exploitable (Предположительно неэксплуатируема), если он определяет отсутствие любого из этих условий. Статус Proposed Not Exploitable остается рекомендацией для рассмотрения, поэтому команда может изучить обоснование, прежде чем принимать решение о том, как поступить с находкой. Обоснование остается доступным рядом с находкой в Risk Orchestration вместе с историей изменения статуса. Разработчики и последующие проверяющие могут видеть, как было получено заключение, что помогает им продолжать работу без повторного проведения расследования.

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

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

Интегрируйте исправление в большее число рабочих процессов разработки

С предложенным исправлением проще работать, когда оно вписывается в существующий процесс ревью команды. Для поддерживаемых проектов интеграции с репозиториями кода GitHub и Azure DevOps Remediation Assist может создать отдельный пул-реквест с предложенными изменениями, чтобы разработчики могли изучить дифф, обсудить корректировки и утвердить исправление в том репозитории, где они уже управляют своим кодом.

Команды, использующие другие рабочие процессы, также могут переносить предложенные изменения из Checkmarx One в свою среду разработки. Начиная с 1 ноября, опции внутри Checkmarx One позволяют разработчикам копировать дифф, скачивать патч или копировать подготовленный промпт для агента кодинга на базе ИИ. Эти параметры поддерживают ручные и импортированные проекты (как с интеграцией SCM, так и без нее), сокращая усилия, необходимые для превращения рекомендаций по исправлению в изменения кода.

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

Сделайте прогресс видимым для тех, кто управляет рисками

Во время интенсивного устранения проблем открытие каждой находки для выяснения того, была ли она оценена или имеет ли она предложенное исправление, создает собственную очередь. Также запланированные на начало ноября новые столбцы Attackability и Remediation в Risk Orchestration добавляют эти результаты в таблицу результатов SAST и SCA, обеспечивая сортировку и фильтрацию для помощи командам в работе с ними.

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

Подготовьтесь к следующему раскрытию информации

Раскрытие уязвимостей в PHP и Node.js показывает, как быстро срочные задачи по безопасности могут вступать в противоречие с приложениями, которые команды по-прежнему должны поддерживать и выпускать.

Объединение Developer Assist, Fusion SAST, Triage Assist и Remediation Assist помогает сократить объем рутинной работы, отвлекающей инженерные ресурсы. Обратная связь по безопасности в процессе разработки позволяет разработчикам устранять проблемы, пока они еще хорошо понимают код. По мере того как результаты анализа поступают в AppSec, более эффективное обнаружение и анализ атакуемости предоставляют доказательства для принятия решений о том, где действовать, а предложенные изменения дают разработчикам отправную точку для исправления. Сокращение времени, затрачиваемого на восстановление контекста, расследование ложных срабатываний и подготовку исправление, помогает командам поддерживать повседневную работу по безопасности, когда очередной срочный отчет об уязвимости нарушает их планы.

Этим людям по-прежнему придется принимать сложные решения, но в момент принятия у них перед глазами будут все данные и предложенные изменения.