Защитная диагностика Steeltoe Configuration Encryption по GHSA-4j9m-h44m-2hv8: version inventory, обратимый fixture, PASS/FAIL/Unknown, stop-rule и минимальный пакет доказательств без production-данных.
Что именно проверяет карточка Steeltoe Configuration Encryption
Здесь не проводится общий аудит продукта и не пересказывается чужая публикация. Проверяется одна граница: настройка OAEP могла приводить к шифрованию PKCS#1 v1.5 и создавать ложное представление о режиме. Advisory GHSA-4j9m-h44m-2hv8 задаёт проверяемый inventory-контекст «Steeltoe.Configuration.Encryption: >= 4.0.0, <= 4.1.0; первая исправленная версия: 4.2.0». Само совпадение версии означает только affected_candidate. Оно не подтверждает достижимость пути, наличие инцидента или ущерба. Для not_present нужен runtime/SBOM, для outside_range — resolved dependency, для patched_or_backported — release либо commit и повторяемый regression result. Если связать работающий artifact с revision нельзя, честный ответ — Unknown. Уникальная модель наблюдения для этой карточки связывает гарантию «выбранный padding должен совпадать с фактической криптографической операцией, а старые ciphertext мигрироваться отдельно» с действием «одноразовая пара тестовых ключей шифрует маркер в каждом режиме; результат проверяется независимым decrypt и затем выполняется пробная миграция копии». Она считается полной только вместе с колонками «configured mode | detected padding | decrypt path | migrated copy | verdict» и отдельным аварийным условием «использован production key, исходный ciphertext перезаписан или режим не определяется однозначно». Эти пять элементов образуют самостоятельную проверку именно Steeltoe Configuration Encryption, а не заменяемый шаблон для соседнего продукта.
Дерево решения по версии и функции Steeltoe Configuration Encryption
Соберите package manager, lock-файл, digest образа или бинарника, feature flag и фактическую точку вызова. Сначала установите, присутствует ли Steeltoe.Configuration.Encryption в runtime, а не только в исходном manifest. Затем сравните доказанную версию с границей «Steeltoe.Configuration.Encryption: >= 4.0.0, <= 4.1.0; первая исправленная версия: 4.2.0». Ветка not_present завершает проверку без запуска fixture; outside_range требует сохранённого вывода inventory; affected_candidate переходит к изолированному тесту; patched_or_backported требует ссылки на исправление и его test evidence. Не подменяйте эти состояния одним HTTP 200, названием контейнера, датой сборки или отсутствием жалоб.
Обратимый fixture для механизма GHSA-4j9m-h44m-2hv8
Целевая гарантия сформулирована так: выбранный padding должен совпадать с фактической криптографической операцией, а старые ciphertext мигрироваться отдельно. Проверка: одноразовая пара тестовых ключей шифрует маркер в каждом режиме; результат проверяется независимым decrypt и затем выполняется пробная миграция копии. Среда должна быть одноразовой, без production snapshot, персональных данных, токенов и открытого исходящего доступа. До boundary-case выполните benign control, чтобы доказать достижимость нужной ветки. Заранее установите таймаут, лимит CPU/RSS, разрешённое дерево temp и сетевой allowlist loopback. После каждого шага прочитайте состояние обратно и удалите созданные объекты. Не используйте опубликованные exploit payload или реальные идентификаторы.
Как заполнить таблицу «configured mode | detected padding | decrypt path | migrated copy | verdict»
Записывайте по одной строке на benign control и boundary-case: configured mode | detected padding | decrypt path | migrated copy | verdict. PASS означает, что control дошёл до нужной функции, граничный случай был управляемо отклонён, состояние и side effects не изменились. FAIL допустим только при работающем control и наблюдаемом нарушении заявленной гарантии. Unknown обязателен при недоказанной версии, недостижимой ветке, неполной телеметрии, раннем срабатывании limiter или неоднозначном readback. Такая матрица отделяет наблюдение от догадки и позволяет другому инженеру повторить проверку без доступа к исходной среде.
Исправление и безопасная последовательность rollout
Если получен affected_candidate или воспроизводимый FAIL, следуйте remediation из upstream source; ориентир inventory: Steeltoe.Configuration.Encryption: >= 4.0.0, <= 4.1.0; первая исправленная версия: 4.2.0. Когда исправленная версия не названа или проект больше не поддерживается, не придумывайте patch: изолируйте функцию и спланируйте миграцию на поддерживаемую замену. Сначала сохраните lock/digest и fixture, затем измените только компонент, повторите benign и boundary cases, проверьте readback и лишь потом переходите к canary. Не смешивайте обновление с заменой proxy, прав, storage и формата данных: это разрушает причинность. Защитный фильтр может быть временной мерой, но не заменяет исправление. Stop-rule этого материала: использован production key, исходный ciphertext перезаписан или режим не определяется однозначно. При его срабатывании тест немедленно прекращается, артефакты изолируются, production не меняется.
Пакет доказательств для владельца Steeltoe Configuration Encryption
В handoff включите GHSA-4j9m-h44m-2hv8, границу «Steeltoe.Configuration.Encryption: >= 4.0.0, <= 4.1.0; первая исправленная версия: 4.2.0», artifact digest, source revision, feature state, hash fixture, лимиты, результаты control и boundary-case, одну строку из таблицы «configured mode | detected padding | decrypt path | migrated copy | verdict», итог PASS/FAIL/Unknown и точную причину Unknown. Добавьте ссылки на GitHub Advisory Database и upstream advisory/fix, но не копируйте длинные фрагменты. Отдельной строкой укажите, что проверялась боль «настройка OAEP могла приводить к шифрованию PKCS#1 v1.5 и создавать ложное представление о режиме», а не весь продукт. Уберите hostname, IP, usernames, cookies, tokens, конфиги и содержимое пользовательских объектов. Так evidence остаётся минимальным, проверяемым и пригодным для повторного решения. Для машиночитаемого журнала используйте независимые ключи `steeltoe-oaep-effective-padding-migration-check-inventory-proof`, `steeltoe-oaep-effective-padding-migration-check-benign-control`, `steeltoe-oaep-effective-padding-migration-check-boundary-observation`, `steeltoe-oaep-effective-padding-migration-check-state-readback`, `steeltoe-oaep-effective-padding-migration-check-sideeffect-diff`, `steeltoe-oaep-effective-padding-migration-check-stop-trigger`, `steeltoe-oaep-effective-padding-migration-check-final-verdict` и `steeltoe-oaep-effective-padding-migration-check-cleanup-proof`. Они не должны содержать значения секретов; это только имена полей, позволяющие не спутать доказательства этой проверки с соседними карточками.
Материал подготовлен редакцией VOne с помощью ИИ; даты, версии, первичные источники, обратимый fixture, stop-rule, privacy-ограничения и отсутствие рекламных обещаний перепроверены человеком.
Источники и проверка
- GitHub Advisory Database GHSA-4j9m-h44m-2hv8 проверено 2026-09-01
- Primary upstream source for Steeltoe Configuration Encryption проверено 2026-09-01
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.