Суть
1. Что это за аудит и зачем он нужен
AuditGuard нужен в тот момент, когда владелец сайта понимает: проблема может быть не в одном сломанном заголовке или одном лишнем скрипте, а во всей связке сразу — сервер, third-party контур, browser runtime, SEO, accessibility, GEO/AI-видимость и публичная кибербезопасность. По отдельности это выглядит как «технические мелочи», а вместе превращается в потерю трафика, шумные инциденты, слабый trust, регресс после релиза и неприятные сюрпризы перед запуском рекламы или продаж.
Поэтому сервис устроен как first-line аудит публичного технического контура. Он не притворяется pentest-командой и не обещает магического автолечения. Его задача другая: быстро и честно показать, где сайт технически и публично уязвим, что реально ломает trust, индексацию, цитируемость и базовую защиту, и какой следующий шаг даст наибольший эффект.
Для владельца сайта
Сервис помогает быстро понять, где у сайта технические, SEO, GEO, accessibility и публичные security-риски, и что исправить в первую очередь без погружения в сырые логи и десятки разрозненных сканеров.
Для команды
Отчёт удобно передавать по ролям: разработчику, DevOps, владельцу, SEO или маркетингу, без лишней ручной расшифровки findings и бесконечных «а что именно имелось в виду».
Для повторной проверки
Аудит фиксирует versioning, checked pages и findingSource, чтобы можно было сравнивать состояние сайта до и после исправлений и видеть, что реально изменилось.
Pipeline
2. Как AuditGuard превращает URL в отчёт
Аудит начинается не с оценки, а со сбора фактов. Сначала нормализуется URL, проверяется доступность домена, выбирается канонический старт, собирается список checked pages и фиксируется crawl manifest. Уже на этом этапе важно не «угадывать» состояние сайта, а понять, какие страницы и сценарии реально попали в обход.
Дальше включается browser/runtime слой: он нужен не для красивой симуляции браузера, а для тех случаев, где HTML сам по себе недостаточен. Например, third-party script может грузиться раньше основного интерфейса; форма может выглядеть статичной, но отправляться через скрытый XHR-маршрут; сервер может отвечать корректно, а клиентская часть — падать в runtime. После этого facts со страниц, из DNS, TLS, browser evidence и external services сопоставляются между собой и только затем превращаются в signals, problem zones и top actions.
URL и обход
Стартовый адрес, каноникализация, ключевые страницы, checked pages и crawl manifest.
Browser и runtime
Runtime-поведение интерфейса, формы, storage, внешние сервисы и публичные страницы.
Сигналы и problem zones
Rule engine собирает сигналы, группирует их в problem zones и показывает top actions.
Fix package
После отчёта пользователь получает отдельный слой с инструкциями, snippet-ами и post-fix checklist.
Процесс
3. Как проходит аудит
Нормализация и старт
Система определяет канонический URL, снимает базовые заголовки и формирует стартовый набор ключевых страниц. Это важно, чтобы не смешивать `http/https`, зеркала, старые пути и служебные редиректы.
Обход публичного контура
Движок обходит главную, методологию, compare-страницы, контакты, trust-секции и ключевые технические маршруты. Мы сознательно остаёмся в публичной зоне и не пытаемся «выламывать» сайт изнутри.
Browser-level сценарий
Отдельный runtime-слой проверяет storage, actionless/XHR-формы, внешние скрипты, performance-хвосты и поведение интерфейса. Это позволяет видеть не только текст на странице, но и то, как страница действительно ведёт себя для пользователя.
Сопоставление сигналов
Факты не оцениваются по одному. Сервер, DNS, TLS, browser runtime, third-party scripts, SEO/GEO и accessibility evidence сверяются между собой, чтобы отчёт ловил не только отсутствие чего-то, но и внутренние противоречия публичного контура.
Сборка отчёта
На выходе формируются summary, problem zones, top actions, technical appendix, checked pages и reproducibility-блок. Пользователь видит не просто найденный signal, а его место в общей картине сайта.
Архитектура
4. Какие слои есть у движка
Внутри AuditGuard несколько разных слоёв, и это важно для качества результата. Если бы сервис опирался только на текст страниц, он пропускал бы runtime-проблемы. Если бы он смотрел только на browser-слой, ему было бы сложнее объяснять серверные и infrastructural противоречия. Если бы мы оставили только внешние enrichments, продукт бы быстро соскользнул в noisy security scanner. Поэтому текущая архитектура — это не один «большой детектор», а сочетание слоёв, у каждого из которых есть своя роль.
Threat Intelligence (Session 1, 2026-05-30): Добавлены три новых источника приоритизации угроз:
- Shodan InternetDB — открытые порты и CVE по IP-адресу цели (бесплатный API). Позволяет видеть административные сервисы, торчащие в интернет без WAF.
- FIRST EPSS — вероятность эксплуатации каждой CVE в ближайшие 30 дней (0–100%). EPSS ≥ 50% = приоритет немедленного патчинга.
- CISA KEV — официальный каталог уязвимостей, реально используемых злоумышленниками прямо сейчас. CVE из KEV получают статус critical с hardSignal.
SEO/GEO Checks (Session 2, 2026-05-30, только AuditGuard): Добавлены новые проверки, которых ранее не было:
- X-Robots-Tag noindex — проверка HTTP-заголовка на server-level блокировку индексации (nginx/Apache/CDN)
- Home page noindex — специфичная проверка: закрыта ли главная страница от поисковиков через meta robots
- Broken links sampler — HEAD-запросы к 10 внутренним ссылкам с главной страницы, выявление 4xx/5xx
- JSON-LD Organization completeness — проверка полноты разметки для Google Knowledge Graph: logo, sameAs, description, contactPoint
Reference Intelligence (S5-S6, 30.05.2026):
- S5-1 Fix Prompt — кнопка «📋 AI-промпт» на каждой карточке находки AG: копирует готовый промпт в буфер обмена для вставки в ChatGPT/Claude
- S5-2 Trickest PoC — пассивная проверка trickest/cve GitHub HEAD-запросом: если PoC опубликован → high severity finding
- S5-3 Passive Error Leak — по паттернам PayloadsAllTheThings: SQL-ошибки, stack trace, debug-режим, утечка .env (только technical_first)
- S6-1 ToS;DR — рейтинг политики сервиса (A–E через api.tosdr.org); уровень D/E → medium finding; A/B → положительный сигнал
- S6-2 Shared Hosting — HackerTarget Reverse IP: >100 соседей на одном IP → medium риск; >30 → low
- S6-3 Гос. предприятие — детекция ОПФ ФГУП/ГУП/МКУ/ФКУ из DaData; ссылки на ЕИС и РНП ФАС в рекомендации
Mobile + SEO + GEO (S7, 02.06.2026): 5 новых проверок:
- ENG-MOBILE-ZOOM-BLOCKED — user-scalable=no / maximum-scale=1 в viewport (WCAG 1.4.4, Google accessibility penalty)
- ENG-MOBILE-PICTURE-SRCSET — отсутствие адаптивных изображений: <picture> / srcset — замедляет LCP на мобильных
- ENG-SEO-BREADCRUMB — отсутствие BreadcrumbList Schema.org/JSON-LD: поисковики и LLM-краулеры не видят иерархию сайта
- ENG-GEO-H2-QUESTIONS — <15% заголовков H2/H3 в формате вопросов снижает AI Overviews и answer engine visibility
- ENG-GEO-TLDR — отсутствие блока TL;DR / «Кратко» на контентных страницах снижает AI Share of Voice
- ENG-RKN-LIVE — DNS → TCP → TLS → HTTP проба с российского IP; определяет тип: DNS poisoning, TCP reset, TLS DPI по SNI (ТСПУ), ISP stub-страница
- Дополняет статический реестр РКН — живой зонд ловит актуальные блокировки в том числе ТСПУ, которые не всегда попадают в реестр своевременно
- Severity: critical для DNS/TCP/TLS-блокировок, high для stub-страниц, medium для таймаутов
Security layer (базовый): Mozilla Observatory усиливает security-header профиль, URLhaus, Phishing.Database и ThreatFox добавляют public-first reputation-сигналы, OpenPhish — дополнительный phishing-source, PageSpeed — производительность. Suspicious targets режутся preflight-профилем, скачиваемые файлы проходят quarantine.
Threat-intel layer (новый 2026-05): AlienVault OTX (0 ключей, 30M+ IoC-пульсов), AbuseIPDB (IP-репутация, 1000 req/day free tier) (70+ AV-движков, key-gated), URLScan.io (публичная история сканов), Disify (одноразовые email в контактах), GeoJS (fallback IP-геолокация без ограничений). Все интеграции работают в параллельном режиме через Promise.allSettled — отказ одного источника не блокирует аудит.
Безопасность самих интеграций: Все 23+ источника находятся в реестре с DNS-пинингом, SSL fingerprint и еженедельной проверкой schema. Авто-карантин при двух подряд сбоях. Bundle integrity (SHA256) фиксируется при каждом деплое. Эти интеграции усиливают текущие проверки, но не подменяют rule engine и не ломают аудит при недоступности одного источника.
Rule-based ядро
Основной контур AuditGuard. Именно он отвечает за детерминированные проверки, scoring и explainability.
- server, routes, forms, external services и browser runtime;
- SEO, GEO, a11y, language, public claims и content-risks;
- связка indexability, technical trust и third-party consistency;
- отдельные checks на language quality, runtime regressions и security-header hygiene.
Browser / runtime слой
Нужен там, где HTML недостаточно и важна реальная работа страницы.
- runtime errors, lazy UI и hidden render-paths;
- localStorage, sessionStorage и technical tracking behavior;
- XHR-submit, hidden routes и client-side формы.
Phase 5-6 stack
Этот слой усиливает текущие правила новыми источниками evidence и новыми deterministic-модулями public-first проверки. Он не подменяет собой ruleset, а делает существующие выводы точнее, воспроизводимее и полезнее для внедрения.
- `httpx`, `wafw00f`, `katana`, `gau`, `subfinder`, `amass` — truth layer, WAF-awareness и discovery;
- `gau`, `waybackurls`, `subfinder` — historical и subdomain discovery;
- `pa11y`, `axe-core`, `lighthouse` — accessibility, performance и UX evidence;
- Document extraction pipeline: HTML (visible text), PDF (
pypdf→pdftotext→strings→ OCR черезtesseract.jsкак last resort), DOCX (unzip word/document.xml), images (tesseract OCR). Subdomains (legal.domain.ru,docs.domain.ru) теперь сканируются. ИНН/ОГРН из extracted text кормятrknProfileиdadataProfile(SP-E7, с 29.05.2026); - `retire.js` и safe path probe — public-first сигналы по уязвимым JS-библиотекам, debug/admin/config surface и accidental exposure;
ENR-GREEN(Green Web Foundation) — проверяет, работает ли хостинг сайта на возобновляемой энергии; формирует сигнал направления Sustainability;ENG-SCHEMA— обнаружение и валидация JSON-LD / schema.org разметки: тип сущности, обязательные поля и машинная цитируемость;ENG-DNS-SEC— наличие DNSSEC-подписи и CAA-записей; снижает риск DNS-перехвата и несанкционированного выпуска сертификатов;- `security headers / route surface / runtime regressions` — deterministic слой для технических рисков публичного контура;
- `search / geo / ai visibility checks` — отдельный кластер для индексации, answer engines и machine-readable структуры сайта.
AI слой
AuditGuard — полностью rule-based. AI не участвует в findings и scoring. Каждый вывод детерминирован и воспроизводим (ADR-009): security-продукт не должен галлюцинировать.
SitePravo — AI-assisted (с 29.05.2026, gpt-4o-mini): AI-слой дополнительно проверяет юридические документы, спорные findings и формирует narrative. Все rule-based findings остаются детерминированными; AI добавляет контекст поверх, не заменяя оценку.
- AuditGuard: findings = deterministic правила, score = веса severity, без LLM;
- SitePravo:
aiReviewDocumentsIfConfigured,aiReviewFindingsIfConfigured,aiReviewSiteNarrativeIfConfigured; - graceful degradation: аудит продолжается в rule-only режиме при недоступности AI;
- модель configurable в DB; таймауты 20s/30s; промпты ≤6000 символов/документ.
Knowledge / reasoning слой
Phase 10 уже усилил движок слоем классификации сайта, official-source контуром и матрицей обязательности, чтобы отчёт не путал прямые обязанности, сценарные требования и рекомендации.
- business-type classification: `leadgen`, `catalog`, `ecommerce`, `services`, `content/media`, `saas`;
- requirement typing: `critical technical`, `security`, `visibility`, `trust`, `recommendation`;
- evidence typing: `text`, `header`, `runtime`, `network`, `inference`, `manual check`;
- official-source layer: browser/runtime evidence, registry facts, factual DNS/TLS reasoning и explainable enrichment output;
- отдельная логика для ситуации, когда страница существует, но её runtime, headers или связанный technical контур противоречат друг другу;
- Wave 2 provenance: quality-ladder для linked HTML/PDF/DOCX, OCR fallback и extraction trust вместо безымянного “файл найден”.
Security самого AuditGuard
Мы отдельно защищаем и сам сервис, а не только проверяем чужие сайты.
- отдельный rate limit на аудит;
- SSRF/runtime URL guard и app-level egress hygiene;
- scan safety preflight для suspicious targets;
- quarantine для скачиваемых PDF/DOCX, `YARA` и `ClamAV` path;
- security metrics, watchdog и Telegram alerts с явными причинами деградации, а не только общим названием алерта.
Отчётный слой
Результат должен быть не dump finding-ов, а документ, с которым можно идти в работу.
- web/PDF parity;
- problem zones и top actions;
- technical appendix и checked pages;
- fix package для следующего шага после аудита.
Направления
5. Что именно мы проверяем
Текущие 9 направлений удобнее читать не как длинную простыню правил, а через несколько продуктовых кластеров. Так проще понять и владельцу бизнеса, и разработчику, и SEO-команде, где именно лежит риск: в сервере, браузерном runtime, third-party контуре, индексации, accessibility или публичной безопасности сайта.
Внешний контур и third-party сервисы
- analytics, maps, chat, CRM, embed и другие внешние technical integrations;
- third-party scripts, loaders и неожиданные внешние зависимости;
- runtime storage и технический consent/tracking contour;
- foreign processors и public trust signals вокруг интеграций.
Здесь аудит показывает, какие внешние зависимости реально присутствуют на сайте, как они подгружаются в runtime и не создают ли они неожиданный технический или доверительный риск.
Сервер и браузерная изоляция
- headers, HSTS, TLS, cookie flags и базовый hardening;
- COOP, COEP, CORP, CSP и browser isolation surface;
- mixed content, redirect issues и host/canonical consistency;
- серверные ответы, статусы и public-facing конфигурационные хвосты.
В этом кластере особенно важна связка headers + runtime: сайт может внешне открываться нормально, но быть слабым по изоляции вкладки, загрузке ресурсов и защите браузерного контура.
Публичная кибербезопасность
- debug/docs/metrics exposure и accidental public files;
- token-like strings, secret-like fragments и unsafe client artifacts;
- reputation feeds: AlienVault OTX, AbuseIPDB и URLScan.io;
- safe enrichments без exploit-логики и intrusive probing.
Мы сознательно остаёмся в public-first security модели. Это значит, что проверка показывает открытые техповерхности, exposures и trust-риски, но не скатывается в агрессивный pentest или brute-force сценарии.
SEO, GEO и AI-видимость
- title, description, H1, canonical и sitemap consistency;
- robots, indexability и crawl quality;
- definitional blocks, compare-sections и citation-friendly structure;
- llms.txt / ai.txt и AI-discovery hygiene.
Мы смотрим не только классический SEO-каркас, но и готовность сайта к машинному чтению: фактические блоки, понятные определения, стабильность структуры и hygiene для AI-crawlers и answer engines.
Техническая доступность
- alt, labels, lang, aria и базовая навигация;
- mobile viewport и базовая пригодность интерфейса;
- 404 hygiene, checked pages и tech quality signals.
Это не отдельный accessibility-аудит на уровне WCAG-стандарта, а first-line слой пригодности: может ли пользователь понять форму, дойти до кнопки, открыть ключевую страницу и не теряется ли интерфейс на мобильном контуре.
Сайт как продукт и runtime UX
- статический HTML vs browser render и critical route health;
- actionless/XHR-формы, runtime errors и client-side regressions;
- trust-блоки, claims и public promise vs technical reality;
- готовность к hardening-модулю и повторной проверке после фиксов.
Этот слой связывает сухие технические сигналы с реальным пользовательским сценарием: страница может отвечать `200`, но при этом падать в runtime, ломать CTA, терять title, выдавать stale content или вести в тупиковые маршруты.
Отчёт
6. Как читать результат аудита
Старый формат «длинная лента finding-ов» редко помогает владельцу сайта что-то внедрить. Из него трудно понять, какие проблемы связаны между собой, что даст быстрый эффект, кому именно это передать и что можно закрыть одним большим решением. Поэтому в Report V2 логика чтения меняется: сначала summary и problem zones, потом top actions, а уже затем technical appendix и полный список сигналов.
Сначала диагноз
Отчёт начинается с summary, общего балла, количества сигналов, problem zones и top actions. Это верхний уровень для владельца и управленческого чтения.
Потом приоритет
Вместо длинного списка однотипных finding-ов сервис сначала показывает крупные проблемные зоны и действия, которые закрывают несколько рисков сразу.
Потом приложение
Technical appendix остаётся доступным для разработчика, DevOps и повторного контроля, но больше не ломает читаемость отчёта и не мешает первому решению.
Аудитируемость
7. Что сохраняем для повторной проверки и explainability
Прозрачность для нас — это не только красивое объяснение текста finding-а. Важно, чтобы пользователь понимал, что именно было проверено, на каких страницах, каким способом и из какого источника пришёл сигнал. Поэтому audit-result хранит не только итоговые выводы, но и слой воспроизводимости: checked pages, crawl manifest, findingSource, версии движка и ruleset, а для части сигналов — extraction method. Начиная с текущего runtime slice Волны 2, document-heavy evidence получает и нормализованный provenance-слой: `documentParsingProfile`, `trustBand`, `confidenceBand`, `parserReason`, `ocrUsed`, `ocrMode`.
Checked pages
Показывают, какие URL реально попали в обход. Это помогает понять, был ли найденный сигнал взят с продающей страницы, compare-страницы, технического маршрута, app-route или просто типового alias-path.
Finding source
Показывает, из какого контура пришёл вывод: browser runtime, HTML, headers, DNS, WHOIS, historical discovery, subdomain discovery, file extraction или parsing. Для download-heavy evidence доезжают и trust/confidence поля extraction-контура. Это снижает ощущение «чёрного ящика» и помогает вручную перепроверять сложные случаи.
Crawl manifest
Фиксирует, сколько страниц было найдено, обойдено, отклонено лимитом, заблокировано robots/noindex/canonical или не успело ответить. Для бизнеса это не просто техничка: так видно, не спрятан ли важный документ или раздел слишком глубоко.
Версии движка
В результате сохраняются engineVersion и rulesetVersion. Это делает сравнение «до и после исправлений» честнее и не смешивает выводы разных версий движка в один безымянный балл.
После аудита
8. Как выводы переходят в реальные задачи
Смысл аудита не в том, чтобы выдать красивый список проблем, а в том, чтобы сократить путь до внедрения. Поэтому после summary и problem zones пользователь получает следующий слой: fix package. Он раскладывает задачи по ролям, показывает, что можно копировать почти как есть, где нужна адаптация под стек, а где нужен более глубокий ручной review.
Fix package
- полный пакет исправлений после аудита;
- problem-zone grouping и role-based blocks;
- статусы: готово к вставке, нужна адаптация, требует ручного review;
- post-fix checklist и точечные переходы из finding-ов.
Deterministic templates
Для типовых проблем сервис подбирает remediation snippets: server/header hardening, DNS/mail-security заготовки, CSP/COOP/COEP scaffolds, route/redirect patterns, monitoring hints и другие опорные шаблоны.
Переход по ролям
Разработчик получает headers, forms, integrations и routes. DevOps — сервер, TLS, browser isolation и security surface. Владелец — очередность шагов и бизнес-эффект. SEO/маркетинг — indexability, GEO, claims и trust consistency.
Повторная проверка
После внедрения аудит можно повторить и сравнить problem zones, checked pages и оставшиеся сигналы. Это закрывает цикл от диагностики к проверке результата.
Ограничения
9. Где граница автоматической проверки
- автоматический аудит не заменяет ручной pentest, review инфраструктуры и продуктовый QA;
- закрытые кабинеты, внутренние панели, staging и частные API без доступа не видны автоматике;
- часть security и content-выводов требует ручного контекстного просмотра;
- внутренняя логика хранения логов, CI/CD, секретов и привилегий требует manual review;
- мы не проводим brute force, не эксплуатируем уязвимости и не делаем pentest.
Итог: AuditGuard нужен для того, чтобы быстро и честно показать владельцу сайта, где у него технические и public security-риски, почему они важны и что исправить первым. Дальше — либо повторный аудит, либо ручной разбор с разработчиком, DevOps и владельцем по уже собранным evidence и checked pages.
Связанные материалы
10. Где почитать подробнее
Версия
11. Текущая версия движка
445+ параметров, 46+ инструментов, 9 направлений — rule engine + browser runtime + security enrichments + AI-assisted layer (SitePravo), Report V2, ops/self-diagnostics и Phase 9 security contour сканера.
Ключевые улучшения (02.06.2026): +5 mobile/SEO/GEO-проверок (ENG-MOBILE-ZOOM-BLOCKED, ENG-MOBILE-PICTURE-SRCSET, ENG-SEO-BREADCRUMB, ENG-GEO-H2-QUESTIONS, ENG-GEO-TLDR). SSL-INFO: срок SSL теперь всегда в отчёте. Исправлен ложный positive Bitrix; CSP: только script-src unsafe-inline снижает оценку; улучшены фильтры Nikto.
Ключевые улучшения (03.06.2026): ENG-RKN-LIVE — живой сетевой зонд на блокировки РКН/ТСПУ (DNS poisoning, TCP reset, TLS DPI, HTTP stub). Исправлено 3 ложных срабатывания: X-Frame-Options при наличии CSP frame-ancestors, /404 как «сломанная страница», дублирующий чек llms.txt в Next.js. URLScan.io расширен: скриншот браузера в отчёте + ENG-URLSCAN-EXTERNAL (внешние домены). Запущена staging-среда для безопасного тестирования патчей.
P0/P1 обновление (03.06.2026, сессия 5): CISA KEV finding — добавлен дисклеймер о применимости CVE к конкретной версии сервиса. CF-Ray WAF soft fail — при наличии cf-ray header WAF-finding теперь указывает на Cloudflare Dashboard. Confidence-aware CRITICAL scoring — оценка CRITICAL только при maxCriticalConfidence ≥ 0.8, иначе HIGH_RISK. Per-domain cooldown — 5-минутный запрет повторного аудита домена без авторизации. Группировка findings в отчёте — аккордеон по направлению при 2+ сигналах.
P2 обновление (03.06.2026, сессия 6): WCAG 2.2 criterion IDs — движок теперь парсит коды Pa11y (вида WCAG2AA.Principle1.Guideline1_4.1_4_4.G179) и добавляет в текст рекомендации и поле wcagCriteria конкретные номера критериев WCAG 2.2 (например, «1.4.4 Resize text», «2.4.11 Focus Appearance»). Покрыты все 43 критерия от 1.1.1 до 4.1.3 включая новые WCAG 2.2: 2.4.11, 2.5.7, 2.5.8, 3.3.7, 3.3.8. SARIF 2.1.0 export — новый endpoint GET /api/audits/:id/sarif возвращает результат аудита в формате SARIF 2.1.0 (Static Analysis Results Interchange Format) для интеграции с GitHub Security tab, GitLab SAST и CI/CD-пайплайнами. Severity-маппинг: critical/high → error, medium → warning, low → note. Badge SVG v2 — три секции [label | grade | score] вместо двух, grade-специфичные цвета (A+ зелёный #1aa35a, CRITICAL тёмно-красный #7b241c), адаптивная ширина grade-секции, role="img", aria-label, <title>-тултип, заголовки X-Audit-Grade и X-Audit-Score.
P2 обновление (03.06.2026, сессия 7): JS-фреймворк fingerprinting — движок расширен функцией extractJsFrameworkDetail(), которая извлекает версию фреймворка (Next.js buildId, Vue version comment, React bundle marker, Angular ng-version) и сохраняет структурированный объект jsFramework: { name, version } в результате аудита. Версия используется в эвиденс-строках CVE-находок и снижает FP при определении применимости. NVD API 2.0 CVSS v3 — новый компонент runNvdCvssLookup(): для CVE-ID из CISA KEV и Shodan InternetDB выполняется поиск CVSS v3.1/v3.0/v2 балла через services.nvd.nist.gov/rest/json/cves/2.0?cveId=.... Лимит — 8 CVE на аудит, rate-limit 7 сек между запросами, кеш 24ч. Результат добавляется в текст finding: «CVE-XXXX [CVSS 3.1=9.8]». Версионирование методологии (P2-AG-10) — таблица audit_reports расширена колонками methodology_version (значение 2026.06.1) и engine_version; заполняются автоматически при сохранении каждого аудита. Константа AUDIT_RULESET_VERSION обновлена до 2026-06-03.
P2 обновление (03.06.2026, сессия 8): Contrast ratio CDP (P2-AG-7) — движок вычисляет коэффициент контраста текст/фон через getComputedStyle в CDP для всех p,h1-h6,span,a,li,td,button,label элементов; нарушения WCAG 2.2 AA (< 4.5:1 или < 3:1 для крупного) → finding с worst-ratio и списком элементов. Rule Registry (P2-AG-8) — RULE_REGISTRY со структурированными метаданными (profiles, effort, falsePositiveRisk) для 25+ правил. Confidence contract (P2-AG-9) — каждый finding содержит businessImpact, effort, falsePositiveRisk; автовычисление через _deriveConfidenceContract(). GitHub Action (P2-AG-4) — auditguard/scan@v1: action.yml + dist/index.js (Node.js 20, без внешних зависимостей); inputs: url, threshold, fail_on_critical, output_sarif; интеграция с GitHub Security tab через SARIF upload; PR-комментарий с badge. Файлы: /var/www/auditguard/github-action/.
Ключевые улучшения движка (29.05.2026): SP-E1 (убран ложный CRITICAL при reachable_but_invalid), SP-E3 (WAF low/смягчён), SP-E4/E5 (legal-subdomains + расширенные URL паттерны), SP-E6 (ИНН из linked docs → нет ложного «нет реквизитов»), SP-E7 (ИНН/ОГРН из PDF/DOCX/HTML → rknProfile активен), AI model fix (gpt-4o-mini), таймауты AI 20s/30s.
Полный live-stack (29.05.2026):
Crawl & discovery: `httpx`, `katana`, `waybackurls`, `gau`, `subfinder`, `amass`
Security scanners: `nuclei-safe` (1 000+ CVE-шаблонов), `nikto` (safe mode), `sslyze` (Heartbleed/ROBOT/CCS), `nmap` (safe ports), `dalfox` (XSS), `gitleaks`, `trufflehog`, `SecretFinder`
Browser runtime: `pa11y` + `axe-core` (WCAG), CDP Chrome (JS-ошибки, failed requests), `lighthouse`/PageSpeed
TLS/SSL: `testssl` deep scan, SSLabs, sslyze (Heartbleed, ROBOT, CCS injection, TLS 1.0/1.1)
Reputation & threat intel: Mozilla Observatory, URLhaus, PhishTank, OpenPhish, Phishing.Database, Google Safe Browsing, AbuseIPDB, urlscan.io, ThreatFox
OSINT: `theHarvester`, `amass`, `subfinder`, `crt.sh`, Wayback Machine/`waybackurls`
Content & frameworks: `WPScan`, `whatweb`, `retirejs`, `wafw00f`, `pa11y`, `photon`
DNS security: DNSSEC, CAA, MTA-STS, DKIM/SPF/DMARC, DNS zone transfer probe
Sustainability: `ENR-GREEN` (Green Web Foundation), Carbon API (websitecarbon.com)
Обновление (04.06.2026, сессия 11): Shared engine — добавлены 4 новых SitePravo-only legal-first проверки (P3-SP-22/24/25/26) в общий движок. Регрессионные тесты расширены до 52 (unit + integration). AuditGuard technical-first параметры не изменились: 445+, 9 направлений.
Обновление движка (04.06.2026, сессия 12): В shared-движке добавлен тематический классификатор (ОКВЭД + ключевые слова + домен → topicProfile) и 6 отраслевых правовых блоков для SitePravo-режима: медицина (323-ФЗ), ERID (38-ФЗ ст.18.1), 18+ (436-ФЗ), eCommerce (ПП №612), СМИ (2124-1), финансовые услуги (353-ФЗ). Всего 22 новые проверки. SitePravo: 640+ параметров. AuditGuard: технический аудит без изменений.
Обновление движка (13.06.2026, сессия 13): Новый сводный блок «GEO/AI-видимость» (geoAiVisibility) в отчёте AuditGuard — 5 структурированных элементов: (1) таблица доступа AI-ботов к сайту по robots.txt (GPTBot, ChatGPT-User, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended, CCBot, Bytespider и YandexAdditional — ЯндексGPT/Нейро) со статусом allowed/blocked/unspecified и рекомендацией по каждому; (2) сводка по llms.txt и ai.txt — наличие, статус, найденные проблемы (раскрытие закрытых разделов, слишком слабое описание для AI-краулеров); (3) сводка структурированных данных — найденные типы schema.org (Organization, LocalBusiness, WebSite, Service, Product, Article, FAQPage, BreadcrumbList) и наличие FAQ-разметки; (4) свежесть контента — анализ <lastmod> в sitemap.xml, порог устаревания 180 дней, список топ-5 самых старых страниц; новая находка [low][geo] при значительной доле устаревших страниц. Расширен regex детекции AI-директив robots.txt (hasExplicitAiCrawlerDirective) добавлением YandexAdditional. Блок доступен только для AuditGuard (technical_first); для SitePravo не отображается. Константа AUDIT_RULESET_VERSION обновлена до 2026-06-13, methodology_version — до 2026.06.6.
Обновление движка (13.06.2026, сессия 15): Блок «GEO/AI-видимость» (geoAiVisibility) расширен по итогам анализа сторонних GEO/security-инструментов: (1) таблица AI-ботов увеличена с 9 до 14 — добавлены OAI-SearchBot, Amazonbot, Meta-ExternalAgent, Diffbot, cohere-ai (наряду с GPTBot, ChatGPT-User, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended, CCBot, Bytespider, YandexAdditional); (2) новая метрика «цитируемость» (citability) — доля текстовых абзацев объёмом 40-180 слов (оптимальный размер для цитирования в ChatGPT/Perplexity/Google AI Overviews); при низкой доле (<15% из ≥5 абзацев) формируется новая находка [low][geo] «мало самодостаточных текстовых блоков для цитирования ИИ-поисковиками». Проверка существующего покрытия security-заголовков (CSP, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy, COOP/COEP/CORP, CORS-misconfig, Cookie Secure/HttpOnly/SameSite, SRI) подтвердила: все эти проверки уже реализованы в движке AuditGuard, дополнений не требуется. Версии: AUDIT_RULESET_VERSION = 2026-06-13 (без изменения даты), rulesVersion = 2026-06-13.rules.v3, methodology_version = 2026.06.8.
Обновление движка (14.06.2026, сессия 16): Новая находка — авторизация через иностранные OAuth-сервисы. В России складывается де-факто запрет на вход на сайты и в приложения через зарубежные ID/OAuth-сервисы (Google Account, Apple ID, Facebook и др.) — за это владельцам ресурсов грозят крупные штрафы. Движок сканирует HTML на признаки кнопок и SDK входа через Google (accounts.google.com, g_id_onload, apps.googleusercontent.com), Apple (appleid.cdn-apple.com, AppleID.auth, Sign in with Apple) и Facebook (connect.facebook.net/.../sdk.js, FB.login, fb-login-button), а также по тексту кнопок («Войти через Google/Apple/Facebook», «Sign in with…», «Continue with…»). При обнаружении формируется находка externalServices[medium] «Авторизация через иностранные аккаунты (Google/Apple/Facebook) — риск штрафов по законодательству РФ» с разъяснением разрешённых альтернатив: вход по российскому номеру телефона, через Госуслуги (ЕСИА), российские ID-сервисы (VK ID, Яндекс ID и т.п.), либо иностранный e-mail как логин — если сама система авторизации находится под российским контролем. Находка применяется к обоим продуктам (SitePravo и AuditGuard), категория externalServices входит в обязательный набор категорий для обоих профилей. Версии: AUDIT_RULESET_VERSION = 2026-06-14, rulesVersion = 2026-06-14.rules.v4, methodology_version = 2026.06.9.
Обновление движка (14.06.2026, сессия 17): Новая находка — отзыв SSL-сертификатов GlobalSign у российских сайтов. По данным РБК, удостоверяющий центр GlobalSign начал процедуру принудительного отзыва ранее выпущенных SSL-сертификатов у российских компаний, ссылаясь на обновлённые требования CA/Browser Forum. Движок теперь читает издателя (issuer) TLS-сертификата при прямой проверке (checkSslExpiry → issuerOrg/issuerCN) и при обнаружении GlobalSign формирует находку cybersecurity[high] «SSL-сертификат выпущен GlobalSign — риск принудительного отзыва для российских сайтов» с рекомендацией заранее подготовить альтернативу: Let's Encrypt (бесплатно, автопродление) или отечественный TLS-сертификат от аккредитованного российского УЦ (НУЦ Минцифры и партнёры — по заявлению Минцифры, это доступно владельцам сайтов при отзыве иностранного сертификата). Находка применяется к обоим продуктам (SitePravo и AuditGuard), категория cybersecurity входит в обязательный набор категорий для обоих профилей. Версии: rulesVersion = 2026-06-14.rules.v5, methodology_version = 2026.06.10.
Обновление движка (14.06.2026, сессия 18): Критичный инфраструктурный фикс — рендер JS-страниц (Playwright) был полностью отключён. Обнаружено, что на сервере была установлена версия Chromium, не совпадающая с версией, ожидаемой пакетом Playwright (установлен build 1223, движок ожидал build 1193) — из-за этого браузерный рендер страниц молча завершался с ошибкой «Executable doesn't exist» на КАЖДОМ аудите, и все проверки, основанные на JS-рендере страницы (видимость реквизитов и контактов в футере, обнаружение PDF/DOCX-документов политики и оферты, рабочие часы, диалоги cookie и т.п.), фактически не выполнялись. Установлен правильный браузерный движок (Chromium build 1193) — рендер JS-страниц теперь работает на каждом аудите. Новая проверка — реквизиты и юридические документы на SPA-сайтах. На сайтах с client-side рендерингом (SPA/React/Vue) реквизиты оператора и ссылки на PDF/DOCX-версии политики ПДн и оферты часто появляются в DOM только после выполнения JS и не видны статическому краулеру. Движок теперь дополнительно проверяет JS-рендеренную страницу: (1) повторно ищет реквизиты (ИНН/ОГРН/КПП/адрес) в видимом тексте после рендера; (2) находит ссылки на PDF/DOCX-документы политики и оферты, которые видны только после рендера, скачивает и анализирует их текст — за счёт этого корректно определяется наличие порядка разрешения споров и полноценность документа политики ПДн. Находки «Не найдены юридические реквизиты», «Не найден порядок разрешения споров» и «страница не выглядит как полноценный юридический документ» больше не формируются ложно для SPA-сайтов, где эти данные фактически присутствуют, но видны только после JS-рендера. Регрессия по holacrm.ru проверена (score=53, 16 находок — без изменений). Версии: rulesVersion = 2026-06-14.rules.v6, methodology_version = 2026.06.11.
Обновление движка (14.06.2026, сессия 19): Уточнение приоритетов обхода сайта (SP-CRAWL-REALLINK). Общий движок (используется и SitePravo, и AuditGuard) теперь сильнее отдаёт приоритет реальным ссылкам, найденным в HTML (<a href>), перед угадываемыми путями — это снижает число ложных находок «страница не найдена» на сайтах с нестандартной структурой URL. Бюджет страниц увеличен с 30 до 40. Регрессия по holacrm.ru проверена (score=53, 16 находок — без изменений). Версии: rulesVersion = 2026-06-14.rules.v8, methodology_version = 2026.06.13.
Обновление движка (14.06.2026, сессия 20): Дополнительные точечные находки GEO/SEO/AI-видимости (на основе сверки с внешней методологией seo-geo-ai-roadmap): (1) предупреждение, если og:title совпадает с <title> страницы или выглядит шаблонно («Главная», «Welcome») — ослабляет превью ссылок в соцсетях и мессенджерах; (2) проверка несоответствия — на странице есть разметка FAQPage, но отсутствует видимый блок вопрос-ответ; (3) проверка противоречий между ai.txt, robots.txt и llms.txt (например, ai.txt разрешает использование контента, а robots.txt блокирует AI-ботов, или ai.txt ссылается на llms.txt, которого нет на сайте). Регрессия по auditguard.ru (score=92) и holacrm.ru (score=53) проверена — без изменений. Версии: rulesVersion = 2026-06-14.rules.v9, methodology_version = 2026.06.14.
Обновление движка (16.06.2026, сессия 21): Исправление 4 дефектов в анализе документов, реквизитов и краулинга. (1) Краулинг скрытых ссылок (Tilda lazy-nav) — страницы типа /documents/, /docs/ и /legal/, размещённые в выпадающих меню (Tilda и аналогичные конструкторы), теперь обнаруживаются и обходятся краулером: функция isLikelyImportantLink() расширена регулярным выражением, охватывающим эти пути; добавлены как резервные пути при отсутствии явных ссылок. (2) ИНН и ОГРН не в подвале — добавлена находка [medium→high][requisites] «ИНН и ОГРН компании не размещены в подвале сайта»: если юридическая форма (АО, ООО, ЗАО, ПАО) найдена на сайте, а ИНН/ОГРН отсутствуют в footer-блоке, формируется соответствующий вывод (требование Роспотребнадзора и ФАС к интернет-торговле и B2B-сайтам). (3) Режим работы службы поддержки — новая находка [low][requisites] «Не указан режим работы службы поддержки или контакт-центра»: для сайтов с горячей линией (8-800), колл-центром или службой техподдержки публикация режима работы обязательна по ст. 9 ЗоЗПП; находка не дублирует существующую проверку режима работы для интернет-магазинов. (4) PDF-документы: пустой ответ сервера и родительский домен — добавлено детектирование документов, которые HEAD-запрос объявляет доступными (HTTP 200), но GET-запрос возвращает 0 байт или обрывает соединение; формируется находка [high][documents] «Документ присутствует, но недоступен для скачивания». Расширен поиск PDF/DOCX на родительском домене: для b2b.ttk.ru теперь учитываются файлы с ttk.ru. Тест b2b.ttk.ru: overall: 62 (было 70), requisites: 79 (было 100), страница /documents/ обнаружена и проанализирована. Версии: rulesVersion = 2026-06-16.rules.v14, methodology_version = 2026.06.18.
Обновление движка (09.07.2026, SEO-GVOZD-7): 7 новых SEO-проверок для AuditGuard на основе анализа конкурентных инструментов. Добавлены в категорию geo (только AuditGuard / technical_first): (1) SEO-INDEX-HTML — /index.html отдаёт 200 вместо 301-редиректа, что создаёт дублированный URL для поисковиков; (2) SEO-NOFOLLOW (категория marketing, оба продукта) — внешние ссылки без rel="nofollow", включая коммерческий анкор; (3) SEO-ROBOTS-HOST — устаревшая директива Host: в robots.txt (Яндекс признал её deprecated ~2022); (4) SEO-H1-HTML — тег H1 содержит вложенную HTML-разметку (<span>, <strong> и др.); (5) SEO-H1-NOSCRIPT — тег H1 внутри <noscript>, создаёт дублирование H1 для поисковых ботов; (6) SEO-DEPRECATED-TAGS — 2+ устаревших HTML-тегов (<font>, <center>, <marquee> и др.), исключённых из HTML5; (7) SEO-OG-EXTENDED — неполные OG-теги: присутствуют og:title/og:description, но отсутствует og:type или og:locale. Параметры AuditGuard: 445+ (было 438+). Версия: rulesVersion = 2026-07-09.rules.v18, AUDIT_RULESET_VERSION = 2026-07-09.
Обновление (10.07.2026, сессия 23): Хаб бесплатных инструментов auditguard.ru/tools/ — 17 онлайн-инструментов для технических специалистов и DevOps. API-инструменты (переиспользуют движок аудита): DNS Lookup, SSL-сертификат, Security Headers, HTTP заголовки, Email Deliverability (SPF/DMARC/DKIM), CORS Checker, WHOIS. Клиентские инструменты (браузер, без бэкенда): JWT Decoder, JSON Formatter, Regex Tester, Nginx Config Generator. sitepravo.ru/tools/ → redirect на хаб. Сервис ag-tools (порт 3007, PM2). Поисковый трафик: каждая страница — отдельный SEO-документ под запрос.