Новейшая директива CISA смещает акцент с уровня серьезности или количества выявленных проблем на фактический контекст риска при принятии решений о способах устранения уязвимостей. Для федеральных групп кибербезопасности этот сдвиг становится все более важным, поскольку уязвимости обнаруживаются быстрее, чем команды успевают их исправлять.
Когда каждая проблема высокой степени серьезности рассматривается как одинаково срочная, владельцы систем вынуждены выбирать между безопасностью и поддержанием работоспособности критически важных систем. Команды также могут тратить драгоценное время на разбор менее рискованных находок вместо того, чтобы сосредоточиться на уязвимостях, представляющих наибольшую угрозу. Вопрос больше не стоит просто в том, насколько велик риск, а в том, какие риски требуют действий в первую очередь — и как последовательно применять этот подход на протяжении всего жизненного цикла программного обеспечения.
Обязательная оперативная директива (BOD) 26-04 от CISA внедряет этот риск-ориентированный подход в практику федеральных гражданских исполнительных органов власти. Выпущенная 10 июня 2026 года, эта директива заменяет старые директивы BOD 19-02 и BOD 22-01. Вместо того чтобы полагаться исключительно на оценку серьезности по шкале CVSS или каталог известных эксплуатируемых уязвимостей (KEV), BOD 26-04 учитывает четыре основных фактора:
- Является ли затронутый актив общедоступным?
- Включена ли уязвимость в каталог известных эксплуатируемых уязвимостей (KEV) CISA?
- Может ли злоумышленник автоматизировать эксплуатацию?
- Приведет ли успешная эксплуатация к частичному или полному контролю злоумышленника над активом?
На основе этих ответов у агентств есть 3, 14 или 60 дней на устранение проблемы, при этом некоторые уязвимости могут быть исправлены во время следующего крупного обновления системы. Наиболее серьезные случаи могут также потребовать проведения криминалистического анализа для определения того, была ли система уже скомпрометирована. BOD 26-04 не означает, что агентства могут меньше заниматься исправлением уязвимостей. Это означает, что им необходимо использовать контекст риска для принятия более разумных решений о том, что исправлять в первую очередь.
Самое важное изменение — это не трехдневный срок
Трехдневный срок привлечет наибольшее внимание, но более значимым изменением является то, что агентства должны знать еще до того, как этот отсчет начнется. Оценка серьезности дает представление об общем техническом риске, но не показывает, открыт ли актив для доступа, эксплуатируется ли уязвимость, что именно может контролировать злоумышленник или как риск может повлиять на выполнение задач.
BOD 26-04 меняет вопрос с «Насколько серьезна эта уязвимость?» на «Какой риск создает эта уязвимость здесь, в текущих условиях, и каких действий требует это доказательство?»
Это различие имеет значение на практике. В ходе первой проверки CISA в крупном гражданском ведомстве только 1% уязвимостей требовал устранения в течение трех дней, в то время как более 60% могли подождать до будущего обновления системы. Больше контекста не означало снижение безопасности; это дало командам более четкое основание для концентрации усилий там, где задержки были бы наиболее дорогостоящими.
Директива также дает понять, что устранение не всегда заканчивается применением патча. Когда есть доказательства того, что уязвимость, возможно, уже была использована, командам может потребоваться проведение криминалистических проверок, чтобы определить, была ли система скомпрометирована. Исправление уязвимости устраняет слабое место; проверка безопасности системы учитывает вероятность того, что этим слабым местом уже воспользовались.
В совокупности эти изменения указывают на более широкий сдвиг в управлении федеральными уязвимостями: от простого закрытия найденных проблем к использованию доказательств для понимания рисков, определения приоритетов агентства и снижения наиболее значимых рисков.
CISA может предоставить контекст угроз. Агентства должны предоставить контекст среды
Модель реализации CISA делает разделение ответственности понятным. CISA публикует статус известной эксплуатации через каталог KEV и предоставляет анализ автоматизируемости эксплуатации и технического воздействия через свою программу Vulnrichment. Агентства, однако, должны предоставить контекст среды: является ли затронутый актив общедоступным? Какое программное обеспечение вы используете? Где оно находится? Что доступно из интернета? Кто владеет каждой системой? И как быстро команды могут реагировать.
Этот контекст может изменить уровень риска, даже если CVE остается прежним. Например, рабочая нагрузка может стать общедоступной, уязвимость может быть добавлена в каталог KEV, или новый анализ может показать, что ее проще эксплуатировать, чем предполагалось ранее. Уязвимость с низким приоритетом может внезапно стать срочной, пока она находится в очереди на исправление.
Вот почему агентствам нужно нечто большее, чем разовая оценка. Им нужен постоянный, непрерывно обновляемый обзор, который связывает данные об уязвимостях, сведения о программном обеспечении, подверженность активов, право собственности, прогресс устранения и подтверждающие доказательства. Без этого риск-ориентированная политика — это просто упражнение с таблицами. С этим политика превращается в реальную систему для принятия мер.
Та же логика должна распространяться вверх по цепочке на разработку программного обеспечения
BOD 26-04 фокусируется на обновлениях безопасности для уже используемых технологий, но основной принцип, лежащий в ее основе, должен применяться ко всему жизненному циклу программного обеспечения.
У каждой уязвимости в промышленной эксплуатации есть своя предыстория. Она может возникнуть в пользовательском коде, сторонней зависимости с открытым исходным кодом, образе контейнера или инфраструктуре как коде (IaC). К тому времени, когда уязвимость достигает общедоступной системы и начинается трехдневный отсчет, агентства сталкиваются с проблемой на самом дорогом и критичном по времени этапе.
Безопасность федерального программного обеспечения не может ждать до этапа эксплуатации, чтобы собрать контекст, необходимый для оценки и управления рисками. Агентствам нужен этот контекст от разработки до развертывания, чтобы они могли избежать ненужной подверженности рискам, быстро реагировать при изменении рисков и демонстрировать, как они управляют этими рисками.
Это требует трех сдвигов:
- Видеть полную картину подверженности программного обеспечения
Инвентаризация активов важна, но этого недостаточно. Агентствам также необходимо связать приложения, репозитории, компоненты с открытым исходным кодом, зависимости, образы контейнеров и инфраструктуру с системами и функциональными задачами, которые они поддерживают.
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, безопасность инфраструктуры как кода (IaC), безопасность контейнеров, обнаружение вредоносных пакетов и ASPM в платформе, сертифицированной по стандарту FedRAMP, обеспечивая единообразную безопасность как для ведомственной, так и для подрядной разработки.
С помощью Checkmarx One for Government (CxG) федеральные команды могут:
- Связывать результаты анализа программного обеспечения в коде, зависимостях с открытым исходным кодом, инфраструктуре, контейнерах и облачных средах.
- Идентифицировать и приоритизировать значимые риски на более ранних этапах жизненного цикла разработки.
- Применять единообразные политики для различных программ, команд разработчиков и подрядчиков.
- Сохранять прослеживаемость и доказательства, необходимые для надзора, авторизации и непрерывного мониторинга.
- Сокращать количество фрагментированных процессов передачи задач, которые отнимают время, когда риск становится критическим.
Настоящая ценность заключается в упрощении связи между подверженностью программного обеспечения угрозам и ответственными действиями.
Будущее за доказательным подходом
BOD 26-04 устанавливает риск-ориентированный подход к устранению уязвимостей в агентствах Федеральной гражданской исполнительной власти. Но это нечто большее, чем просто новый набор сроков. Это сигнализирует о более широком операционном сдвиге в федеральном гражданском секторе: от подсчета найденных уязвимостей к пониманию последствий, от статической оценки серьезности к текущему контексту и от выполненных задач к верифицированному снижению рисков.
Соответствие этому стандарту требует большего, чем просто добавление еще одной очереди на устранение. Ведомствам нужна операционная модель, которая объединяет данные о программном обеспечении, активах, угрозах, ответственности и политиках достаточно быстро, чтобы поддерживать принятие решений по миссии. Уровень серьезности говорит ведомствам, что может сделать уязвимость; контекст говорит им, угрожает ли она на самом деле миссии.
Ведомства, которые лучше всего подготовлены к выполнению директивы, — это те, которые смогут превратить этот контекст в своевременные, обоснованные действия и предоставить доказательства своих решений. Это то, что в конечном итоге должно обеспечить риск-ориентированное управление уязвимостями: не просто меньше открытых проблем, а более четкое, доказуемое снижение рисков для миссии.
Теги:
Агентный ИИ
Агентная безопасность приложений
ИИ-агенты
Управление ИИ
Федеральное правительство