Проблема после аудита в том, что команда часто получает не ответ, а очередь из разнородных пунктов: где-то есть версия зависимости, где-то вопрос к авторизации, где-то неполная карта загрузки файла. Самый громкий заголовок или высокий score легко забирает весь фокус. Цена — исправить то, что удобно показать в статусе, и оставить без владельца публичную boundary с неполным evidence. Вторая цена не менее реальна: поспешная «security-правка» ломает рабочий путь, а rollback никто не продумал, потому что triage уже назвал её очевидной.
Причина в том, что severity читают как готовый порядок действий. CVSS v3.1 полезен для описания технических характеристик и прямо допускает Base, Temporal и Environmental groups. Но сама спецификация говорит, что организация учитывает и другие факторы при remediation decision. Score не знает, есть ли разрешённое воспроизведение, кому принадлежит boundary, насколько широко она используется, что изменится при фиксе и можно ли вернуть состояние. Поэтому безопасный triage строится не вокруг одной цифры, а вокруг цепочки evidence → owner → reversible decision → проверка результата.
Сначала отделяем гипотезу от решения
Пусть есть карточка «authz boundary требует review». Она не означает, что в системе найдена vulnerability; это вопрос, который получил высокий порядок потому, что относится к public entry и не имеет полного evidence. Следующая карточка про third-party identity contract может оказаться важнее зависимости с высоким Base score, если у неё нет согласованного owner и scope. Это не спор с CVSS. Это признание границ метода: он описывает свойства уязвимости, а не контекст конкретного изменения и не право действовать с чужими системами.
Для каждого пункта нужны четыре развилки. Первая — evidence: есть ли достаточно материала для утверждения или пока только gap. Вторая — exposure: где находится boundary относительно пользовательского пути и внешней зависимости. Третья — owner: кто может подтвердить контракт и принять решение. Четвёртая — reversibility: какой шаг можно отменить, если гипотеза не подтвердится. Пока хотя бы одна развилка неизвестна, правильное действие — не автоматическая правка, а уточнение. Это быстрее, чем создать новый риск из хорошего намерения.
| Поле | Вопрос | Если ответа нет | Безопасный следующий шаг |
|---|---|---|---|
| Evidence | что подтверждено и с каким ограничением? | severity опирается на гипотезу | перевести в evidence gap и запросить разрешённое подтверждение |
| Exposure | какая boundary и пользовательский путь затронуты? | не виден возможный blast radius | связать пункт с asset map и ценным сценарием |
| Owner | кто подтверждает контракт и change? | исправление становится бесхозным | назначить владельца до изменения |
| Reversibility | что вернём и как проверим? | rollback звучит как обещание | написать validation и rollback plan |
| Decision | почему именно этот пункт идёт первым? | очередь строится по громкости | зафиксировать evidence-based rationale, а не только score |
Порядок — это объяснение, а не сортировка по колонке
Хороший порядок можно пересказать одним предложением. Например: «сначала подтверждаем evidence и владельца на public authz boundary, затем согласуем scope с identity provider, затем пишем validation и rollback для upload delivery». В такой формулировке видно, что пункт №1 не объявлен найденной уязвимостью и не отправлен на автоматический fix. Его подняли потому, что незакрытый вопрос касается ценного входа и есть обратимый шаг — получить доказательство и договориться о change. Если причина порядка не помещается в одно предложение, значит, в очереди смешались разные классы работы.
Нельзя скрывать decision в шкале «critical/high/medium». Эти labels полезны для сводки, но не отвечают на «кто сделает что утром». К моменту изменения нужны owner, exact boundary, критерий валидации, отказоустойчивый план остановки и правило возврата. Если операция требует неотменяемой миграции, влияния на совместимость или доступа к third-party, её нельзя выдавать за «быстрый security fix». Пункт должен перейти в отдельный review, даже если проблема кажется знакомой.
Fixture моделирует только безопасные gates
В учебной модели три synthetic triage cards уже имеют порядок, но не получают право менять систему. Первая карта требует подтвердить evidence и owner до change. Вторая требует согласовать scope третьей стороны. Третья требует сначала написать validation и rollback plan. Любая подмена на synthetic-automatic-change отвергается. Тест также отказывается принимать claimed permission, externally confirmed evidence, лишние asset fields и raw secret. Это не защита реального проекта; это защита примера от ложного смысла.
node web/scripts/upgrade-2023-12.mjs --verify-fixtureПосле запуска можно увидеть только PASS набора assert-выражений. Никакого score не вычисляется, CVSS vector не создаётся, URL не открывается, сеть не используется, код и логи не читаются. Fixture не запускает scanner, brute force или browser и не заявляет vulnerability, coverage, compliance либо production effect. В этом его ценность: модель показывает, что triage начинается с запрета на действие без evidence и owner, а не с имитации риск-оценки без системы.
Исправление должно быть проверяемым и обратимым
Техническое решение можно назвать только после того, как сформулирован критерий проверки. «Добавим проверку доступа» ещё не план: нужно знать, на какой boundary, для какого действия пользователя, кто проверит ожидаемый и запрещённый исход, где записан результат и как вернуть предыдущую версию. Здесь автор продолжает линию статей о контрактных тестах и e2e stability: хороший gate не обещает, что баг исчез. Он фиксирует, какой наблюдаемый результат отличит рабочее изменение от неверной гипотезы.
Rollback не обязан быть сложным, но обязан быть реальным для выбранного изменения. Для конфигурации это может быть версия правила и явный owner восстановления. Для UI-flow — возврат к известной реализации и ограничение exposure. Для third-party contract — прекращение rollout до согласования. Нельзя писать «откатим базу» или «выключим интеграцию» без оценки последствий для данных и пользователей. Если безопасного обратного действия нет, triage должен повысить требование к review, а не ускорить выпуск из-за тревожного названия.
Маршрут: симптом → причина → проверка → действие
- Симптом. Backlog полон security-пунктов, но первые места заняты самым громким score или последним сообщением в чате.
- Причина. Severity подменила evidence, scope, owner и reversibility; очередь стала списком тревог, а не планом изменения.
- Проверка evidence. Для каждого пункта зафиксируйте literal claim, источник, status, границу, ограничение и то, что не подтверждено. При gap не называйте карточку finding.
- Проверка change. Назовите owner, пользовательский путь, expected result, запрещённый результат, валидацию, stop condition и rollback. Если одного элемента нет, решение ещё не готово.
- Действие. Поставьте первым не «самый страшный» пункт, а тот, для которого есть понятный evidence-based question и безопасный следующий gate. Неавторизованные или необратимые действия вынесите из очереди исправлений.
- Повтор. После подтверждения или изменения обновите evidence и rationale. Если причина порядка изменилась, пересортируйте очередь открыто, а не оставляйте старый номер по инерции.
Ограничения и следующий шаг
Эта статья не даёт универсальный SLA, пороги severity, срок исправления или готовый порядок для всех команд. CVSS v3.1 — исторически доступный стандарт к декабрю 2023, но он не определяет business impact, permission, owner или rollback конкретного продукта. NIST, OWASP и RFC дают язык для планирования, границ и верификации; они не выводят автоматически, что надо менять в данном коде. Любая реальная проверка требует согласованного scope и допустимого метода вне этого fixture.
Следующий шаг — выбрать одну карточку из backlog и провести пятнадцатиминутный triage без обсуждения реализации. Запишите: claim, evidence status, asset boundary, owner, exposure, reversible next step, validation, stop condition и rollback. Только после этого решайте, нужна ли разработка, review контракта, запрос к подрядчику или дополнительное доказательство. Такая карточка короче типичного отчёта, но даёт команде возможность действовать без вымышленных гарантий.
Историческая граница декабря 2023
Для порядка исправлений использована версия CVSS 3.1 от июня 2019 года, доступная до декабря 2023, вместе с NIST SP 800-115, OWASP WSTG v4.2, ASVS 4.0.3 и RFC 9116. CVSS здесь назван входом в decision, а не автоматической командой. Учебные числа, findings, exploitation, coverage, compliance и production-результаты не создаются и не заявляются.
Проверяемые источники
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment, сентябрь 2008 — Первичный документ NIST о планировании, проведении, анализе и mitigation технических проверок. Это обзор 2008 года: он не заменяет актуальный договор об авторизации, не задаёт scope конкретного веб-проекта и не подтверждает результаты этого учебного fixture.
- OWASP Web Security Testing Guide v4.2, 3 декабря 2020 — Версионированный официальный guide описывает testing framework, mapping архитектуры и WSTG identifiers. Он не даёт права выполнять тест, не является перечнем всех активов и не доказывает coverage или finding в чужой системе.
- OWASP Application Security Verification Standard 4.0.3, 28 октября 2021 — Официальный ASVS задаёт требования к верификации приложения. Версия 4.0.3 существовала к концу 2023 года, но стандарт не выдает сертификат, не подменяет evidence и не делает учебную запись compliance-результатом.
- RFC 9116: security.txt, апрель 2022 — Информационный RFC описывает канал disclosure и прямо оговаривает отсутствие подразумеваемого разрешения на testing. security.txt относится к домену или IP, из которого он получен; сам по себе он не расширяет scope и не создаёт authorization.
- FIRST: Common Vulnerability Scoring System v3.1, июнь 2019 — Первичная спецификация различает Base, Temporal и Environmental metrics и называет CVSS входом для management process. Она не учитывает автоматически владельца, обратимость изменения, доказательство, разрешённые границы или бизнес-контекст конкретной команды.