# П70 · 2023-12 · Практический аудит веб-проекта — три прохода саморевью ## Рамка sidecar-партии - Slug: `editorial-2023-12-practice-security-audit`, `editorial-2023-12-mechanism-security-audit`, `editorial-2023-12-field-security-audit`. - Голос: М6, декабрь 2023. Автор действует как системный практик: начинает с конкретного пробела в audit-работе и цены неверного решения, называет границу, evidence и owner, затем оставляет обратимый следующий шаг. Речь короткая и предметная: «симптом → причина → проверка → действие». Нет вымышленного инцидента, скана, риска, coverage, compliance или результата в production. - Три независимых угла темы: practice собирает scope и карту активов до первого теста; mechanism разделяет evidence, scope и authorization; field строит порядок исправлений из evidence, owner и reversibility, а не из самой громкой severity-метки. - Граница изменений выдержана: созданы только этот review, import-safe script и три локальных SVG. Не менялись `articles.json`, registry, README, очередь, Git, staging, commit, push и любые чужие пути. ## Проход 1 — факты, модель и безопасные границы - Исторический срез проверен 31.07.2026 по первичным или официальным документам, существовавшим до конца декабря 2023: [NIST SP 800-115, сентябрь 2008](https://csrc.nist.gov/pubs/sp/800/115/final), [OWASP Web Security Testing Guide v4.2, 03.12.2020](https://owasp.org/www-project-web-security-testing-guide/v42/), [OWASP ASVS 4.0.3, 28.10.2021](https://owasp.org/www-project-application-security-verification-standard/), [RFC 9116, апрель 2022](https://www.rfc-editor.org/rfc/rfc9116.html) и [FIRST CVSS v3.1, июнь 2019](https://www.first.org/cvss/v3-1/specification-document). Использованы versioned или dated формы, а не последующие правила как будто они уже были известны в 2023 году. - Формулировки ограничены источниками. NIST описывает planning, test/examination, analysis и mitigation, но это обзор 2008 года, а не готовый современный audit-процесс. WSTG v4.2 даёт версионированные сценарии и mapping архитектуры, но не даёт permission и не доказывает coverage. ASVS 4.0.3 задаёт verification requirements, но не является сертификатом. RFC 9116 определяет disclosure channel и прямо оговаривает отсутствие implied permission to test. CVSS v3.1 описывает Base, Temporal и Environmental groups, но не заменяет контекст, owner, evidence, обратимость или решение конкретной команды. - `createSyntheticSecurityAuditPacket()` создаёт только fixed marked synthetic audit records в памяти Node. В valid branch ровно один declared boundary record, четыре asset records, четыре evidence cards и три triage cards. Все имена фиксированы и имеют `synthetic-` marker. Любой extra top-level field, заявленное real permission, новый asset field, перестановка asset map, raw evidence payload, claimed external confirmation или automatic-change triage отклоняются. - Fixture не сканирует и не брутфорсит, не обращается к URL или сети, не читает проект, код, логи, secrets, environment, Git, CI или часы, не запускает browser и реальные security tests. Ответ явно фиксирует `vulnerability=not-claimed`, `coverage=not-claimed`, `compliance=not-claimed`, `scan=not-performed`, `bruteForce=not-performed`, `securityTest=not-run`, `realPermission=not-granted` и `productionEffect=not-attempted`. - `runSecurityAuditFixture()` содержит 23 assertions: valid path проверяет scope, owners, four boundaries, unverified evidence, manual gates, отсутствие реальных claims и отсутствие обращений к данным проекта; отрицательные ветки проверяют не-synthetic input, extra field, claimed permission, asset mutation/reorder/sparse map, raw evidence, claimed confirmation и automatic change; две ветки проверяют узкий rollback. PASS не подтверждает аудит, finding, vulnerability, permission, coverage, compliance или безопасность реального веб-проекта. - Rollback намеренно возвращает только snapshot in-memory draft. Он не удаляет внешние записи, не отменяет deploy, не меняет доступы и не трогает network. В статьях отдельно сказано, что реальный rollback требует владельца, версии изменения, validation criterion и операционного плана в той среде, где действие действительно разрешено. - В первом проходе найдена модельная недосказанность: третий triage gate требовал validation/rollback plan, но не содержал literal ограничение `before-change`. Gate был исправлен на `synthetic-write-validation-and-rollback-plan-before-change`; assertion теперь проверяет одинаковое правило для всех трёх маршрутов. ## Проход 2 — редактура, голос и объём - Все три статьи начинают с проблемы и цены. Practice показывает пропущенную boundary и риск затронуть чужую инфраструктуру; mechanism — неподтверждённое утверждение, ошибочно названное finding; field — backlog, который сортируют по громкости score и превращают в неуправляемую правку. Тексты не используют вымышленные метрики, инциденты, пользователей или production-результаты. - Содержательная разница сохранена. Practice отвечает на «как сузить объект аудита» через asset card, owner и scope; mechanism — «что делает вывод проверяемым и где заканчивается разрешение» через evidence matrix; field — «почему порядок исправлений требует gates» через evidence, exposure, owner и reversibility. Общий fixture — сознательно общий учебный предмет, но каждый текст делает из него другой инженерный вывод. - В каждой статье есть минимум пять смысловых разделов, доступная таблица, собственный SVG с осмысленными `alt` и caption, исполнимый fixture, упорядоченный маршрут с буквальной формулой «симптом → причина → проверка → действие», explicit limits, rollback, next step и раздел официальных источников. Запрещённые шаблонные обороты и нераскрытые общие оценки отсутствуют. - Объём основного текста, посчитанный без списка источников: practice — **9 031** знак, mechanism — **8 586** знаков, field — **8 780** знаков. Все тексты находятся в диапазоне 5 000–15 000 и в целевой плотности 8–10 тыс. `readingMinutes`: 11, 12 и 12. - Тон соответствует траектории 2022–2024: термин получает соседний объект проверки. Scope привязан к asset/boundary/owner; evidence — к источнику, статусу и limit; CVSS — к характеристике, не к автоматической команде; rollback — к выбранному изменению и валидации. Автор не выдаётся за руководителя платформы и не заявляет, что его модель универсальна. - Во втором проходе автоматический аудит показал, что у вступления field-статьи в первых 800 знаках не было буквально слова «проблема», хотя цена и предмет были названы. Первое предложение переписано: теперь оно прямо задаёт проблему backlog-а; после исправления audit видит постановку задачи и текст не потерял краткость. ## Проход 3 — визуал, автоматические проверки и выпуск - `security-audit-2023-scope-map.svg` показывает только четыре synthetic типа активов и четыре границы; внизу крупно указан запрет трактовать схему как карту сети, перечень URL или permission. `security-audit-2023-evidence-matrix.svg` отделяет scope, owner/status и next step от permission/finding/compliance. `security-audit-2023-remediation-route.svg` завершает каждый путь gate-ом до изменения и отдельно перечёркивает automatic change, scan, brute force, URL/network access и реальные claims. - Во всех SVG есть `title`, `desc`, `role="img"`, `aria-labelledby`, контрастные цвета, крупные подписи и локальные векторные элементы. Нет `