CodeGraph сочетает анализ кода и управляемую поставку. Security posture зависит от профиля развёртывания, настроенных провайдеров, identity и network controls заказчика и доказательств точной ревизии. Обзор связывает assurance questions с сопровождаемыми источниками. Сертификат и результат penetration test оформляются отдельными процедурами.
Границы доверия
В дизайне заказчика выделите как минимум:
- пользователей, service accounts, агентов и их клиентские интерфейсы;
- API, MCP, ACP, gRPC, dashboard и CLI;
- PostgreSQL, OpenViking, GoCPG, project files и generated evidence;
- model и repository providers, issue systems, SIEM и webhooks;
- ingress, egress, TLS, secrets, backups и административный доступ заказчика.
Authorization вычисляется для интерфейса и project scope. Идентификатор, имя инструмента или роль цифрового сотрудника сами по себе не дают доступ.
Identity и authorization
OAuth и LDAP описывает внешнюю authentication, проверку state, доступность каталога, mapping ролей и deprovisioning. RBAC — подробный источник по текущим ролям, permissions, API keys, service accounts, scopes, project access и webhook authorization.
Количество permissions и routes здесь намеренно не повторяется. При оценке сверяйте установленный enum, live OpenAPI и effective policy.
Данные и egress модели
DLP задаёт действия pre-request и post-response scanning и их ограничения. Безопасность LLM показывает, какие system prompt и user prompt могут уйти выбранному провайдеру после фильтрации. Ни один control не делает внешнюю обработку «локальной»: provider, network, retention, training, logging и jurisdiction остаются частью решения.
Не помещайте секреты в prompts, logs, закоммиченную конфигурацию, fixtures и публичную документацию. Применяйте classification и retention заказчика к отчётам и evidence.
События безопасности и аудит
Интеграция SIEM описывает форматы событий, configured handlers, buffering, dispatch status и downstream receipt. Application audit records и SIEM delivery решают разные задачи. Indexing получателем подтверждается downstream receipt и записью в SIEM.
Определите для пилота обязательные event types, severity mapping, retention, receiver owner, alert routing, delivery SLO, degraded-mode policy и reconciliation procedure.
Развёртывание и эксплуатация
Руководство по развёртыванию связывает профили с сопровождаемыми Compose, Helm, bare-metal и runbook-артефактами. Оно требует immutable release identity, health, secret и network controls, observability, backup, restore, rollback и recovery evidence.
Платформенные объекты, которых нет в сопровождаемом chart, остаются ответственностью заказчика. Размер среды определяйте по корпусу пилота и измеренному SLO, а не по общей таблице capacity.
Управляемая поставка
Product requirements, task capsules, ответственные evidence lanes, human approvals, traceability, runtime readiness и financial reconciliation определяют приёмку изменений. Unit tests или один static scan сами по себе не разрешают production status.
Human approval действует только для подписанного перехода и scope. Generated status pages и repository projections рекомендательны, если устарели, ожидают синхронизации или не привязаны к точной ревизии.
Какие доказательства запросить
Для пилота или RFP запросите доказательства реального профиля:
- threat model и data-flow diagram с границами providers и storage;
- тесты identity, RBAC, service account, session и deprovisioning;
- DLP positive, negative, masking и provider-call evidence;
- secret, dependency, source и publication scans неизменяемого релиза;
- SIEM dispatch, buffer, downstream receipt и alert recovery;
- installation, health, representative workflow, backup, restore и rollback;
- известные ограничения, недоступные controls, compensating measures, owners и expiry;
- revision-bound closure QA, AppSec, traceability, docs, support, runtime и cost.
В evidence должны быть указаны предмет и место теста, ревизия и конфигурация, исполнитель, результат и оставшийся gap.
Ограничения
Security behavior меняется вместе с конфигурацией, topology, identity provider, model и repository providers, включёнными интерфейсами и операциями заказчика. После таких изменений повторяйте нужные проверки. Для regulatory mapping используйте соответствующий control-specific документ и профессиональную оценку, а не вывод о compliance из этого обзора.