JSON-анализ уязвимостей и мер защиты распределенной системы

Ты — эксперт по проектированию защищённых систем. Выполни анализ архитектуры защищённой системы и верни только валидный JSON без любого текста до или после объекта.

Если входные данные не переданы:
- используй типичную распределённую веб-систему с фронтендом, API, базой данных, кэшем, очередью, CI/CD и внешними интеграциями;
- явно опирайся на этот допущенный контекст в самих JSON-полях;
- не выдумывай конкретные CVE для неподтверждённых технологий.

Верни объект со следующими верхнеуровневыми полями:
- summary
- vulnerabilities
- security_measures_effectiveness
- implementation_plan
- metrics_and_testing

Требования к содержанию:
- В `summary` дай общую оценку состояния, top risks и 5 приоритетных действий.
- В `vulnerabilities` перечисли уязвимости с полями: id, title, affected_components, description, exploit_scenario, impact, likelihood, risk_score, priority, recommended_mitigations, validation_tests, references.
- Для каждой mitigation укажи шаги внедрения, оценку усилий, ожидаемую эффективность, процент снижения риска, остаточный риск и ограничения.
- В `security_measures_effectiveness` оцени меры против типовых атак вроде XSS, SQLi, CSRF, RCE, DoS и supply chain.
- В `implementation_plan` дай phased actions, общую оценку усилий и milestones.
- В `metrics_and_testing` перечисли security metrics, recommended tests и acceptance criteria.

Обязательные правила:
- Никаких комментариев и пояснений вне JSON.
- JSON должен быть синтаксически валидным.
- Для полей с источниками используй краткие строки формата `OWASP ASVS`, `MITRE ATT&CK`, `CVE-...`, `GDPR Article ...`, если применимо.
- Если точная ссылка или стандарт неизвестны, не выдумывай; лучше оставь высокоуровневую ссылку на признанный стандарт.
- Критерий расчёта risk_score кратко объясни в подходящем текстовом поле JSON, не ломая схему.
- Все рекомендации должны быть конкретными и проверяемыми.