CodeGraph combines code intelligence with governed delivery. Its security posture depends on the selected deployment profile, configured providers, customer identity and network controls, and revision-bound evidence. This brief maps assurance questions to maintained sources; it is not a certification, penetration-test result, or unconditional guarantee.
Trust boundaries
Identify at least these boundaries in the customer design:
- users, service accounts, agents, and their client interfaces;
- API, MCP, ACP, gRPC, dashboard, and CLI entry points;
- PostgreSQL, OpenViking, GoCPG, project files, and generated evidence;
- model providers, repository providers, issue systems, SIEM, and webhooks;
- customer ingress, egress, TLS, secrets, backups, and administrative access.
Authorization is evaluated at an interface and project scope. The server grants access after it matches the authenticated principal to the requested identifier, tool, and project scope.
Identity and authorization
OAuth and LDAP describes external authentication, state validation, directory availability, role mapping, and deprovisioning. RBAC is the detailed source for current roles, permissions, API keys, service accounts, scopes, project access, and webhook authorization.
Counts of permissions and routes are intentionally not duplicated here. Verify the installed enum, live OpenAPI, and effective policy during assessment.
Data and model egress
DLP defines pre-request and post-response scanning actions and their limits. LLM security identifies which system and user prompt data can reach the selected provider after filtering. Neither control makes external processing “local”; provider, network, retention, training, logging, and jurisdiction terms remain part of the deployment decision.
Keep secrets out of prompts, logs, configuration committed to source, fixtures, and public documentation. Apply customer classification and retention rules to generated reports and evidence.
Security events and audit
SIEM integration covers event formats, configured handlers, buffering, dispatch status, and downstream receipt. Application audit records and SIEM delivery serve different purposes. An accepted or enqueued event records local delivery state; verify receiver-side indexing in the SIEM.
Define required event types, severity mapping, retention, receiver ownership, alert routing, delivery SLO, degraded-mode policy, and reconciliation procedure for the pilot.
Deployment and operations
Deployment guidance binds supported profiles to maintained Compose, Helm, bare-metal, and runbook artifacts. It requires immutable release identity, health, secret and network controls, observability, backup, restore, rollback, and recovery evidence.
Platform objects not shipped in the maintained chart remain the customer’s responsibility. Size the environment from the pilot corpus and measured SLOs rather than generic capacity claims.
Governed delivery
Product requirements, task capsules, accountable evidence lanes, human approvals, traceability, runtime readiness, and financial reconciliation control how changes are accepted and promoted. Unit tests and static scans contribute evidence to the production-status decision.
Human approval applies only to the signed transition and scope it names. Generated status pages and repository projections are advisory when stale, pending, or not bound to the exact revision.
Evidence to request
For a pilot or RFP, request evidence appropriate to the actual profile:
- threat model and data-flow diagram with provider and storage boundaries;
- identity, RBAC, service-account, session, and deprovisioning tests;
- DLP positive, negative, masking, and provider-call evidence;
- secret, dependency, source, and publication scans for the immutable release;
- SIEM dispatch, buffer, downstream receipt, and alert-recovery evidence;
- installation, health, representative workflow, backup, restore, and rollback results;
- known limitations, unavailable controls, compensating measures, owners, and expiry;
- revision-bound QA, AppSec, traceability, documentation, support, runtime, and cost closure.
Evidence should state what was tested, where, against which revision and configuration, by whom, with what result and remaining gap.
Limitations
Security behavior changes with configuration, deployment topology, identity provider, model and repository providers, enabled interfaces, and customer operations. Re-run relevant checks after those inputs change. For regulatory mapping, use the applicable control-specific document and professional assessment rather than inferring compliance from this brief.