Федеральный покупатель запросил аттестацию программного обеспечения. К какому выпуску он относится?
Присоединяйтесь к федеральному запросу, аттестации CISA, версии продукта и свидетельству о выпуске, прежде чем приступать к работе по обеспечению безопасности программного обеспечения.
Сигналы для наблюдения
- Федеральный покупатель или генеральный подрядчик называет программный продукт и запрашивает текущую аттестацию безопасного программного обеспечения CISA перед выпуском или награждением.
- У производителя есть корпоративная политика безопасной разработки, но он не может сопоставить область аттестации с конкретным поставляемым продуктом и версией.
- Агентство отдельно запрашивает SBOM, оценку или другой артефакт, и в отчете о продажах это неправильно рассматривается как часть формы подтверждения.
Федеральный запрос на аттестацию безопасного программного обеспечения является применимым только в том случае, если его можно присоединить к одно запрашивающее агентство, один производитель, один продукт или линия продуктов и доставляемый выпуск. Корпоративная политика безопасной разработки, спецификация программного обеспечения (SBOM) или старая форма для другого продукта — это не то, что нужно. В августе 2026 года действующая политика агентства по обеспечению качества и формулировка контракта также будут иметь значение: CISA говорит, что агентства могут использовать общую форму, а не представлять ее как автоматическое требование для каждой покупки.
Этот ответ важен руководителю по развитию бизнеса поставщика услуг обеспечения безопасности цепочки поставок ПО, который отслеживает авторизованные Telegram-группы федеральных подрядчиков, поставщиков ПО и специалистов по безопасности. Полезный Signal — не просто сообщение «нужна федеральная аттестация». В нем названы продукт, покупатель или генеральный подрядчик, неясная граница версии и датированное событие выпуска, предложения или приемки. Если увидеть его только завтра, можно пропустить встречу, на которой инженеры, юристы и уполномоченный представитель производителя определят охват заявления.
Форма представляет собой заявление о практике разработки, а не сертификат выпуска.
В CISA Страница формы аттестации разработки безопасного программного обеспечения указано, что форма основана на специальной публикации 800-218 Национального института стандартов и технологий, платформе безопасной разработки программного обеспечения (SSDF) версии 1.1. общая форма позволяет производителю идентифицировать охватываемое программное обеспечение и подтвердить соблюдение перечисленных методов безопасной разработки или определить методы, которые он не может подтвердить.
Форма не подтверждает отсутствие уязвимостей в выпуске. Это не превращает CISA в оценщика продукта. Он также не содержит всех артефактов, которые может запросить агентство. Заявление, объем продукта и любые подтверждающие доказательства должны оставаться отдельными объектами в записи о продажах.
История политики объясняет, почему старые сообщения могут вводить в заблуждение. OMB М-22-18, выпущенный 14 сентября 2022 года, предписывает агентствам получить самоаттестацию для указанного программного обеспечения и обосновывает эту работу практиками безопасной разработки NIST. М-23-16, выпущенный 9 июня 2023 г., обновил график реализации и процесс общей формы. Текущая страница CISA теперь указывает на OMB M-26-05: агентства должны вести инвентаризацию программного и аппаратного обеспечения и устанавливать политики обеспечения безопасности, соответствующие риску и миссии; они может используют ресурсы, созданные в соответствии с M-22-18, включая форму, и могут заключить контракт на текущий SBOM.
Практическое правило продаж простое: датируйте запрос. В памятке 2023 года объясняется происхождение формы. Текущая политика агентства, предложения, положения контракта или инструкции по приемке определяют, что покупатель просит в данный момент.
Создание соединения аттестации к выпуску
Используйте одну короткую запись с шестью полями. Он меньше, чем контрольный список оценки, поскольку его цель — определить коммерческую задачу, а не выполнить проверку качества.
- Запрашивающий: агентство, подрядная организация или генеральный подрядчик, а также источник запроса.
- Продюсер: юридическое лицо, ответственное за программное обеспечение, а не просто реселлер, отправляющий файл.
- Охватываемое программное обеспечение: Продукт или линейка продуктов, как указано в форме.
- Релиз: точную версию, сборку, образ поставки или семейство выпусков, которые получит покупатель.
- Заявление: формирует дату, удостоверяющую личность и практику, которую подтверждает или не подтверждает производитель.
- Отдельные артефакты: SBOM, отчет об уязвимостях, оценка третьей стороны, план действий или другой элемент, явно запрошенный вне формы.
Четвертое поле является оригинальным вкладом этой статьи. Общая форма может охватывать продукт или линейку продуктов, тогда как закупки и проектирование работают с выпусками. Объединение этих слоев предотвращает присоединение допустимой формы к версии, которую она никогда не поддерживала.
Например, в политическом документе может быть указано, что компания проверяет исходный код и защищает среду сборки. Это полезный фон. Он не устанавливает, какой репозиторий, служба сборки, подписывающее удостоверение или ветвь выпуска создали приложение, доставленное в агентство. И наоборот, в SBOM для конкретной версии перечислены компоненты, но сам по себе не подтверждается, что производитель соблюдает все методы, указанные в форме.
Пример: три файла, все еще нет закрытого выпуска.
Рассмотрим это иллюстративный композит, а не сообщение клиента:
“Премьеру нужна аттестация CISA до пятничной обрезки изображения. У нас есть прошлогодняя форма и SBOM из версии 4.8. Юристы говорят, что политика не изменилась. Этого достаточно?”
Фрагмент содержит запрос генерального подрядчика, событие пятницы, предыдущую форму и SBOM для версии 4.8. Он не идентифицирует агентство, название продукта в старой форме, выпуск, запланированный на пятницу, подписывающего лица, использует ли текущий запрос общую форму или соответствует ли SBOM изображению доставки.
Не отвечайте да или нет от группы. Напишите соединение с пробелами:
Запрашивающий: назван главным, агентство не подтверждено; производитель: неподтвержденное юридическое лицо; покрываемое программное обеспечение в предыдущей форме: еще не прочитано; дата поставки: не подтверждена; дата выписки и подписывающее лицо: еще не проверены; отдельный артефакт: SBOM с пометкой 4.8, связь с пятничным изображением неизвестна.
Теперь маршрут обслуживания становится видимым. Если старая форма охватывает ту же линейку продуктов, но владелец свидетельства не может связать ее с новой версией, работа может заключаться в сопоставлении свидетельств выпуска. Если производитель не может сделать одно из утверждений, общая форма включает способ выявления этого пробела, а не его сокрытия. Если единственным недостающим элементом является запрошенный агентством SBOM для окончательного образа, направьте запрос на производство или проверку инвентаризации компонентов, а не на «обновление сертификата».
Запросите доказательства, не собирая секреты в публичной группе
Для первого разговора необходим текст запроса, область действия формы и идентификатор выпуска. Ему не нужен исходный код, учетные данные, сведения об уязвимостях или личные записи федерального клиента в Telegram. Переместите разрешенные доказательства в авторизованный канал покупателя и запишите, кто может их проверять.
Полезные последующие вопросы конкретны:
- Какое ведомство или генеральный подрядчик направили запрос и где опубликована действующая инструкция?
- Какое название производителя и продукт или линейка продуктов указаны в предлагаемой форме?
- Какая версия или образ поставки принимается и когда будет принято решение?
- Кто уполномочен заверять производителя?
- Какие утверждения требуют подтверждающей проверки, а какие в настоящее время сделать невозможно?
- Требуется ли по контракту SBOM или оценка отдельно и для какой версии?
Если проблема заключается в доказательствах контроля филиала, а не в федеральной форме, используйте запись доказательств риска поставщика для защиты филиалов. Для решения смежной задачи проверки того, какие зависимости вошли в выпуск, используйте Запись свидетельства о риске поставщика в файле блокировки зависимостей.
TOP Prospect может фильтровать и объединять неполные фрагменты из групп Telegram, которые пользователь намеренно подключает и имеет право доступа. Он может сохранить источник и время, удалить очевидные дубликаты и объяснить, почему название продукта «форма CISA» и пятничный выпуск появились вместе. Он не может читать частные репозитории, определять политику агентства, подписывать аттестацию, проверять практику SSDF, связываться с участниками или обещать принятие. Цены и варианты доступа описывает уровень обнаружения, а не заключение по обеспечению качества.
Ключевые факты
- CISA сообщает, что общая форма основана на NIST SP 800-218, SSDF версии 1.1.
- Общая форма идентифицирует производителя, обслуживаемое программное обеспечение или линейку продуктов и подтверждающее лицо.
- В сентябре 2022 года на М-22-18 создано федеральное направление самоаттестации; Обновленная реализация М-23-16 в июне 2023 года.
- На странице CISA, доступ к которой осуществлен 14 августа 2026 г., говорится, что агентства могут использовать форму в соответствии со своими политиками обеспечения безопасности, основанными на рисках, и могут отдельно запросить действующую версию SBOM.
- SBOM — это перечень компонентов; это не сертификат безопасной разработки производителя.
- Объединение выпусков — объем продукта плюс точная версия или образ поставки — должно быть проверено, а не выведено из предположения.
FAQ
Является ли форма аттестации безопасного программного обеспечения CISA обязательной для каждой федеральной покупки программного обеспечения?
В августе 2026 года ни одна универсальная претензия не является безопасной. CISA теперь гласит, что OMB M-26-05 требует от агентств вести инвентарные запасы и применять политику обеспечения безопасности, основанную на рисках; агентства могут выбирать общегосударственные ресурсы, созданные в соответствии с M-22-18, включая форму, и могут устанавливать контрактные требования. Проверьте запрашивающее агентство и контракт.
Что должна выявить аттестация?
Общая форма идентифицирует производителя программного обеспечения, соответствующее программное обеспечение или линейку продуктов и аттестующее лицо. Полезная запись о продажах должна включать точный выпуск или версию, запрашивающее агентство, доставку и владельца доказательств, подтверждающих это заявление.
Является ли SBOM тем же, что и аттестация безопасного программного обеспечения?
Нет. SBOM — это перечень компонентов. Аттестация представляет собой заявление производителя о методах безопасной разработки. Агентство может запросить оба, но одно не заменяет другое.
Может ли реселлер подписать контракт с производителем программного обеспечения?
Не делайте выводов об этом из канала продаж. Форма касается производителя программного обеспечения и уполномоченного аттестующего лица. Проверьте производителя, продукт, на который распространяется действие соглашения, и полномочия подписывающего лица для фактической отправки.
Коммерческая передача считается завершенной, когда команда может указать на текущий запрос покупателя, заявление производителя и точный релиз в одной строке, не притворяясь, что один файл подтверждает два других.
Часто задаваемые вопросы
Является ли форма аттестации безопасного программного обеспечения CISA обязательной для каждой федеральной покупки программного обеспечения?
В августе 2026 года ни одна универсальная претензия не является безопасной. CISA теперь гласит, что OMB M-26-05 требует, чтобы агентства вели инвентарные запасы и придерживались политики обеспечения безопасности, основанной на рисках; агентства могут выбирать общегосударственные ресурсы, созданные в соответствии с M-22-18, включая форму, и могут устанавливать контрактные требования. Необходимо проверить запрашивающее агентство и контракт.
Что должна выявить аттестация?
Общая форма идентифицирует производителя программного обеспечения, соответствующее программное обеспечение или линейку продуктов и аттестующее лицо. Полезная запись о продажах должна включать точный выпуск или версию, запрашивающее агентство, доставку и владельца доказательств, подтверждающих это заявление.
Является ли SBOM тем же, что и аттестация безопасного программного обеспечения?
Нет. Спецификация программного обеспечения представляет собой перечень компонентов. Аттестация представляет собой заявление производителя о методах безопасной разработки. Агентство может запросить оба, но одно не заменяет другое.
Может ли реселлер подписать контракт с производителем программного обеспечения?
Не делайте выводов об этом из канала продаж. Форма касается производителя программного обеспечения и уполномоченного аттестующего лица. Производитель, продукт, на который распространяется действие Соглашения, и полномочия подписывающей стороны должны быть проверены на предмет фактической отправки.
Источники и дополнительное чтение
- CISA, Форма аттестации разработки безопасного программного обеспечения и текущая политика, по состоянию на 14 августа 2026 г.
- CISA, Общая форма аттестации разработки безопасного программного обеспечения, апрель 2024 г.
- OMB Меморандум M-22-18, Повышение безопасности цепочки поставок программного обеспечения с помощью методов безопасной разработки программного обеспечения, 14 сентября 2022 г.
- OMB Меморандум M-23-16, обновление до M-22-18, 9 июня 2023 г.
Как обнаруживается Signal, заслуживающий внимания
Методика показывает, как Top Prospect находит и упорядочивает Signals, которые стоит проверить, сохраняет исходный контекст Telegram, удаляет дубли и помогает определить порядок просмотра. Решение о дальнейших действиях остаётся за вами.
