docs: add pilot validation package
This commit is contained in:
igor04091968
@@ -91,6 +91,14 @@ Security Analytics + Forensics для ролей `executive`, `manager`, `securi
|
|||||||
- [ценность пилота для заказчика](docs/PILOT_VALUE_PROPOSITION_RU.md);
|
- [ценность пилота для заказчика](docs/PILOT_VALUE_PROPOSITION_RU.md);
|
||||||
- [преддемо-runbook](docs/DEMO_RUNBOOK_RU.md).
|
- [преддемо-runbook](docs/DEMO_RUNBOOK_RU.md).
|
||||||
|
|
||||||
|
Pilot validation:
|
||||||
|
|
||||||
|
- [чеклист проверки пилота](docs/PILOT_VALIDATION_CHECKLIST_RU.md);
|
||||||
|
- [gap analysis пилота](docs/PILOT_GAP_ANALYSIS_RU.md);
|
||||||
|
- [вопросы для discovery с заказчиком](docs/CUSTOMER_DISCOVERY_QUESTIONS_RU.md);
|
||||||
|
- [критерии успеха пилота](docs/PILOT_SUCCESS_CRITERIA_RU.md);
|
||||||
|
- [конкурентное позиционирование](docs/COMPETITIVE_POSITIONING_RU.md).
|
||||||
|
|
||||||
Границы показа:
|
Границы показа:
|
||||||
|
|
||||||
- pfSense показывается только как `contract_only/readiness`, без заявления
|
- pfSense показывается только как `contract_only/readiness`, без заявления
|
||||||
@@ -239,6 +247,11 @@ collectors.
|
|||||||
- [Pilot value proposition](docs/PILOT_VALUE_PROPOSITION_RU.md)
|
- [Pilot value proposition](docs/PILOT_VALUE_PROPOSITION_RU.md)
|
||||||
- [Pilot v1.0 acceptance checklist](docs/PILOT_V1_ACCEPTANCE_CHECKLIST_RU.md)
|
- [Pilot v1.0 acceptance checklist](docs/PILOT_V1_ACCEPTANCE_CHECKLIST_RU.md)
|
||||||
- [Pilot v1.0 evidence](docs/PILOT_V1_EVIDENCE_RU.md)
|
- [Pilot v1.0 evidence](docs/PILOT_V1_EVIDENCE_RU.md)
|
||||||
|
- [Pilot validation checklist](docs/PILOT_VALIDATION_CHECKLIST_RU.md)
|
||||||
|
- [Pilot gap analysis](docs/PILOT_GAP_ANALYSIS_RU.md)
|
||||||
|
- [Customer discovery questions](docs/CUSTOMER_DISCOVERY_QUESTIONS_RU.md)
|
||||||
|
- [Pilot success criteria](docs/PILOT_SUCCESS_CRITERIA_RU.md)
|
||||||
|
- [Competitive positioning](docs/COMPETITIVE_POSITIONING_RU.md)
|
||||||
- [Production readiness портала](docs/PRODUCTION_READINESS_RU.md)
|
- [Production readiness портала](docs/PRODUCTION_READINESS_RU.md)
|
||||||
- [Explainable Workforce KPI](docs/EXPLAINABLE_KPI_RU.md)
|
- [Explainable Workforce KPI](docs/EXPLAINABLE_KPI_RU.md)
|
||||||
- [Executive Action Center](docs/EXECUTIVE_ACTION_CENTER_RU.md)
|
- [Executive Action Center](docs/EXECUTIVE_ACTION_CENTER_RU.md)
|
||||||
|
|||||||
@@ -0,0 +1,57 @@
|
|||||||
|
# Competitive Positioning
|
||||||
|
|
||||||
|
Сравнение носит ориентировочный характер и основано на публичном
|
||||||
|
позиционировании продуктов. Перед коммерческим использованием его нужно
|
||||||
|
сверить с актуальными официальными материалами поставщиков.
|
||||||
|
|
||||||
|
AWatch-rus не позиционируется как замена сертифицированным DLP, SIEM, EDR или
|
||||||
|
XDR. Корректное позиционирование: Workforce Analytics + Security Analytics +
|
||||||
|
Forensics с прозрачными rule-based объяснениями.
|
||||||
|
|
||||||
|
## Краткое сравнение
|
||||||
|
|
||||||
|
| Продукт | Публичная категория | Сильная сторона | Как позиционировать AWatch-rus рядом |
|
||||||
|
| --- | --- | --- | --- |
|
||||||
|
| ActivityWatch | Open-source automated time tracker | Локальный, открытый и понятный сбор активности приложений и сайтов | AWatch-rus развивает этот подход в пилотный корпоративный контур с ролями, отчетами, Risk Narrative и эксплуатационной документацией |
|
||||||
|
| Стахановец | Контроль сотрудников, мониторинг активности, DLP-возможности | Зрелый классический контроль рабочих мест и политик мониторинга | AWatch-rus не должен заявлять функциональный паритет; его сильная зона - объяснимый управленческий KPI, Security Analytics и пилотная прозрачность |
|
||||||
|
| StaffCop | Employee Monitoring, Insider Risk, Workforce Analytics, DLP | Широкий набор функций мониторинга, productivity analytics, расследований и DLP-направления | AWatch-rus нужно показывать как более узкий и прозрачный пилотный контур, без обещания заменить StaffCop по широте функций |
|
||||||
|
| SearchInform | DLP, Risk Monitor, SIEM, TimeInformer и смежные продукты | Комплексная линейка ИБ-продуктов и мониторинга внутренних рисков | AWatch-rus не конкурирует как полноценный SIEM/DLP; он может быть легким аналитическим слоем для Workforce-first пилота |
|
||||||
|
| InfoWatch | DLP и защита от утечек конфиденциальной информации | Сильное DLP-направление, политики, интеграции и регуляторный контекст | AWatch-rus не заменяет DLP; он показывает операционную активность, объяснимые риски и материалы для внутренней проверки |
|
||||||
|
|
||||||
|
## Где AWatch-rus уместен
|
||||||
|
|
||||||
|
- Быстрый пилот для руководителя, ИБ и эксплуатации без тяжелого SIEM/DLP
|
||||||
|
внедрения.
|
||||||
|
- Workforce-first аналитика с объяснением KPI, coverage и confidence.
|
||||||
|
- Разделение Executive, Workforce, Security и Forensics сценариев.
|
||||||
|
- Прозрачная rule-based модель UEBA Score v1 и Risk Narrative без ML/LLM.
|
||||||
|
- Подготовка evidence package и Markdown-отчетов для ручной проверки.
|
||||||
|
- Честная демонстрация границ: planned, future и contract_only не выдаются за
|
||||||
|
implemented.
|
||||||
|
|
||||||
|
## Где зрелые конкуренты обычно сильнее
|
||||||
|
|
||||||
|
- Глубокие DLP-политики, контентная фильтрация и блокировки каналов утечки.
|
||||||
|
- Масштабные SIEM/SOC-процессы и готовые интеграции ИБ.
|
||||||
|
- Сертификация, регуляторные пакеты и длительная промышленная поддержка.
|
||||||
|
- Большое количество готовых коннекторов, политик и отчетов для типовых
|
||||||
|
отраслей.
|
||||||
|
- Поддержка сложных enterprise-сценариев с централизованным управлением
|
||||||
|
агентами и политиками.
|
||||||
|
|
||||||
|
## Что нельзя заявлять
|
||||||
|
|
||||||
|
- Что AWatch-rus заменяет DLP, SIEM, EDR или XDR.
|
||||||
|
- Что planned или future providers уже работают в production.
|
||||||
|
- Что pfSense readiness означает готовый ingestion, если он находится в статусе
|
||||||
|
`contract_only`.
|
||||||
|
- Что Risk Narrative является ML-прогнозом.
|
||||||
|
- Что система автоматически оценивает персонал или принимает кадровые решения.
|
||||||
|
|
||||||
|
## Публичные источники для сверки
|
||||||
|
|
||||||
|
- ActivityWatch: https://activitywatch.net/
|
||||||
|
- StaffCop: https://www.staffcop.com/
|
||||||
|
- SearchInform products: https://searchinform.com/products/
|
||||||
|
- InfoWatch Traffic Monitor: https://www.infowatch.ru/products/dlp-sistema-traffic-monitor/vozmozhnosti-dlp-sistemy
|
||||||
|
- Стахановец: https://stakhanovets.ru/
|
||||||
@@ -0,0 +1,62 @@
|
|||||||
|
# Customer Discovery Questions
|
||||||
|
|
||||||
|
Вопросы нужны до пилота, чтобы не показывать AWatch-rus в отрыве от реальных
|
||||||
|
управленческих, ИБ и эксплуатационных задач заказчика.
|
||||||
|
|
||||||
|
## Директор
|
||||||
|
|
||||||
|
- Какой главный управленческий вопрос должен закрыть пилот через 30 дней?
|
||||||
|
- Какие подразделения или процессы сейчас вызывают больше всего вопросов по
|
||||||
|
активности, загрузке или прозрачности работы?
|
||||||
|
- Какие выводы руководитель хочет видеть ежедневно, еженедельно и по итогам
|
||||||
|
пилота?
|
||||||
|
- Что будет считаться доказательством ценности: снижение ручного контроля,
|
||||||
|
выявленные пробелы, отчетность, управляемость, экономия времени?
|
||||||
|
- Кто принимает решение о масштабировании после пилота?
|
||||||
|
- Какие темы нельзя показывать в демо руководителю без отдельного согласования
|
||||||
|
с ИБ или юристами?
|
||||||
|
|
||||||
|
## Руководитель подразделения
|
||||||
|
|
||||||
|
- Какие команды, роли или группы надо сравнивать между собой?
|
||||||
|
- Какие рабочие приложения считаются основными для подразделения?
|
||||||
|
- Какие признаки перегрузки и недозагрузки действительно важны для руководителя?
|
||||||
|
- Какие периоды считать рабочим временем, удаленной работой и допустимой
|
||||||
|
внеурочной активностью?
|
||||||
|
- Как трактовать низкую активность: простой, встреча, выездная работа,
|
||||||
|
отсутствие данных или реальная проблема?
|
||||||
|
- Какие рекомендации руководитель готов принимать к исполнению после отчета?
|
||||||
|
|
||||||
|
## ИБ
|
||||||
|
|
||||||
|
- Какие типы кандидатов на проверку наиболее полезны для первого пилота?
|
||||||
|
- Какие reason codes UEBA Score v1 должны быть понятны аналитику ИБ?
|
||||||
|
- Какие события нельзя показывать бизнес-ролям по умолчанию?
|
||||||
|
- Какой порядок ручной проверки incident candidate считается приемлемым?
|
||||||
|
- Какие ограничения evidence package нужно указать заранее?
|
||||||
|
- Нужно ли показывать pfSense readiness как `contract_only`, или этот блок
|
||||||
|
лучше скрыть из демонстрации до появления ingestion?
|
||||||
|
- Какие DLP/SIEM/EDR claims недопустимы в коммуникации с заказчиком?
|
||||||
|
|
||||||
|
## ИТ
|
||||||
|
|
||||||
|
- Где будет развернут портал: отдельный сервер, VM, контейнер или существующий
|
||||||
|
контур?
|
||||||
|
- Какие ОС и версии должны быть покрыты в пилоте?
|
||||||
|
- Какие рабочие станции или серверы можно подключить первой волной?
|
||||||
|
- Какой способ доступа к порталу допустим: VPN, reverse proxy, внутренний FQDN,
|
||||||
|
отдельная учетная запись?
|
||||||
|
- Кто управляет TLS, DNS, firewall rules и резервным копированием?
|
||||||
|
- Какие ограничения есть на установку агента, запуск служб и outbound traffic?
|
||||||
|
- Какой порядок отката считается безопасным?
|
||||||
|
|
||||||
|
## Эксплуатация
|
||||||
|
|
||||||
|
- Кто смотрит health, smoke и журналы во время пилота?
|
||||||
|
- Какие симптомы считать инцидентом эксплуатации: stale data, degraded reports,
|
||||||
|
недоступность портала, рост ошибок сбора?
|
||||||
|
- Какой допустимый RTO и RPO для пилотного стенда?
|
||||||
|
- Где хранить runbooks и кому разрешено выполнять restart или rollback?
|
||||||
|
- Как фиксировать замечания после демонстрации и кто закрывает каждое замечание?
|
||||||
|
- Какая периодичность контрольного отчета нужна: ежедневно, два раза в неделю
|
||||||
|
или по запросу?
|
||||||
+62
-133
@@ -1,145 +1,74 @@
|
|||||||
# Анализ разрывов готовности пилота AWatch-rus
|
# Pilot Gap Analysis
|
||||||
|
|
||||||
Дата аудита: 2026-06-06.
|
Документ фиксирует текущую готовность AWatch-rus к контролируемому пилоту.
|
||||||
|
Оценка относится к существующему состоянию продукта и не добавляет новых
|
||||||
Аудируемый срез: `origin/main`,
|
функций, API, агентов или интеграций.
|
||||||
`9c57d6d2ce7eae1b133c937f037b24933f5797fe`.
|
|
||||||
|
|
||||||
Цель: объективно определить готовность AWatch-rus к контролируемой пилотной
|
|
||||||
эксплуатации и демонстрации руководителю, ИБ и эксплуатации.
|
|
||||||
|
|
||||||
Ограничения аудита: код, архитектура, сущности и интеграции не изменялись.
|
|
||||||
Сформирован только этот аудитный документ.
|
|
||||||
|
|
||||||
Не входило в аудит: pfSense, Telegram, Grafana, InfluxDB.
|
|
||||||
|
|
||||||
## Что готово
|
## Что готово
|
||||||
|
|
||||||
- Архитектура пилота выстроена как понятная цепочка:
|
- Сформирован Pilot v1 контур с ролями `executive`, `manager`, `security`,
|
||||||
`агент -> телеметрия -> аналитика -> риск -> расследование -> отчет`.
|
`forensics` и `admin`.
|
||||||
- Rust workspace на текущем `origin/main` проходит обязательные проверки:
|
- Есть Executive, Workforce, Security и Forensics сценарии для демонстрации.
|
||||||
|
- Реализованы Workforce reports, Explainable KPI, UEBA Score v1, Risk Narrative
|
||||||
|
и Executive Action Center.
|
||||||
|
- Есть Rust Backend, Rust Agent baseline, HTML/HTMX portal и role-based
|
||||||
|
контракты Pilot v1.
|
||||||
|
- Подготовлен demo pack: сценарии руководителя, ИБ и расследований, синтетический
|
||||||
|
demo dataset, evidence pack, пример итогового отчета и value proposition.
|
||||||
|
- Подготовлены registry readiness документы без ложных заявлений о сертификации.
|
||||||
|
- Подготовлены enterprise deployment документы: topology, sizing, backup and
|
||||||
|
recovery, operations runbook, hardening и acceptance checklist.
|
||||||
|
- pfSense readiness описан как `contract_only`, без заявления production
|
||||||
|
ingestion или SIEM-функциональности.
|
||||||
|
- Скриншоты портала вынесены в `docs/screenshots/` и описаны в README.
|
||||||
|
- Есть отдельный smoke для проверки demo, registry, deployment, screenshots,
|
||||||
|
roadmap, reports и runbooks.
|
||||||
|
|
||||||
| Проверка | Результат |
|
## Что требует доработки
|
||||||
| --- | --- |
|
|
||||||
| `cargo test --workspace` | Пройдено. |
|
|
||||||
| `cargo clippy --all-targets --all-features` | Пройдено. |
|
|
||||||
| `cargo build --release` | Пройдено. |
|
|
||||||
| `node scripts/detmir-portal-tabs-smoke.mjs` | Пройдено против рабочего портала через временный туннель; `security_events=available`. |
|
|
||||||
|
|
||||||
- Portal UX проходит smoke: вкладки `Обзор`, `Сотрудники`,
|
- Провести live pilot smoke на целевом стенде заказчика, а не только локальную
|
||||||
`Подразделения`, `Риски`, `Расследования`, `Сетевой периметр`, `Отчеты`,
|
проверку репозитория.
|
||||||
`Настройки` открываются без ошибок консоли и HTTP 4xx/5xx.
|
- Зафиксировать согласованные источники данных, ожидаемое покрытие агентов и
|
||||||
- Executive View готов к показу руководителю: главный вывод расположен первым,
|
допустимую задержку обновления данных.
|
||||||
порядок управленческих блоков подтвержден smoke, англоязычные и лишние
|
- Выполнить контрольный тест backup and recovery на стенде пилота.
|
||||||
технические термины в проверяемом пользовательском слое не обнаружены.
|
- Проверить reverse proxy, TLS, авторизацию и доступность портала из сети
|
||||||
- Security View готов к показу ИБ: есть кандидаты на проверку, расследования,
|
заказчика.
|
||||||
аудит, материалы расследования и переход из риска в карточку расследования.
|
- Провести визуальную проверку портала на рабочем разрешении демонстрационного
|
||||||
Smoke подтвердил 3 кнопки перехода к расследованию.
|
ноутбука и на мобильном/планшетном экране, если такой показ предполагается.
|
||||||
- Operations View готов к показу эксплуатации: видны полнота и качество
|
- Подтвердить, что Markdown-отчеты не содержат персональных данных и внутренних
|
||||||
данных, состояние источников, режим событий безопасности и ошибки сбора.
|
идентификаторов заказчика.
|
||||||
- ClickHouse integration работает в пилотном контуре: `/api/health`
|
- Зафиксировать владельцев действий по Recommended Actions: бизнес,
|
||||||
возвращает `ok=true`, источник `security_events` активен, портал получает
|
эксплуатация, ИБ.
|
||||||
агрегированные события безопасности через ClickHouse.
|
|
||||||
- Сбор данных 1С и DLP зафиксирован как Rust-first runtime: `aw-1c-ingest-rust`
|
|
||||||
и Windows telemetry/evidence sync работают с 15-минутным циклом; скриншоты
|
|
||||||
1С не копируются, доказательные PNG остаются только для DLP-событий.
|
|
||||||
- Agent/Rust migration закрывает критичный runtime-риск: основной сбор
|
|
||||||
worktime, browser/domain, URL/domain extraction, clipboard/USB/print
|
|
||||||
incident semantics и DLP evidence path покрыты Rust-бинарниками и тестами.
|
|
||||||
- Документы `docs/PORTAL_RU.md` и `docs/SECURITY_EVENTS_CLICKHOUSE_RU.md`
|
|
||||||
присутствуют и отражают текущую модель портала и ClickHouse-событий.
|
|
||||||
- Пилотные документы находятся в единой структуре `docs/`:
|
|
||||||
`docs/CUSTOMER_PILOT_PACK_RU.md`, `docs/PILOT_READINESS_AUDIT_RU.md`,
|
|
||||||
`docs/SALES_POSITIONING_RU.md`, `docs/DEMO_RUNBOOK_RU.md`.
|
|
||||||
- 10-минутный демонстрационный путь технически доступен: главный риск,
|
|
||||||
подразделение, причина риска, кандидат, расследование, пакет расследования и
|
|
||||||
итоговый управленческий вывод показываются в портале.
|
|
||||||
|
|
||||||
## Что критично исправить
|
## Что не входит в пилот
|
||||||
|
|
||||||
Критичных блокеров в коде, сборке и smoke-проверке для контролируемого пилота
|
- Полноценная DLP-система с контентной фильтрацией, блокировками и политиками
|
||||||
на текущем срезе не выявлено.
|
предотвращения утечек.
|
||||||
|
- Полноценная SIEM-система с централизованной корреляцией всех событий ИБ.
|
||||||
|
- EDR/XDR, антивирусная защита, реагирование на вредоносный код и управление
|
||||||
|
изоляцией хостов.
|
||||||
|
- ML/LLM-прогнозирование, автоматическая классификация сотрудников и
|
||||||
|
генеративная аналитика.
|
||||||
|
- Автоматическое применение дисциплинарных или кадровых решений.
|
||||||
|
- Обязательный production ingestion pfSense.
|
||||||
|
- Юридически значимая экспертиза без ручной проверки материалов ответственным
|
||||||
|
лицом.
|
||||||
|
|
||||||
Критичные условия перед фактическим показом:
|
## Что отложено на roadmap
|
||||||
|
|
||||||
- Демо должно запускаться на контуре, где развернут именно commit
|
- Расширенные agentless providers: PowerShell, SSH, Syslog, 1C, VPN и SCUD.
|
||||||
`9c57d6d2ce7eae1b133c937f037b24933f5797fe` или более новый проверенный срез.
|
- Production validation российских ОС: Astra Linux, РЕД ОС, Альт и РОСА.
|
||||||
- Перед показом нужен короткий преддемо-прогон на той же сети и экране:
|
- Расширенный React/TypeScript Enterprise UI и Tauri Desktop Forensics.
|
||||||
открыть портал, дождаться `Данные готовы`, проверить кандидата, открыть
|
- Глубокие enterprise-коннекторы AD/LDAP, SIEM и корпоративных учетных систем.
|
||||||
расследование и сформировать отчет.
|
- Нагрузочное тестирование крупного контура с формальным capacity baseline.
|
||||||
- Нельзя продавать текущий срез как промышленно завершенную платформу без
|
- Формальный release package с подписанными артефактами, SBOM и процедурой
|
||||||
оговорок по доступу, retention, backup, versioning и регламенту эксплуатации.
|
поставки для промышленной эксплуатации.
|
||||||
|
- Дополнительные регламентные материалы для закупки и юридической приемки.
|
||||||
|
|
||||||
## Что желательно исправить
|
## Итог
|
||||||
|
|
||||||
- Русифицировать заголовки customer-facing документов: текущие документы
|
AWatch-rus готов к контролируемому пилоту и демонстрации Pilot v1 как
|
||||||
используют названия вроде `Customer Pilot Pack` и `Sales Positioning`, что
|
Workforce-first платформы с Security Analytics и Forensics-контуром. Главный
|
||||||
слабее выглядит на показе руководителю и заказчику.
|
остаточный риск не в функциональности демо, а в неподтвержденной готовности
|
||||||
- Отдельно перед демо проверить экспорт в формате, который будет показан:
|
целевого стенда: доступность портала, покрытие источников, свежесть данных,
|
||||||
текстовый отчет, печать или PDF.
|
резервное восстановление и роли ответственных за действия после пилота.
|
||||||
- Добавить в регулярный smoke мобильный/визуальный прогон. Текущий
|
|
||||||
`detmir-portal-tabs-smoke.mjs` хорошо проверяет функциональный путь, но не
|
|
||||||
является полноценной визуальной regression-проверкой.
|
|
||||||
- Сформировать явную матрицу совместимости API: agent, portal, telemetry,
|
|
||||||
ClickHouse security events и investigation state.
|
|
||||||
- Убрать из публичного customer-facing пакета внутренние формулировки про
|
|
||||||
`<LOCAL_CARGO_TARGET_DIR>`, private contour и служебные runtime-детали.
|
|
||||||
|
|
||||||
## Что перенести после пилота
|
|
||||||
|
|
||||||
- Полное hardening локальных JSON/JSONL/state-хранилищ: atomic write,
|
|
||||||
блокировки, retention, backup/restore и нагрузочные тесты больших файлов.
|
|
||||||
- Промышленный app-layer RBAC для портала. Сейчас ролевые представления есть в
|
|
||||||
UX, но контроль доступа должен оставаться задачей защищенного контура или
|
|
||||||
reverse proxy до отдельного product hardening.
|
|
||||||
- Полное удаление оставшихся PowerShell deploy/bootstrap/fallback-элементов.
|
|
||||||
Для пилота важно отсутствие PowerShell как основного runtime-сборщика; полная
|
|
||||||
зачистка deploy-истории не является блокером показа.
|
|
||||||
- Load/sizing-профиль под промышленную эксплуатацию: количество рабочих мест,
|
|
||||||
объем событий, глубина хранения, требования к ClickHouse и файловому evidence.
|
|
||||||
- Формальные регламенты хранения и доступа к материалам расследований.
|
|
||||||
- CI-упаковку customer-facing документов с проверкой путей, ссылок и русских
|
|
||||||
заголовков.
|
|
||||||
|
|
||||||
## Риски пилота
|
|
||||||
|
|
||||||
| Риск | Влияние | Оценка |
|
|
||||||
| --- | --- | --- |
|
|
||||||
| Контур демо не совпадает с проверенным commit | Возможны расхождения UI, API или данных | Критично контролировать перед показом |
|
|
||||||
| Документы или ссылки изменятся без проверки | Путает hand-off и приемку пакета | Контролировать markdown link-check перед передачей |
|
|
||||||
| Первый запуск портала без прогрева | Может выглядеть как зависшая загрузка | Управляемо преддемо-прогоном |
|
|
||||||
| В текущих данных исчезнут кандидаты на расследование | 10-минутный сценарий потеряет самый сильный пример | Проверять `/api/reports` перед демо |
|
|
||||||
| ClickHouse станет недоступен | Operations View покажет fallback/ошибку вместо полного ИБ-среза | Не блокер UI, но слабее для ИБ |
|
|
||||||
| Нет промышленного RBAC внутри приложения | Нельзя открывать портал вне защищенного контура | Для контролируемого пилота приемлемо |
|
|
||||||
| Остаточные PowerShell deploy/fallback артефакты | Могут вызвать вопросы эксплуатации о миграции | Объяснять как legacy/fallback, не runtime-core |
|
|
||||||
| Нет полной визуальной mobile regression-проверки в обязательном smoke | Возможны мелкие UX-дефекты на нестандартном экране | Проверить вручную перед показом с планшета/ноутбука |
|
|
||||||
|
|
||||||
Дополнительное наблюдение: один первичный запуск smoke через только что
|
|
||||||
созданный туннель один раз не дождался `READY` за 30 секунд. Повтор с тем же
|
|
||||||
30-секундным таймаутом прошел примерно за 8 секунд, `/portal/api/reports`
|
|
||||||
отвечал примерно за 0.4 секунды. Это не выглядит как продуктовый блокер, но
|
|
||||||
подтверждает необходимость преддемо-прогона.
|
|
||||||
|
|
||||||
## Итоговая оценка готовности
|
|
||||||
|
|
||||||
Статус: AWatch-rus готов к контролируемому демонстрационному пилоту на текущем
|
|
||||||
`origin/main`.
|
|
||||||
|
|
||||||
Оценка готовности: 88%.
|
|
||||||
|
|
||||||
Обоснование:
|
|
||||||
|
|
||||||
- Сборка, тесты, clippy, release build и portal smoke на проверенном срезе
|
|
||||||
успешны.
|
|
||||||
- Executive/Security/Operations View закрывают основной сценарий для
|
|
||||||
руководителя, ИБ и эксплуатации.
|
|
||||||
- Rust runtime migration убрал главный риск зависимости от PowerShell в
|
|
||||||
рабочих сборщиках.
|
|
||||||
- ClickHouse-события безопасности доступны и отражаются в портале.
|
|
||||||
- Оставшиеся разрывы относятся в основном к вычитке документов, преддемо
|
|
||||||
дисциплине, промышленному hardening и формальному управлению доступом.
|
|
||||||
|
|
||||||
Рекомендация: допустить к пилоту только как контролируемый демонстрационный
|
|
||||||
контур. Перед показом выполнить короткий smoke на рабочем URL, проверить
|
|
||||||
наличие кандидата на расследование, открыть пакет расследования и заранее
|
|
||||||
подготовить итоговый отчет.
|
|
||||||
|
|||||||
@@ -0,0 +1,58 @@
|
|||||||
|
# Pilot Success Criteria
|
||||||
|
|
||||||
|
Документ задает приемочные критерии 30-дневного пилота AWatch-rus. Критерии
|
||||||
|
ориентированы на проверяемую ценность, а не на маркетинговые заявления.
|
||||||
|
|
||||||
|
## Критерии успеха пилота
|
||||||
|
|
||||||
|
- Портал стабильно открывается для согласованных ролей.
|
||||||
|
- Executive сценарий за 10 минут показывает KPI, объяснение, Risk Narrative и
|
||||||
|
Recommended Actions.
|
||||||
|
- Workforce сценарий показывает активность, подразделения, тренды, coverage и
|
||||||
|
confidence без ручной сборки отчета.
|
||||||
|
- Security сценарий показывает incident candidates, UEBA Score v1 и понятные
|
||||||
|
reason codes без заявления полноценной DLP/SIEM-функциональности.
|
||||||
|
- Forensics сценарий позволяет собрать evidence package и Markdown-отчет на
|
||||||
|
проверяемом кейсе.
|
||||||
|
- Операторы понимают, как диагностировать stale/degraded данные по runbook.
|
||||||
|
- Данные пилота не раскрывают лишние персональные, сетевые или внутренние
|
||||||
|
идентификаторы в демо и отчетах.
|
||||||
|
- Заказчик может принять решение: масштабировать, доработать или остановить
|
||||||
|
пилот на основании фактов.
|
||||||
|
|
||||||
|
## Критерии провала пилота
|
||||||
|
|
||||||
|
- Портал недоступен или регулярно не проходит smoke без понятной причины.
|
||||||
|
- Ролевые ограничения показывают бизнес-ролям техническую ИБ-детализацию.
|
||||||
|
- KPI отображается без объяснения покрытия, свежести и confidence.
|
||||||
|
- Отчеты зависают при деградации источников вместо controlled degraded/stale
|
||||||
|
поведения.
|
||||||
|
- Невозможно объяснить, почему объект попал в incident candidates.
|
||||||
|
- В документах или демо обнаружены реальные IP, hostname, логины, ФИО,
|
||||||
|
подразделения заказчика или события безопасности.
|
||||||
|
- Нет владельца дальнейших действий после Recommended Actions.
|
||||||
|
- Заказчик воспринимает продукт как заявленный DLP/SIEM/EDR, хотя это не
|
||||||
|
соответствует границам пилота.
|
||||||
|
|
||||||
|
## KPI пилота
|
||||||
|
|
||||||
|
- Доступность портала в рабочее время пилота.
|
||||||
|
- Доля успешных smoke-прогонов.
|
||||||
|
- Покрытие согласованных источников данных.
|
||||||
|
- Freshness данных для ключевых отчетов.
|
||||||
|
- Время открытия Executive и Reporting сценариев.
|
||||||
|
- Количество подтвержденных и отклоненных incident candidates.
|
||||||
|
- Доля отчетов, принятых руководителем без ручной переработки.
|
||||||
|
- Количество выявленных gaps по данным, доступам, ролям и эксплуатации.
|
||||||
|
- Количество Recommended Actions, по которым назначен владелец.
|
||||||
|
|
||||||
|
## Ожидаемый результат через 30 дней
|
||||||
|
|
||||||
|
- Подтверждено, какие сценарии AWatch-rus дают ценность заказчику.
|
||||||
|
- Сформирован список источников данных, которые нужны для масштабирования.
|
||||||
|
- Зафиксированы ограничения пилота и roadmap-доработки.
|
||||||
|
- Подготовлен отчет для руководителя, ИБ и эксплуатации.
|
||||||
|
- Принято решение о следующем этапе: масштабирование, ограниченная доработка
|
||||||
|
или завершение пилота.
|
||||||
|
- Согласованы требования к production deployment: роли, доступы, резервное
|
||||||
|
копирование, мониторинг, ответственные и окна изменений.
|
||||||
@@ -0,0 +1,75 @@
|
|||||||
|
# Pilot Validation Checklist
|
||||||
|
|
||||||
|
Документ фиксирует проверку AWatch-rus перед реальным пилотом. Цель проверки:
|
||||||
|
подтвердить, что уже реализованные сценарии можно показать заказчику без
|
||||||
|
добавления нового функционала и без ложных заявлений о DLP, SIEM или EDR.
|
||||||
|
|
||||||
|
## Executive сценарий
|
||||||
|
|
||||||
|
- Главный управленческий вывод отображается первым.
|
||||||
|
- Руководитель видит KPI, Risk Narrative и Recommended Actions без технических
|
||||||
|
ИБ-деталей по умолчанию.
|
||||||
|
- Explainable KPI отвечает на вопрос, почему индекс активности имеет текущее
|
||||||
|
значение.
|
||||||
|
- Risk Narrative объясняет, что происходит, почему это риск и что делать дальше.
|
||||||
|
- Ролевые ограничения не дают роли `executive` видеть расследовательскую и
|
||||||
|
техническую ИБ-детализацию без смены роли.
|
||||||
|
- В демо используются только синтетические данные.
|
||||||
|
|
||||||
|
## Workforce сценарий
|
||||||
|
|
||||||
|
- Отображается индекс активности и объяснение факторов.
|
||||||
|
- Доступно сравнение подразделений и ответственных.
|
||||||
|
- Видны тренды daily, weekly и monthly, если данные есть.
|
||||||
|
- Отдельно показываются признаки перегрузки и недозагрузки.
|
||||||
|
- Coverage и freshness показывают надежность KPI.
|
||||||
|
- При неполных данных система снижает доверие к KPI, а не выдает уверенный
|
||||||
|
вывод.
|
||||||
|
- Отчеты не формулируют автоматическую кадровую оценку сотрудника.
|
||||||
|
|
||||||
|
## Security сценарий
|
||||||
|
|
||||||
|
- ИБ видит UEBA Score v1, risk score, severity и reason codes.
|
||||||
|
- Список incident candidates содержит объяснимые причины попадания в очередь.
|
||||||
|
- Security View отделен от управленческого Workforce Dashboard.
|
||||||
|
- pfSense readiness отображается только как `contract_only`, если задействован
|
||||||
|
соответствующий слой контрактов.
|
||||||
|
- Интерфейс не заявляет AWatch-rus как полноценный SIEM или DLP.
|
||||||
|
- Все выводы rule-based, без ML и LLM.
|
||||||
|
|
||||||
|
## Forensics сценарий
|
||||||
|
|
||||||
|
- Расследователь видит карточку расследования, timeline, evidence и экспорт
|
||||||
|
Markdown-отчета.
|
||||||
|
- Связка user, host, app и network event показывается только в рамках доступных
|
||||||
|
demo/contracts данных.
|
||||||
|
- В demo-режиме отсутствуют реальные ФИО, логины, IP-адреса, hostname и домены.
|
||||||
|
- Система помогает собрать материалы, но не формирует юридически обязательный
|
||||||
|
вывод без проверки ответственным лицом.
|
||||||
|
|
||||||
|
## Agent сценарий
|
||||||
|
|
||||||
|
- Rust Agent baseline описан и проверяется через документацию.
|
||||||
|
- Для пилота определены источники данных, ожидаемое покрытие и допустимая
|
||||||
|
задержка.
|
||||||
|
- Потеря части данных снижает confidence и фиксируется как operational gap.
|
||||||
|
- Массовое развертывание агента выполняется волнами после согласования с ИТ.
|
||||||
|
- Agentless-направления считаются roadmap или planned, если не подтверждены
|
||||||
|
текущей поставкой.
|
||||||
|
|
||||||
|
## Reporting сценарий
|
||||||
|
|
||||||
|
- `/api/reports` и портальные отчеты возвращают данные в рамках роли.
|
||||||
|
- Markdown-отчет формируется на демонстрационных данных.
|
||||||
|
- В отчете видны KPI, Explainable KPI, Risk Narrative и Recommended Actions.
|
||||||
|
- При деградации источников отчеты должны возвращать контролируемый degraded
|
||||||
|
или stale статус, а не зависать.
|
||||||
|
- Оператор может открыть runbook и понять порядок диагностики.
|
||||||
|
|
||||||
|
## Evidence перед запуском пилота
|
||||||
|
|
||||||
|
- Выполнен `scripts/pilot-validation-smoke.mjs`.
|
||||||
|
- Выполнен актуальный smoke портала на целевом стенде.
|
||||||
|
- Проверены скриншоты из `docs/screenshots/`.
|
||||||
|
- Проверены ссылки README и ключевых pilot-документов.
|
||||||
|
- Зафиксированы открытые gaps в `docs/PILOT_GAP_ANALYSIS_RU.md`.
|
||||||
@@ -158,3 +158,60 @@ scripts/pilot-validation-smoke.mjs
|
|||||||
3. Основные риски пилота.
|
3. Основные риски пилота.
|
||||||
4. Конкурентное позиционирование.
|
4. Конкурентное позиционирование.
|
||||||
5. Проверки.
|
5. Проверки.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Выполнение
|
||||||
|
|
||||||
|
Статус: выполнено.
|
||||||
|
|
||||||
|
Созданы документы:
|
||||||
|
|
||||||
|
- `docs/PILOT_VALIDATION_CHECKLIST_RU.md`
|
||||||
|
- `docs/PILOT_GAP_ANALYSIS_RU.md`
|
||||||
|
- `docs/CUSTOMER_DISCOVERY_QUESTIONS_RU.md`
|
||||||
|
- `docs/PILOT_SUCCESS_CRITERIA_RU.md`
|
||||||
|
- `docs/COMPETITIVE_POSITIONING_RU.md`
|
||||||
|
|
||||||
|
Добавлен smoke:
|
||||||
|
|
||||||
|
- `scripts/pilot-validation-smoke.mjs`
|
||||||
|
|
||||||
|
Обновлен README:
|
||||||
|
|
||||||
|
- добавлены ссылки на pilot validation пакет рядом с demo, registry и
|
||||||
|
deployment материалами.
|
||||||
|
|
||||||
|
Выявленные пробелы:
|
||||||
|
|
||||||
|
- нужен live smoke на целевом стенде заказчика;
|
||||||
|
- нужно подтвердить покрытие источников данных и freshness;
|
||||||
|
- нужен контрольный backup and recovery тест;
|
||||||
|
- нужно проверить reverse proxy, TLS, авторизацию и внешнюю доступность портала;
|
||||||
|
- нужно закрепить владельцев действий по Recommended Actions.
|
||||||
|
|
||||||
|
Основные риски пилота:
|
||||||
|
|
||||||
|
- целевой стенд может отличаться от локального demo-стенда;
|
||||||
|
- неполное покрытие источников снизит confidence KPI;
|
||||||
|
- заказчик может ошибочно ожидать DLP/SIEM/EDR, если заранее не проговорить
|
||||||
|
границы пилота;
|
||||||
|
- без владельцев действий управленческие рекомендации останутся отчетом без
|
||||||
|
исполнения.
|
||||||
|
|
||||||
|
Конкурентное позиционирование:
|
||||||
|
|
||||||
|
- AWatch-rus позиционируется как Workforce Analytics + Security Analytics +
|
||||||
|
Forensics;
|
||||||
|
- продукт не заявляется как замена ActivityWatch, Стахановец, StaffCop,
|
||||||
|
SearchInform или InfoWatch;
|
||||||
|
- сравнение сделано честно: зрелые DLP/SIEM/employee monitoring продукты
|
||||||
|
сильнее в глубине политик, сертификации и ширине enterprise-функций;
|
||||||
|
- сильная сторона AWatch-rus в пилоте: explainable KPI, Risk Narrative,
|
||||||
|
role-based сценарии и прозрачные ограничения.
|
||||||
|
|
||||||
|
Проверки:
|
||||||
|
|
||||||
|
- `node --check scripts/pilot-validation-smoke.mjs`
|
||||||
|
- `node scripts/pilot-validation-smoke.mjs`
|
||||||
|
- `git diff --check`
|
||||||
|
|||||||
@@ -0,0 +1,270 @@
|
|||||||
|
#!/usr/bin/env node
|
||||||
|
import fs from "node:fs";
|
||||||
|
import path from "node:path";
|
||||||
|
import process from "node:process";
|
||||||
|
import { fileURLToPath } from "node:url";
|
||||||
|
|
||||||
|
const root = path.resolve(path.dirname(fileURLToPath(import.meta.url)), "..");
|
||||||
|
|
||||||
|
const validationDocs = [
|
||||||
|
"docs/PILOT_VALIDATION_CHECKLIST_RU.md",
|
||||||
|
"docs/PILOT_GAP_ANALYSIS_RU.md",
|
||||||
|
"docs/CUSTOMER_DISCOVERY_QUESTIONS_RU.md",
|
||||||
|
"docs/PILOT_SUCCESS_CRITERIA_RU.md",
|
||||||
|
"docs/COMPETITIVE_POSITIONING_RU.md",
|
||||||
|
];
|
||||||
|
|
||||||
|
const demoDocs = [
|
||||||
|
"docs/PILOT_DEMO_SCENARIO_RU.md",
|
||||||
|
"docs/DEMO_RUNBOOK_RU.md",
|
||||||
|
"docs/DEMO_REPORT_EXAMPLE_RU.md",
|
||||||
|
"docs/PILOT_VALUE_PROPOSITION_RU.md",
|
||||||
|
"docs/demo/DEMO_SCENARIO_EXECUTIVE_RU.md",
|
||||||
|
"docs/demo/DEMO_SCENARIO_SECURITY_RU.md",
|
||||||
|
"docs/demo/DEMO_SCENARIO_FORENSICS_RU.md",
|
||||||
|
"docs/demo/DEMO_PACK_ACCEPTANCE_CHECKLIST_RU.md",
|
||||||
|
"docs/fixtures/pilot-v1-demo/README_RU.md",
|
||||||
|
"docs/fixtures/pilot-v1-demo/demo-seed-data.json",
|
||||||
|
];
|
||||||
|
|
||||||
|
const registryDocs = [
|
||||||
|
"docs/REGISTRY_PRODUCT_PASSPORT_RU.md",
|
||||||
|
"docs/REGISTRY_ARCHITECTURE_RU.md",
|
||||||
|
"docs/REGISTRY_FUNCTIONAL_SCOPE_RU.md",
|
||||||
|
"docs/REGISTRY_DEPENDENCY_STATEMENT_RU.md",
|
||||||
|
"docs/REGISTRY_DEPLOYMENT_MODEL_RU.md",
|
||||||
|
"docs/REGISTRY_COMMERCIAL_POSITIONING_RU.md",
|
||||||
|
"docs/REGISTRY_READINESS_CHECKLIST_RU.md",
|
||||||
|
];
|
||||||
|
|
||||||
|
const deploymentDocs = [
|
||||||
|
"docs/ENTERPRISE_DEPLOYMENT_GUIDE_RU.md",
|
||||||
|
"docs/DEPLOYMENT_TOPOLOGIES_RU.md",
|
||||||
|
"docs/SIZING_GUIDE_RU.md",
|
||||||
|
"docs/BACKUP_AND_RECOVERY_RU.md",
|
||||||
|
"docs/OPERATIONS_RUNBOOK_RU.md",
|
||||||
|
"docs/SECURITY_HARDENING_RU.md",
|
||||||
|
"docs/ENTERPRISE_ACCEPTANCE_CHECKLIST_RU.md",
|
||||||
|
];
|
||||||
|
|
||||||
|
const screenshots = [
|
||||||
|
"docs/screenshots/01-executive-overview.png",
|
||||||
|
"docs/screenshots/02-risk-heatmap.png",
|
||||||
|
"docs/screenshots/03-security-view.png",
|
||||||
|
"docs/screenshots/04-operations-view.png",
|
||||||
|
"docs/screenshots/05-investigation-pack.png",
|
||||||
|
"docs/screenshots/06-markdown-report.png",
|
||||||
|
"docs/screenshots/07-product-architecture.png",
|
||||||
|
];
|
||||||
|
|
||||||
|
const roadmapDocs = [
|
||||||
|
"docs/roadmap/README.md",
|
||||||
|
"docs/roadmap/TASK_001_PILOT_V1_STABILIZATION.md",
|
||||||
|
"docs/roadmap/TASK_002_PRODUCTION_HARDENING.md",
|
||||||
|
"docs/roadmap/TASK_003_EXPLAINABLE_KPI.md",
|
||||||
|
"docs/roadmap/TASK_003A_PORTAL_HARDENING_CLEANUP.md",
|
||||||
|
"docs/roadmap/TASK_004_RISK_NARRATIVE.md",
|
||||||
|
"docs/roadmap/TASK_005_RUST_AGENT_BASELINE.md",
|
||||||
|
"docs/roadmap/TASK_006_EXECUTIVE_ACTION_CENTER.md",
|
||||||
|
"docs/roadmap/TASK_007_CUSTOMER_DEMO_PACK.md",
|
||||||
|
"docs/roadmap/TASK_008_REGISTRY_READINESS.md",
|
||||||
|
"docs/roadmap/TASK_009_ENTERPRISE_DEPLOYMENT_GUIDE.md",
|
||||||
|
"docs/roadmap/TASK_010_PILOT_VALIDATION.md",
|
||||||
|
];
|
||||||
|
|
||||||
|
const reportsAndRunbooks = [
|
||||||
|
"docs/DEMO_REPORT_EXAMPLE_RU.md",
|
||||||
|
"docs/PRODUCTION_INCIDENT_REPORT_2026-06-07_RU.md",
|
||||||
|
"docs/OPERATIONS_RUNBOOK_RU.md",
|
||||||
|
"docs/OPERATIONS_RUNBOOK_WORKTIME_RU.md",
|
||||||
|
"docs/BACKUP_AND_RECOVERY_RU.md",
|
||||||
|
"docs/DEMO_RUNBOOK_RU.md",
|
||||||
|
];
|
||||||
|
|
||||||
|
function readText(file) {
|
||||||
|
return fs.readFileSync(path.join(root, file), "utf8");
|
||||||
|
}
|
||||||
|
|
||||||
|
function exists(file) {
|
||||||
|
return fs.existsSync(path.join(root, file));
|
||||||
|
}
|
||||||
|
|
||||||
|
function checkFiles(files) {
|
||||||
|
return files.filter((file) => !exists(file));
|
||||||
|
}
|
||||||
|
|
||||||
|
function checkScreenshots(files) {
|
||||||
|
const pngSignature = Buffer.from([0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a]);
|
||||||
|
const findings = [];
|
||||||
|
for (const file of files) {
|
||||||
|
const fullPath = path.join(root, file);
|
||||||
|
if (!fs.existsSync(fullPath)) {
|
||||||
|
findings.push({ file, reason: "missing" });
|
||||||
|
continue;
|
||||||
|
}
|
||||||
|
const data = fs.readFileSync(fullPath);
|
||||||
|
if (data.length <= 1000 || !data.subarray(0, 8).equals(pngSignature)) {
|
||||||
|
findings.push({ file, reason: "not_png_or_too_small", size: data.length });
|
||||||
|
}
|
||||||
|
}
|
||||||
|
return findings;
|
||||||
|
}
|
||||||
|
|
||||||
|
function checkMarkdownLinks(files) {
|
||||||
|
const findings = [];
|
||||||
|
const linkPattern = /!?\[[^\]]+\]\(([^)]+)\)/g;
|
||||||
|
for (const file of files) {
|
||||||
|
if (!file.endsWith(".md")) continue;
|
||||||
|
let match = null;
|
||||||
|
const text = readText(file);
|
||||||
|
while ((match = linkPattern.exec(text)) !== null) {
|
||||||
|
const raw = String(match[1] || "").trim();
|
||||||
|
const target = raw.split(/\s+/)[0].replace(/^<|>$/g, "");
|
||||||
|
if (
|
||||||
|
!target
|
||||||
|
|| target.startsWith("#")
|
||||||
|
|| target.startsWith("http://")
|
||||||
|
|| target.startsWith("https://")
|
||||||
|
|| target.startsWith("mailto:")
|
||||||
|
) {
|
||||||
|
continue;
|
||||||
|
}
|
||||||
|
const withoutAnchor = target.split("#", 1)[0];
|
||||||
|
if (!withoutAnchor) continue;
|
||||||
|
const resolved = path.resolve(root, path.dirname(file), withoutAnchor);
|
||||||
|
if (!fs.existsSync(resolved)) {
|
||||||
|
findings.push({ file, target });
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
return findings;
|
||||||
|
}
|
||||||
|
|
||||||
|
function checkRequiredContent() {
|
||||||
|
const checks = [
|
||||||
|
{
|
||||||
|
file: "docs/PILOT_VALIDATION_CHECKLIST_RU.md",
|
||||||
|
markers: ["Executive", "Workforce", "Security", "Forensics", "Agent", "Reporting"],
|
||||||
|
},
|
||||||
|
{
|
||||||
|
file: "docs/PILOT_GAP_ANALYSIS_RU.md",
|
||||||
|
markers: ["Что готово", "Что требует доработки", "Что не входит в пилот", "Что отложено на roadmap"],
|
||||||
|
},
|
||||||
|
{
|
||||||
|
file: "docs/CUSTOMER_DISCOVERY_QUESTIONS_RU.md",
|
||||||
|
markers: ["Директор", "Руководитель подразделения", "ИБ", "ИТ", "Эксплуатация"],
|
||||||
|
},
|
||||||
|
{
|
||||||
|
file: "docs/PILOT_SUCCESS_CRITERIA_RU.md",
|
||||||
|
markers: ["Критерии успеха", "Критерии провала", "KPI пилота", "30 дней"],
|
||||||
|
},
|
||||||
|
{
|
||||||
|
file: "docs/COMPETITIVE_POSITIONING_RU.md",
|
||||||
|
markers: ["ActivityWatch", "Стахановец", "StaffCop", "SearchInform", "InfoWatch"],
|
||||||
|
},
|
||||||
|
];
|
||||||
|
const findings = [];
|
||||||
|
for (const check of checks) {
|
||||||
|
const text = readText(check.file);
|
||||||
|
for (const marker of check.markers) {
|
||||||
|
if (!text.includes(marker)) {
|
||||||
|
findings.push({ file: check.file, marker });
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
return findings;
|
||||||
|
}
|
||||||
|
|
||||||
|
function checkSensitiveStrings(files) {
|
||||||
|
const patterns = [
|
||||||
|
{ name: "private_network_10", re: /10\.10\.10\./ },
|
||||||
|
{ name: "private_network_192", re: /192\.168\./ },
|
||||||
|
{ name: "private_network_172", re: /172\.(1[6-9]|2\d|3[0-1])\./ },
|
||||||
|
{ name: "private_operator_domain", re: /dm\.iri/i },
|
||||||
|
{ name: "customer_codename", re: new RegExp(`${["Det", "Mir"].join("")}|${["SHARKON", "2025"].join("")}`, "i") },
|
||||||
|
{ name: "local_operator_path", re: /\/home\/igor/i },
|
||||||
|
{ name: "mts_phishing_context", re: /\b(lk|l)\.mts\.ru/i },
|
||||||
|
];
|
||||||
|
const findings = [];
|
||||||
|
for (const file of files) {
|
||||||
|
if (!file.endsWith(".md") && !file.endsWith(".json")) continue;
|
||||||
|
const text = readText(file);
|
||||||
|
for (const pattern of patterns) {
|
||||||
|
if (pattern.re.test(text)) {
|
||||||
|
findings.push({ file, pattern: pattern.name });
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
return findings;
|
||||||
|
}
|
||||||
|
|
||||||
|
function pass(checks, name, ok, details = {}) {
|
||||||
|
checks.push({ name, ok: Boolean(ok), ...details });
|
||||||
|
}
|
||||||
|
|
||||||
|
function main() {
|
||||||
|
const checks = [];
|
||||||
|
const docsToScan = [
|
||||||
|
"README.md",
|
||||||
|
...validationDocs,
|
||||||
|
...demoDocs,
|
||||||
|
...registryDocs,
|
||||||
|
...deploymentDocs,
|
||||||
|
...roadmapDocs,
|
||||||
|
...reportsAndRunbooks,
|
||||||
|
];
|
||||||
|
const sensitiveScanFiles = [
|
||||||
|
...validationDocs,
|
||||||
|
"docs/fixtures/pilot-v1-demo/README_RU.md",
|
||||||
|
"docs/fixtures/pilot-v1-demo/demo-seed-data.json",
|
||||||
|
];
|
||||||
|
|
||||||
|
pass(checks, "validation_docs_exist", checkFiles(validationDocs).length === 0, {
|
||||||
|
missing: checkFiles(validationDocs),
|
||||||
|
});
|
||||||
|
pass(checks, "demo_docs_exist", checkFiles(demoDocs).length === 0, {
|
||||||
|
missing: checkFiles(demoDocs),
|
||||||
|
});
|
||||||
|
pass(checks, "registry_docs_exist", checkFiles(registryDocs).length === 0, {
|
||||||
|
missing: checkFiles(registryDocs),
|
||||||
|
});
|
||||||
|
pass(checks, "deployment_docs_exist", checkFiles(deploymentDocs).length === 0, {
|
||||||
|
missing: checkFiles(deploymentDocs),
|
||||||
|
});
|
||||||
|
pass(checks, "roadmap_exists", checkFiles(roadmapDocs).length === 0, {
|
||||||
|
missing: checkFiles(roadmapDocs),
|
||||||
|
});
|
||||||
|
pass(checks, "reports_and_runbooks_exist", checkFiles(reportsAndRunbooks).length === 0, {
|
||||||
|
missing: checkFiles(reportsAndRunbooks),
|
||||||
|
});
|
||||||
|
|
||||||
|
const screenshotFindings = checkScreenshots(screenshots);
|
||||||
|
pass(checks, "screenshots_exist_and_are_png", screenshotFindings.length === 0, {
|
||||||
|
findings: screenshotFindings,
|
||||||
|
});
|
||||||
|
|
||||||
|
const requiredContentFindings = checkRequiredContent();
|
||||||
|
pass(checks, "validation_docs_have_required_sections", requiredContentFindings.length === 0, {
|
||||||
|
findings: requiredContentFindings,
|
||||||
|
});
|
||||||
|
|
||||||
|
const linkFindings = checkMarkdownLinks(docsToScan);
|
||||||
|
pass(checks, "markdown_links_valid", linkFindings.length === 0, {
|
||||||
|
findings: linkFindings,
|
||||||
|
});
|
||||||
|
|
||||||
|
const sensitiveFindings = checkSensitiveStrings(sensitiveScanFiles);
|
||||||
|
pass(checks, "sensitive_string_scan", sensitiveFindings.length === 0, {
|
||||||
|
findings: sensitiveFindings,
|
||||||
|
});
|
||||||
|
|
||||||
|
const ok = checks.every((check) => check.ok);
|
||||||
|
process.stdout.write(`${JSON.stringify({
|
||||||
|
ok,
|
||||||
|
generated_at_utc: new Date().toISOString(),
|
||||||
|
checks,
|
||||||
|
}, null, 2)}\n`);
|
||||||
|
process.exitCode = ok ? 0 : 2;
|
||||||
|
}
|
||||||
|
|
||||||
|
main();
|
||||||
Reference in New Issue
Block a user