Последняя директива CISA переносит акцент с степени серьезности или количества уязвимостей на реальный контекст рисков при принятии решений об устранении. Для федеральных команд по кибербезопасности этот сдвиг приобретает все большее значение, поскольку уязвимости обнаруживаются быстрее, чем команды успевают их исправлять.
Когда каждая проблема высокой степени серьезности воспринимается как одинаково срочная, владельцы систем вынуждены выбирать между безопасностью и поддержанием работоспособности критически важных систем. Команды также могут тратить драгоценное время на разбор уязвимостей с меньшим риском вместо того, чтобы сосредоточиться на тех из них, которые представляют наибольшую угрозу. Вопрос заключается уже не просто в том, сколько существует рисков, а в том, какие из них требуют действий в первую очередь и как применять этот подход последовательно на протяжении всего жизненного цикла программного обеспечения.
Директива CISA Binding Operational Directive (BOD) 26-04 воплощает этот подход, основанный на оценке рисков, на практике для агентств Федерального гражданского исполнительного департамента. Эта директива, выпущенная 10 июня 2026 года, заменяет более старые директивы BOD 19-02 и BOD 22-01. Вместо того чтобы полагаться исключительно на оценку серьезности по шкале CVSS или каталог известных проэксплуатированных уязвимостей (KEV), BOD 26-04 учитывает четыре основных фактора:
- Подвержен ли затронутый актив публичному воздействию?
- Включена ли уязвимость в каталог известных проэксплуатированных уязвимостей CISA?
- Может ли злоумышленник автоматизировать эксплуатацию?
- Предоставит ли успешная эксплуатация злоумышленнику частичный или полный контроль над активом?
Исходя из этих ответов, у агентств есть 3, 14 или 60 дней на устранение проблемы, причем некоторые уязвимости подлежат устранению во время следующего крупного обновления системы. В наиболее серьезных случаях также может потребоваться судебно-медицинский анализ, чтобы определить, была ли система уже скомпрометирована. BOD 26-04 не означает, что агентства могут меньше заниматься патчами. Это означает, что им необходимо использовать контекст рисков для принятия более разумных решений о том, что исправлять в первую очередь.
Самое важное изменение — это вовсе не трехдневный срок
Трехдневный дедлайн привлечет больше всего внимания, но более масштабное изменение заключается в том, что агентства должны знать еще до того, как этот отсчет времени начнется. Оценка серьезности дает меру общего технического риска, но она не показывает, подвержен ли актив воздействию, эксплуатируется ли уязвимость, чем может завладеть злоумышленник и как этот риск может повлиять на выполнение задачи.
BOD 26-04 меняет вопрос с: «Насколько серьезна эта уязвимость?» на «Какой риск создает эта уязвимость здесь, в текущих условиях, и каких действий требует это подтверждение?»
Это различие имеет практическое значение. В ходе первой проверки CISA в крупном гражданском ведомстве лишь 1% уязвимостей потребовал устранения в течение трех дней, в то время как более 60% могли ждать будущего обновления системы. Больший контектекст не означал меньшую безопасность; он дал командам более четкую основу для сосредоточения усилий там, где задержки обойдутся дороже всего.
Директива также дает понять, что устранение не всегда заканчивается применением патча. Когда появляются свидетельства того, что уязвимость могла быть уже проэксплуатирована, командам может потребоваться провести проверки для определения того, была ли система скомпрометирована. Устранение уязвимости решает проблему слабого места; проверка безопасности системы устраняет вероятность того, что слабое место уже было использовано.
В совокупности эти изменения указывают на более масштабный сдвиг в управлении федеральными уязвимостями: от простого закрытия найденных проблем к использованию фактических данных для понимания риска, определения ответственности и снижения рисков, которые имеют наибольшее значение.
CISA может предоставить контекст угроз. Агентства должны предоставить контекст среды
Модель реализации CISA четко определяет разделение ответственности. CISA публикует статус известной эксплуатации через каталог KEV и предоставляет анализ возможности автоматизации эксплойтов и технического воздействия через свою программу Vulnrichment. Однако агентства должны обеспечить контекст среды: подвержен ли затронутый актив публичному воздействию? Какое программное обеспечение вы используете? Где оно находится? Что доступно из интернета? Кто владеет каждой системой? И как быстро команды могут реагировать.
Этот контекст может изменить уровень риска, даже если CVE остается прежним. Например, рабочая нагрузка может стать общедоступной, уязвимость может быть добавлена в каталог KEV или новый анализ может показать, что ее проще использовать, чем предполагалось изначально. Уязвимость с низким приоритетом может внезапно стать срочной, пока она ожидает своей очереди в бэклоге.
Именно поэтому агентствам требуется нечто большее, чем просто разовая оценка. Им нужен постоянный, непрерывно обновляемый обзор, который связывает данные об уязвимостях, сведения о программном обеспечении, подверженность активов рискам, права собственности, прогресс в устранении и подтверждающие данные. Без этого политика на основе рисков — это просто упражнение в электронных таблицах. С ее помощью политика превращается в реальную систему принятия мер.
Такая же логика должна распространяться вверх по цепочке на разработку программного обеспечения
BOD 26-04 фокусируется на обновлениях безопасности для уже используемых технологий, но лежащий в ее основе основной принцип должен применяться ко всему жизненному циклу программного обеспечения.
У каждой производственной уязвимости есть предыстория. Она может происходить из пользовательского кода, зависимости с открытым исходным кодом, образа контейнера или инфраструктуры как кода. К тому моменту, как уязвимость доходит до общедоступной системы и начинается трехдневный отсчет, агентства сталкиваются с проблемой на самом дорогостоящем и критичном по времени этапе.
Безопасность федерального ПО не может ждать этапа производства для сбора контекста, необходимого для оценки рисков и управления ими. Этот контекст необходим агентствам от разработки до развертывания, чтобы они могли избежать ненужных рисков, быстро реагировать на их изменение и демонстрировать, как они этими рисками управляют.
Для этого требуются три изменения:
- Увидеть полную картину подверженности ПО рискам
Инвентаризация активов имеет значение, но ее недостаточно. Агентствам также необходимо связать приложения, репозитории, компоненты с открытым исходным кодом, зависимости, образы контейнеров и инфраструктуру с системами и функциями задач, которые они поддерживают.
SBOM может показать наличие компонента, но действенная аналитика программного обеспечения должна отвечать на большее количество вопросов: какое приложение его использует? Можно ли получить доступ к рискованному коду? Развернуто ли приложение? Подвержено ли оно публичному воздействию? Кто несет ответственность за его исправление? От какой задачи оно зависит?
Цель состоит не в создании очередного списка. Цель — обеспечить отслеживаемость: от компонента программного обеспечения, в котором возникает риск, до системы, на которую он влияет, и последствий, которые возникнут в случае его эксплуатации.
- Объединить аналитику рисков и управление
BOD 26-04 демонстрирует, почему данные об уязвимостях не должны оставаться изолированными по инструментам, программам, подрядчикам или этапам жизненного цикла ПО. Агентствам необходим единый взгляд на риск, который связывает результаты анализа кода и зависимостей с возможностью эксплуатации, доступностью, подверженностью угрозам, правом собственности и важностью для выполнения задач.
Директива устанавливает федеральный стандарт обработки срочных обновлений безопасности. Но агентствам также необходимы четкие правила управления результатами проверок безопасности на более ранних этапах процесса разработки, включая контрольные точки безопасности, ожидания по устранению проблем, критерии для исключений, ответственных владельцев, резервные элементы управления и сроки для принятых рисков.
Эти стандарты должны одинаково применяться как к внутренним командам разработки, так и к программному обеспечению подрядчиков. Владельцы проектов не должны получать один тип доказательств от команд ведомства и совершенно другой — от подрядчиков. Цель состоит в создании единого стандарта обеспечения безопасности программного обеспечения, который делает решения о рисках более простыми для понимания, рассмотрения и обоснования.
- Ускоренное проверенное снижение рисков
Приоритезация рисков помогает командам сосредоточиться, но она не создает автоматически дополнительные ресурсы для устранения проблем. Ведомства должны использовать этот фокус для борьбы с рисками как можно раньше: предотвращать попадание небезопасных зависимостей в сборки, находить устранимые дефекты до выпуска, применять политики в конвейере поставки и предоставлять разработчикам четкую информацию в их инструментах.
Когда уязвимость все же попадает в производство, подготовительная работа уже должна быть выполнена. Команды должны знать, кому принадлежит система, понимать ее зависимости и уровень воздействия, иметь подтверждающие доказательства и знать, какие действия предпринять.
Команды безопасности не должны тратить первые часы трехдневного окна только на то, чтобы выяснить, где работает приложение, какие зависимости оно содержит, кто является подрядчиком или кто может принимать решения.
Смысл здесь заключается в том, чтобы максимально быстро снизить риски для миссии и иметь возможность обосновать, почему реакция была адекватной.
Что ведомства должны уметь доказывать
Современная федеральная программа безопасности программного обеспечения должна уметь отвечать на пять вопросов без запуска ручной процедуры восстановления:
- Где находится уязвимое программное обеспечение? Определите каждое затронутое приложение, компонент, образ, репозиторий и развернутую рабочую нагрузку.
- Каково реальное воздействие? Свяжите результаты с доступностью, возможностью эксплуатации, публичной доступностью и влиянием на миссию.
- Кто принимает решение? Направьте действия на подотчетную команду разработки, владельца системы, подрядчика или программный офис.
- Что изменилось? Пересчитайте приоритет при изменении воздействия, доказательств эксплуатации, состава программного обеспечения или состояния развертывания.
- Можем ли мы доказать результат? Сохраняйте доказательства устранения, снижения рисков, исключения, проверки и, при необходимости, передачи для проведения криминалистического анализа.
Это не просто вопросы соответствия. Они показывают, способно ли ведомство превратить информацию о безопасности в реальные, скоординированные действия так быстро, как это необходимо для миссии.
Где Checkmarx находит свое место
Хотя ни один отдельный продукт для безопасности приложений не может полностью соответствовать BOD 26-04, Checkmarx может помочь ведомствам создать необходимый контекст программного обеспечения для выявления и приоритезации рисков, ускорения устранения и поддержания доказательств и управления, необходимых для своевременных и обоснованных решений.
Checkmarx One for Government (CxG) Application Security Posture Management (ASPM) объединяет результаты сканирования безопасности приложений с таким контекстом, как возможность эксплуатации, достижимость и воздействие во время выполнения. Checkmarx One for Government (CxG) объединяет SAST, SCA, безопасность инфраструктуры как кода, безопасность контейнеров, обнаружение вредоносных пакетов и ASPM в сертифицированной платформе FedRAMP, поддерживая согласованную безопасность как для разработки силами ведомства, так и силами подрядчиков.
С помощью Checkmarx One for Government (CxG) федеральные команды могут:
- Связывать результаты проверки программного обеспечения в коде, зависимостях с открытым исходным кодом, инфраструктуре, контейнерах и облачных средах.
- Выявлять и приоритизировать важные риски на более ранних этапах жизненного цикла разработки.
- Применять единообразные политики для различных программ, команд разработчиков и подрядчиков.
- Сохранять прослеживаемость и доказательства, необходимые для надзора, авторизации и непрерывного мониторинга.
- Сокращать количество фрагментированных передач управления, которые отнимают время при возникновении критических рисков.
Реальная ценность заключается в том, чтобы упростить увязку воздействия программного обеспечения с ответственными действиями.
Будущее за оценкой на основе доказательств
BOD 26-04 устанавливает подход к устранению уязвимостей на основе рисков для ведомств Федеральной гражданской исполнительной ветви власти. Но это представляет собой нечто большее, чем просто новый набор сроков. Это сигнализирует о более широком операционном сдвиге в федеральном гражданском секторе: от подсчета уязвимостей к пониманию последствий, от статической критичности к текущему контексту и от завершенных задач к проверенному снижению рисков.
Достижение этого стандарта требует большего, чем просто добавление еще одной очереди на устранение. Ведомствам нужна операционная модель, которая объединяет данные о программном обеспечении, активах, угрозах, правах собственности и политиках достаточно быстро для поддержки решений миссии. Критичность говорит ведомствам о том, к чему может привести уязвимость; контекст подсказывает, угрожает ли она на самом деле миссии.
Ведомства, наиболее подготовленные к выполнению директивы, — это те, которые смогут превратить этот контекст в своевременные, обоснованные действия и продемонстрировать доказательства, лежащие в основе их решений. Именно это в конечном итоге должно обеспечить управление уязвимостями на основе рисков: не просто меньшее количество открытых уязвимостей, а более четкое, доказуемое снижение рисков для миссии.
Теги:
Agentic AI
Agentic AppSec
AI Agents
AI Governance
Federal Government
