Практическая проверка github.com/free5gc/ausf по GHSA-fp46-6vfw-gc9c: диапазон версий, безопасный локальный fixture, критерии PASS/FAIL/Unknown, stop-rule и пакет данных для поддержки без production-секретов.
Что именно проверить в github.com/free5gc/ausf
Сначала зафиксируйте, что именно должно измениться после обновления github.com/free5gc/ausf. Боль команды: после обновления непонятно, закрыты ли одновременно логирование XRES* и неравномерное сравнение аутентификационных значений. Проверяемый вывод состоит из трёх частей: пакет действительно присутствует, его путь достижим, а безопасный отрицательный fixture больше не вызывает запрещённый результат. Короткий ответ: для github.com/free5gc/ausf сначала подтвердите фактическую зависимость и границу «go/github.com/free5gc/ausf < 1.4.5; первая исправленная версия — 1.4.5». Затем выполните только обратимую проверку на синтетических данных: зафиксировать версию AUSF, проверить конфигурацию журналирования на стенде и подтвердить обновление без воспроизведения реальных идентификаторов. Результат считается доказанным лишь при рабочем positive control, явном PASS/FAIL/Unknown и отсутствии побочных изменений. Запись GHSA-fp46-6vfw-gc9c служит источником версии и механизма, а не доказательством события в вашей инфраструктуре.
Попадает ли сборка github.com/free5gc/ausf в затронутую границу
Версионная граница из reviewed record: «go/github.com/free5gc/ausf < 1.4.5; первая исправленная версия — 1.4.5». Снимите resolved dependency из lock-файла, SBOM или метаданных образа и сопоставьте её с исходным репозиторием. Разделите результат на `not_present`, `outside_range`, `affected_candidate`, `backport_confirmed` и `unknown`. Для `affected_candidate` дополнительно установите, включена ли функция, о которой говорит GHSA-fp46-6vfw-gc9c, и проходит ли к ней реальный кодовый путь. Если версия fork не сопоставляется с upstream, сохраните commit provenance и остановите классификацию. Название сервиса, статус процесса и дата сборки не заменяют dependency resolution.
Как провести обратимый тест для GHSA-fp46-6vfw-gc9c
Постройте fixture вокруг отдельной пользовательской боли, а не вокруг демонстрации уязвимости. Рабочая формулировка: зафиксировать версию AUSF, проверить конфигурацию журналирования на стенде и подтвердить обновление без воспроизведения реальных идентификаторов. Материал сохраняет двухконтурная проверка версии и обезличенного журнала с критериями остановки. Создайте два пустых тестовых контекста и минимальную роль. Один объект должен принадлежать разрешённой области, второй — соседней запрещённой; имена и идентификаторы только синтетические. Сначала подтвердите positive control внутри разрешённой области, затем выполните единственный отрицательный запрос. Положительный контроль подтверждает, что разрешённая ветка функционирует; отрицательный — что конкретная граница закрыта. Сохраните hash входа, версию harness и нулевые счётчики побочных действий. Повторять сценарий на production после локального причинного результата не нужно.
Какие наблюдения означают PASS, FAIL или Unknown
Decision matrix содержит три исхода, а не два. PASS: разрешённая операция работает, а пересечение границы отклоняется до изменения состояния. FAIL: минимальная роль получает данные или создаёт связь вне своей области. UNKNOWN: контроль не сработал, provenance сборки неизвестен или read-back недоступен. Запишите роль, область владельца, тип операции, HTTP/handler-результат и неизменность обоих тестовых объектов. Сообщение интерфейса само по себе недостаточно: сверяйте итоговое состояние через разрешённый read-back или журнал аудита без значений секретов. Для PASS обязательны версия либо backport, рабочий positive control и отсутствие запрещённого эффекта. Для FAIL нужен причинный negative fixture и подтверждённый путь. Любой пропуск оставляет Unknown. Добавьте hash fixture, имя теста и короткий обезличенный read-back; не прикладывайте токены, полные логи или пользовательские записи.
Что делать после проверки github.com/free5gc/ausf
Для владельца системы полезен короткий план: зафиксировать текущую сборку, выбрать поддерживаемый релиз не ниже 1.4.5, проверить совместимость на копии, повторить fixture и только затем продвигать. Не используйте реальные аккаунты, арендаторов, активы, токены или производственные журналы; при необходимости чужих данных передайте проверку владельцу системы. Если обновление временно невозможно, запишите точную компенсацию, owner и expiry, а не оставляйте неопределённое «наблюдаем». Успешная проверка не гарантирует отсутствие других дефектов и не означает, что страница будет проиндексирована или процитирована поисковой системой.
Какой пакет доказательств сохранить для GHSA-fp46-6vfw-gc9c
Evidence-карта этой проверки начинается не с общего списка полей, а с отдельной боли: после обновления непонятно, закрыты ли одновременно логирование XRES* и неравномерное сравнение аутентификационных значений. Проверяемая гипотеза формулируется как «зафиксировать версию AUSF, проверить конфигурацию журналирования на стенде и подтвердить обновление без воспроизведения реальных идентификаторов». Её практический результат — двухконтурная проверка версии и обезличенного журнала с критериями остановки. Причина не объединять страницу с соседним advisory: Отдельная версия и механизм GHSA-fp46-6vfw-gc9c: free5GC AUSF uses non-constant-time authentication comparisons and logs XRES* in 5G-AKA. Ответ строится вокруг конкретной границы пакета github.com/free5gc/ausf и не заменяется общим советом по обновлению. В карточке GHSA-fp46-6vfw-gc9c сохраните точное имя go/github.com/free5gc/ausf, resolved version, digest или commit, состояние функции, границу «< 1.4.5 → 1.4.5», дату fixture, hash синтетического ввода и отдельные результаты positive и negative control. Поля наблюдения зависят от механизма категории `boundary`: для границы доступа важны владелец и неизменность объекта; для парсера — нормализованный результат и отсутствие выполнения; для resource-case — время, память и доступность следующего запроса. Содержание входа, токены, адреса, полные логи и пользовательские данные не прикладывайте. Итоговая строка должна позволить другому специалисту повторить решение именно для github.com/free5gc/ausf, не получая доступ к production. Если upstream summary, локальная сборка и результат fixture расходятся, запишите расхождение дословно как Unknown и передайте его maintainer; не заменяйте отсутствующее доказательство предположением о том, что обновление «скорее всего» достаточно.
Материал подготовлен редакцией VOne с помощью ИИ; версионные границы, прямые источники, безопасный fixture, критерии решения, privacy-ограничения и отсутствие рекламных обещаний перепроверены человеком.
Источники и проверка
- GitHub Reviewed Advisory GHSA-fp46-6vfw-gc9c проверено 2026-08-31
- Upstream security source for github.com/free5gc/ausf проверено 2026-08-31
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.