Проблема обычно выглядит безобидно: в задаче написано «проверить веб-проект», а в руках команды только основной домен и длинный чек-лист. Через день один человек изучает форму входа, другой обсуждает CDN, а интеграция с identity provider вообще не попала в разговор. Цена такой экономии — не только пропущенный участок. Можно потратить время на второстепенный экран, принять чужую инфраструктуру за свою или затронуть внешний сервис, для которого команда не получила разрешения. До любого теста нужен не инструмент, а короткий scope: что считаем системой, где граница и кто подтверждает каждый участок.
Вторая ошибка — путать карту активов с перечнем URL. Адрес показывает точку входа, но не объясняет, где принимается решение об авторизации, кто владеет данными сессии, куда уходит загрузка файла и что считается внешней зависимостью. Для аудита это разные вопросы. Если ответ на них спрятан в голове одного разработчика, итоговый отчёт будет выглядеть аккуратно, но не позволит повторить проверку или безопасно выбрать первое исправление.
Scope начинается с действия пользователя и заканчивается владельцем
В декабре 2023 автор уже не сводит безопасность к одному сканеру. После тем о сессиях, CSRF и threat model естественный следующий шаг — увидеть путь пользователя как несколько границ. Для обычного веб-проекта это минимум browser UI, web API, identity boundary и delivery пользовательского файла. Это не универсальная архитектура и не список обязательных сервисов. Это способ задать первый вопрос: где конкретно меняется состояние и кто может объяснить контракт этого перехода.
Начинать полезно с одного ценного сценария: вход, смена адреса доставки, оплата или загрузка документа. Затем отмечаем активы, по которым проходит сценарий. Для каждого нужны шесть полей: понятный идентификатор, тип, граница, владелец, класс данных и вопрос аудита. Поле «вопрос» особенно полезно: оно не позволяет записать «проверить API» вместо проверяемого условия вроде «подтвердить границу авторизации между browser и API». Карта не говорит, что на границе есть ошибка. Она делает незнание видимым и назначает, у кого уточнить его до следующего действия.
| Поле | Пример учебной записи | Зачем нужно | Чего не доказывает |
|---|---|---|---|
| ID | synthetic-asset-web-api | связывает scope, evidence и triage без адреса реальной системы | что актив существует в production |
| Граница | browser → API | показывает момент смены ответственности | что запрос уже проверен на практике |
| Владелец | web owner | даёт адрес для уточнения контракта и плана изменения | что владелец разрешил любой тест |
| Класс данных | session metadata | помогает не смешать интерфейс, учетные данные и файл | что данные действительно хранятся или передаются |
| Вопрос | подтвердить authz boundary | делает следующий шаг наблюдаемым | что найдено нарушение |
Не подменяйте инвентаризацию разрешением
Самая опасная формулировка в стартовой задаче — «раз доступно из браузера, можно проверять». RFC 9116 описывает формат security.txt для disclosure, а не разрешение на действия. В его security considerations отдельно сказано, что файла недостаточно для подразумеваемого permission to test. Даже документ с contact и policy относится к домену или IP, из которого он получен; он не переносится автоматически на поддомены, подрядчика или соседний продукт. Поэтому рядом с scope нужна отдельная запись: кто утверждает границы, допустимый метод, среду, время и способ остановки. Пока этой записи нет, честный режим — inventory и review, а не активная проверка.
Это различие не бюрократическое. Scope отвечает «какой объект обсуждаем». Authorization отвечает «что разрешено делать с объектом». Evidence отвечает «на чём основан вывод». Когда три слоя смешаны в одной таблице, любая ссылка на документацию превращается в мнимое разрешение, а любой скриншот — в мнимое доказательство. Разделённые карточки делают разговор короче: сначала владелец подтверждает границу, потом команда фиксирует допустимый способ проверки, затем в отчёт попадают только воспроизводимые сведения.
Учебный fixture проверяет форму карты, а не проект
Ниже запускается маленькая модель этой статьи. В ней четыре заранее заданных объекта с префиксом synthetic-, одна запись declared boundary, четыре evidence cards и три triage cards. У входа нет поля URL, учётных данных, лога, исходного кода или произвольной цели. Любое лишнее поле, перестановка карты, попытка назвать permission granted или добавить raw secret отвергаются. Это полезно для редакторской проверки: короткий пример не должен незаметно стать сканером или источником ложного отчёта.
node web/scripts/upgrade-2023-12.mjs --verify-fixturePASS означает только одно: fixed in-memory contract собран, отрицательные ветки отклонены и rollback вернул учебный draft. Код не открывает browser, не читает репозиторий, не выполняет HTTP, не обращается к URL, не пробует пароль, не перебирает пути и не запускает security test. В нём нет реального актива, finding, coverage, compliance или permission. Такие явные ограничения важнее красивого примера: читатель видит, где заканчивается модель и начинается работа с владельцем системы.
Карта активов помогает ставить точный вопрос
Симптом часто маскируется под техническую деталь: форма авторизует пользователя, а после загрузки файла команда спорит, кто обязан проверять доступ к выдаче. Причина — на карте был отмечен upload, но не был отмечен переход от хранения к delivery. Проверка — не отправить специальный файл и не искать обход, а попросить владельца назвать контракт: кто принимает файл, где его имя становится серверным, кто выдаёт его пользователю, какие роли участвуют и где хранится evidence этого решения. Действие — добавить отсутствующую boundary card, владельца и отдельный plan проверки. После этого можно обсуждать метод, не расширяя scope наугад.
NIST SP 800-115 полезен именно этой последовательностью: планирование, проведение, анализ findings и mitigation не должны быть одним импульсом. Документ старше современного web stack, поэтому не стоит искать в нём готовую схему OAuth, CDN или SPA. Но его практический принцип остаётся применим: сначала назначить цель, ограничения и evidence, затем выбрать технику. OWASP WSTG v4.2 дополняет это версионированными сценариями и рекомендацией фиксировать идентификатор версии. В отчёте лучше написать WSTG-v42-… с границей применимости, чем «проверили OWASP» без предмета и версии.
Маршрут: симптом → причина → проверка → действие
- Симптом. В задаче есть домен и тема аудита, но непонятно, входит ли в него identity provider, upload delivery или административный путь.
- Причина. Команда начала с техники, не зафиксировав активы, владельцев, данные и переходы между ними.
- Проверка scope. Выберите один пользовательский сценарий и заполните карточки активов. Для каждого перехода спросите: кто владелец, какие данные пересекают границу и какой вопрос мы хотим подтвердить.
- Проверка permission. Отдельно получите и запишите допустимый метод, среду, период, точку остановки и контакт.
security.txt, публичный экран и ссылка на стандарт не заменяют этот шаг. - Действие. Уберите из плана всё, у чего нет owner или разрешённой границы. Неизвестный участок пометьте как evidence gap и назначьте следующий разговор, а не как «низкий риск».
- Повтор. Перед каждым новым классом проверки сравните план с той же картой: если появился новый актив или third-party boundary, обновите scope и согласование до действия.
Rollback должен возвращать договор, а не обещание
У аудита тоже есть обратимое действие. Если карта оказалась неверной, безопасный rollback — не «продолжаем осторожнее», а возврат к предыдущей версии scope: убрать неподтверждённый актив из плана, отметить evidence gap, восстановить старую формулировку и снова запросить подтверждение владельца. Это не удаляет результаты и не отменяет инцидент: в учебной модели таких объектов вообще нет. В реальной работе нужно отдельно указать, что происходит с уже собранными материалами, доступами и задачами, потому что именно там возникает риск распространить лишние данные.
Следующий шаг занимает меньше часа: провести review одной карты с владельцем самого ценного пользовательского пути. В результате должна появиться не презентация, а versioned scope record: активы, boundary, owner, класс данных, вопрос проверки, разрешённый метод, запретные действия и способ остановки. Если хотя бы одно поле неизвестно, это и есть результат аудита на сегодня. Не следует имитировать полноту новым чек-листом; сначала надо закрыть пробел в договоре.
Историческая граница декабря 2023
К концу декабря 2023 уже были доступны NIST SP 800-115 (сентябрь 2008), OWASP WSTG v4.2 (3 декабря 2020), ASVS 4.0.3 (28 октября 2021) и RFC 9116 (апрель 2022). В статье используются их определения planning, versioned testing guidance, verification requirements и disclosure boundary. Они не превращают synthetic fixture в аудит, не дают permission и не позволяют говорить о реальном покрытии проекта.
Проверяемые источники
- 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. Она не учитывает автоматически владельца, обратимость изменения, доказательство, разрешённые границы или бизнес-контекст конкретной команды.