Суть
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. Текущая версия движка
438+ параметров, 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 параметры не изменились: 438+, 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: технический аудит без изменений.