Summary

  • В докладе GAO-26-107530 должностные лица 17 из 24 федеральных ведомств сообщили, что разница между указаниями OMB и NIST затрудняет сбор и хранение перечней компонентов ПО, или SBOM. Это оценка закупочной практики ведомствами, а не статистика инцидентов.
  • Прежний меморандум OMB M-22-18 относил сбор SBOM к возможным действиям и представлял перечень как статический документ; NIST связывал сведения о компонентах каждого выпуска с анализом уязвимостей. В январе 2026 года OMB отменило M-22-18: действующий M-26-05 допускает требование актуальной SBOM по контракту и возлагает ответственность на руководство ведомства.
  • GAO рекомендовала выпустить через CISA практические указания по созданию, получению и анализу этих данных при закупках, разработке и управлении риском. Проверять следует путь от версии работающего продукта до ответственного за решение, а не число полученных файлов.

Папка закрывается раньше, чем появляется уязвимость

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

Доклад GAO от 23 июня 2026 года показывает, как федеральные правила развели эти задания. Из 24 ведомств, где аудиторы опросили руководителей ИТ и закупок, 17 сообщили о трудностях из-за противоречия между инструкциями OMB и NIST по сбору и хранению SBOM. В другом разделе доклада также фигурируют 17 ведомств, столкнувшихся с управлением стоимостью облака. Это две разные группы ответов на разные вопросы; одинаковая цифра не превращает расходы в проблему SBOM.

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

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

Январский меморандум передал выбор вниз

M-26-05 от 23 января 2026 года отменил M-22-18 и M-23-16. Ссылаться на M-22-18 как на действующее правило теперь нельзя. Новый текст сохраняет требование полных инвентарных списков программ и оборудования, подход с учётом риска и ответственность руководителя ведомства. Он разрешает ведомству включить в контракт обязанность предоставить актуальную SBOM по запросу; для облачной услуги условие должно охватывать рабочую производственную среду.

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

Материалы NIST о цепочке поставок ПО описывают ценность компонентных данных для безопасности. Совместный документ CISA, опубликованный в сентябре 2025 года, призывает создавать, принимать и анализировать SBOM внутри существующих процессов управления риском. GAO установила, что в этом видении не хватает конкретных указаний, как ведомству связать данные с инструментами и рабочим процессом. Принцип задаёт направление; контракт и служба эксплуатации нуждаются в адресе передачи.

Следующий документ должен описать передачу

GAO рекомендовала Министерству внутренней безопасности поручить CISA выпустить дополнительные указания по созданию, использованию и анализу SBOM при закупках, разработке и управлении риском. Министерство согласилось и в ответе назвало 30 сентября 2026 года ожидаемым сроком. Само обещание не является опубликованной инструкцией. На момент проверки для этой статьи открытая карточка рекомендации GAO сохраняла статус Open.

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

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

Sources