CodeGraph — техническое описание
Единый контур понимания и верификации кода для корпоративной разработки, релизного контроля и аудита
1. Аннотация
Сдвиг рынка: ИИ ускорил написание кода, но не решил три главные проблемы корпоративной разработки: как удерживать живой контекст изменений, как передавать одну и ту же цепочку доказательств между людьми и инструментами и как не допускать устаревшую память в принятие решений.
Решение: CodeGraph объединяет граф кода, проектную память и контур управления сессиями в единый механизм понимания, проверки и совместной работы по проекту.
Результат: 95.6% точность на бенчмарке из 160 вопросов, ускорение анализа кода в 10–600 раз, явный контекст сессии для командной работы, передача одной и той же ИИ-сессии между разработчиком, тестировщиком и ревьюером, а также безопасная работа с памятью проекта по состояниям «актуально», «требует проверки» и «устарело».
2. Проблема
Корпоративная разработка упирается не в скорость написания нового кода, а в скорость понимания последствий изменений. Это ведёт к перегрузке ведущих инженеров, шуму в безопасности, недоверию к релизам и дорогому ручному аудиту.
| Проблема | Масштаб | Источник |
|---|---|---|
| Разработчики тратят 60% времени на понимание существующего кода | 90,000 разработчиков | Исследование GitHub, 2023 |
| Ручная проверка кода пропускает до 80% уязвимостей | 100+ корпоративных проектов | Отчёт NIST |
| Онбординг новых сотрудников занимает 3-6 месяцев | Отраслевой стандарт | Опросы CTO |
| Документация устаревает за 2-4 недели | 500+ команд | Опрос разработчиков |
| Аудит безопасности занимает 2-4 недели вручную | Корпоративные проекты | Отраслевой бенчмарк |
Стоимость проблемы
Для команды из 50 разработчиков со средней зарплатой 200,000 руб./мес потери составляют:
- 60 млн руб./год — время на понимание кода (60% × 50 × 200K × 12)
- Неизмеримые риски — пропущенные уязвимости, утечки данных
- Замедление вывода продукта — отложенные релизы из-за долгой проверки кода
3. Предпосылки: почему традиционные подходы не работают
Существующие инструменты анализа кода имеют фундаментальные ограничения:
Текстовый поиск (`grep`, поиск в IDE)
- Проблема: Нет понимания семантики — ищет только точные совпадения строк
- Пример: Поиск SQL-инъекций не найдёт уязвимости с параметризованными запросами
- Результат: Низкая полнота, много пропущенных угроз
Статический анализ (SonarQube, CodeQL)
- Проблема: Требует предопределённых правил, не понимает намерение пользователя
- Пример: Нельзя спросить «какие функции обрабатывают пользовательский ввод?»
- Результат: Много ложных срабатываний, нет интерактивности
Генеративные помощники (ChatGPT, Copilot)
- Проблема: Ускоряют генерацию, но не дают воспроизводимых доказательств по коду и зависимостям всей системы
- Пример: Не видят полный граф вызовов, реальные потоки данных и архитектурные ограничения на уровне большого корпоративного проекта
- Результат: Ответ может выглядеть убедительно, но его нельзя положить в основу релизного решения или аудита без детерминированной проверки
Вывод: Нужен не ещё один генератор кода, а единый контур, который связывает структуру кодовой базы, проверку изменений, безопасность, соответствие требованиям и управленческие решения.
4. Методология: граф свойств кода, гибридный поиск и воспроизводимые проверки
CodeGraph объединяет три слоя: детерминированное представление кодовой базы, гибридный поиск по смыслу и структуре и сценарии, которые превращают результат анализа в релизные и аудиторские решения.
4.1 Граф свойств кода (CPG)
CPG — это унифицированное представление кода, генерируемое собственным инструментом GoCPG (Go + Tree-sitter, 33 аналитических прохода). CPG объединяет:
- AST (абстрактное синтаксическое дерево) — синтаксическая структура
- CFG (граф потока управления) — поток управления
- PDG (граф зависимостей программы) — зависимости данных и управления
- DDG (граф зависимостей данных) — чистые зависимости данных
- Граф вызовов — связи между функциями
4.2 Гибридный поиск и контур памяти
После интеграции OpenViking, поиск в CodeGraph перестал быть просто комбинацией графа и векторов. Теперь система работает в трёх взаимосвязанных слоях: слой структуры кода отвечает за детерминированные факты, слой проектной памяти хранит живой контекст, а слой управления контролирует доступ, состояние сессий и жизненный цикл знаний.
| Плоскость | Что хранит | Зачем нужна |
|---|---|---|
| Слой структуры кода | CPG, связи вызовов, потоки данных, зависимости | Даёт детерминированный ответ о фактах кодовой базы и последствиях изменений |
| Слой проектной памяти | Проектные ресурсы, навыки, память сессий, использованный контекст | Даёт живой контекст проекта и переносимую память между задачами, людьми и инструментами |
| Слой управления | Владельцы сессий, участники, жизненный цикл знаний, аудит передачи | Защищает от несанкционированного использования и от устаревших данных в контексте и ответах ИИ |
4.3 Управление сессией и памятью проекта
Вместо неявного контекста в промпте CodeGraph использует явный контекст сессии. Сессия может быть открыта, переоткрыта, передана ревьюеру или тестировщику, закрыта или архивирована, оставаясь привязанной к одному и тому же проекту и одной и той же цепочке доказательств.
| Операция | Что получает пользователь | Что контролирует платформа |
|---|---|---|
| Открытие и продолжение | Продолжение той же цепочки доказательств в OpenCode, MCP или REST | Владельца, режим доступа и границы проекта |
| Совместная работа и передача | Передача одной ИИ-сессии ревьюеру, тестировщику или другому ИИ-агенту | Доступ только для чтения, смену владельца и аудит передачи |
| Сохранение памяти | Сохранение полезного контекста без блокирования процесса разработки | Фоновую фиксацию, устранение дублей, происхождение знания и его состояние |
| Фильтрация знаний | Ответы без вредного устаревшего контекста | Использование только актуальных знаний по умолчанию, предупреждения и исключение устаревших записей |
4.4 Покрытие уязвимостей CWE/CAPEC
Модуль безопасности обнаруживает 58 типов уязвимостей CWE и связывает их с 27 паттернами атак CAPEC:
| Категория | CWE | Примеры |
|---|---|---|
| Инъекции | 11 | SQL (CWE-89), Command (CWE-78), LDAP (CWE-90), Code (CWE-94/95), Format String (CWE-134), SpEL (CWE-917), Template (CWE-1336), NoSQL (CWE-943), File Include (CWE-98) |
| Память | 9 | Buffer Overflow (CWE-120/119/787/125), Use-After-Free (CWE-416), Double Free (CWE-415), Null Deref (CWE-476), String Termination (CWE-170), Stack Return (CWE-562) |
| Валидация ввода | 6 | Path Traversal (CWE-22), Deserialization (CWE-502), SSRF (CWE-918), Open Redirect (CWE-601), Info Exposure (CWE-200/209) |
| Криптография | 8 | Weak Crypto (CWE-327/328), Weak PRNG (CWE-330/338), Bad Certificate (CWE-295), Cleartext (CWE-319), Weak PBE (CWE-916), Predictable IV (CWE-329) |
| Доступ и авторизация | 6 | Hardcoded Credentials (CWE-798), Missing Auth (CWE-862), Broken Access Control (CWE-284), Privilege Escalation (CWE-250), IDOR (CWE-639), Exposed API (CWE-749) |
| Веб-приложения | 4 | XSS (CWE-79), CSRF (CWE-352), Prototype Pollution (CWE-1321), XXE (CWE-611) |
| Многопоточность | 2 | Race Condition (CWE-362), TOCTOU (CWE-367) |
| Управление ресурсами | 8 | Dangerous Function (CWE-242), Unchecked Return (CWE-252), Temp File (CWE-377), DoS (CWE-400), Resource Leak (CWE-404), ReDoS (CWE-1333), Input Diff (CWE-183/1025) |
| Целочисленные ошибки | 3 | Integer Overflow (CWE-190), Integer Underflow (CWE-191), Truncation (CWE-197) |
| Журналирование | 2 | Log Injection (CWE-117), Insufficient Logging (CWE-778) |
| Итого | 58 | + языковые правила: Python/Django, JavaScript, TypeScript, Java, Go, C#, Kotlin, PHP, 1С:Предприятие (190 YAML-правил) |
Паттерны атак CAPEC
Система связывает уязвимости CWE с реальными паттернами атак CAPEC для приоритизации:
| CAPEC ID | Атака | Связанные CWE |
|---|---|---|
| CAPEC-66 | SQL Injection | CWE-89 |
| CAPEC-88 | OS Command Injection | CWE-78 |
| CAPEC-86 | XSS через HTTP Headers | CWE-79 |
| CAPEC-100 | Buffer Overflow | CWE-120 |
| CAPEC-126 | Path Traversal | CWE-22 |
| CAPEC-586 | Object Injection (Deserialization) | CWE-502 |
| CAPEC-664 | Server-Side Request Forgery | CWE-918 |
| CAPEC-201 | XML External Entity (XXE) | CWE-611 |
| CAPEC-136 | LDAP Injection | CWE-90 |
| CAPEC-97 | Cryptanalysis | CWE-327, CWE-328 |
| CAPEC-112 | Brute Force (Weak PRNG) | CWE-330, CWE-338 |
| CAPEC-94 | Man-in-the-Middle | CWE-295, CWE-319 |
| CAPEC-268 | Audit Log Manipulation | CWE-117 |
| CAPEC-492 | Regular Expression DoS (ReDoS) | CWE-1333 |
И ещё 13 паттернов CAPEC для race conditions, криптографических атак, форматных строк, privilege escalation и др.
5. Техническая архитектура
5.1 Архитектура по плоскостям
CodeGraph больше не описывается как один RAG-конвейер. Целевая архитектура разделяет структурное знание о коде, живую память проекта и контур управления, а затем собирает из этого единый контракт для агентов и пользователей.
5.2 Контур жизненного цикла сессии и памяти
Критическое отличие новой архитектуры в том, что память проекта больше не живёт как неформальный побочный эффект. У неё есть владелец, режим доступа, происхождение и состояние, поэтому одна и та же ИИ-сессия может переходить между разработчиком, ревьюером и тестировщиком внутри одного проекта.
| Слой | Основное хранилище | Роль |
|---|---|---|
| Сессии, участники, передача | PostgreSQL | Открытие, список, метаданные, совместная работа, принятие или отклонение передачи, закрытие, архив |
| Проектная память и ресурсы | OpenViking | Хранение ресурсов, навыков, памяти сессий и фоновое сохранение |
| Жизненный цикл знаний | PostgreSQL + слой правил | Состояния «актуально», «требует проверки», «устарело» и безопасные правила поиска |
| Локальный технический кэш | SQLite | Устранение дублей, восстановление незавершённого сохранения и локальное состояние |
5.3 Поддерживаемые LLM-провайдеры
CodeGraph поддерживает 4 LLM-провайдера с единым интерфейсом:
| Провайдер | Модели | Контекст | Особенности |
|---|---|---|---|
| GigaChat (Сбер) | GigaChat-2, -Pro, -Max | 128K | Российский провайдер, соответствие требованиям |
| Яндекс AI Studio | Qwen3-235B, gpt-oss-120b, YandexGPT | до 256K | Большой контекст, совместимость с OpenAI API |
| OpenAI | GPT-5.4 | 400K - 1M | Международный стандарт |
| Локальный | Qwen3-Coder-Next, GLM 5, DeepSeek | до 256K | Автономная работа, изолированная среда |
5.4 Поддерживаемые языки программирования
GoCPG анализирует код на 11 языках через Tree-sitter парсеры:
| Категория | Языки | Расширения |
|---|---|---|
| Системные | C, C++ | .c, .h, .cpp, .hpp, .cc, .cxx |
| Корпоративные | Java, C#, Kotlin | .java, .cs, .kt, .kts |
| Веб | JavaScript, TypeScript, PHP | .js, .ts, .jsx, .tsx, .php |
| Скриптовые | Python, Go | .py, .go |
| Отечественные | 1С:Предприятие | .bsl, .os |
5.5 Технологический стек
| Компонент | Технология | Описание |
|---|---|---|
| Серверная часть | Python 3.11+ / FastAPI | 130+ REST-эндпоинтов, WebSocket. Мультитенантность: RBAC (4 роли, 21 разрешение), изоляция проектов по группам |
| Парсер CPG | GoCPG (Go + Tree-sitter) | 11 языков, 33 аналитических прохода, gRPC API (mTLS, Prometheus), ускорение в 30–60 раз по сравнению с Joern |
| Графовая БД | DuckDB | Хранение графа свойств кода, исполнение SQL/PGQ-запросов и графовых алгоритмов через расширение DuckPGQ |
| Контекстная плоскость | OpenViking | Ресурсы, подготовленные навыки, память сессий, фоновое сохранение и явные операции поиска, просмотра и чтения для внешних агентов |
| Слой управления | PostgreSQL | Основной жизненный цикл сессий, смена владельца, аудит и правила поиска с учётом состояния знаний |
| Технический кэш | SQLite | Локальный технический кэш для возврата в сессию, устранения дублей и восстановления |
| Оркестрация | LangGraph | Сценарная координация, правила маршрутизации, сигнал готовности контекста и многошаговые рабочие процессы |
| Интерфейсы | 6 точек входа | REST API, WebSocket, CLI (40+ команд), MCP (stdio/SSE/HTTP), ACP (Zed, JetBrains, VS Code), OpenCode (агент + команды) |
6. Сценарии использования
CodeGraph предоставляет 21 готовый сценарий для типичных задач разработки. После интеграции OpenViking появился новый класс сценариев: непрерывная работа с одной сессией, управление знаниями проекта и передача контекста между разными людьми и инструментами внутри одного проекта.
6.1 Новые сценарии совместной работы
| Новый сценарий | Что стало возможно | Покрытие в платформе |
|---|---|---|
| Совместная сессия ревью | Разработчик передаёт ревьюеру ту же ИИ-сессию с уже собранным контекстом и цепочкой доказательств | Доступ только для чтения, список и метаданные, повторное открытие в OpenCode, MCP и REST |
| Передача в тестирование | Тестировщик принимает владение и продолжает ту же сессию после разработки | Принятие или отклонение передачи, аудит и смена владельца |
| Возврат после паузы | Команда продолжает разбор задачи после сжатия истории, смены исполнителя или инструмента | Запомненное состояние сессии, явный возврат и контроль статуса сохранения |
| Управляемая память проекта | Устаревшие знания не попадают в ответы по умолчанию и не отравляют контекст | Метаданные жизненного цикла, перевод в состояние «требует проверки» и исключение устаревших записей |
6.2 Базовый каталог сценариев
| # | Сценарий | Описание | Пример запроса |
|---|---|---|---|
| 1 | Онбординг в кодовую базу | Навигация по кодовой базе для новых разработчиков | "Объясни архитектуру проекта" |
| 2 | Аудит безопасности | Комплексный аудит безопасности с анализом потоков данных | "Найди все SQL инъекции" |
| 3 | Генерация документации | Автоматическая генерация технической документации | "Сгенерируй документацию по API" |
| 4 | Разработка функционала | Поддержка разработки новых функций (навигация по зависимостям) | "Где добавить новую точку входа?" |
| 5 | Рефакторинг | Рекомендации по рефакторингу с анализом влияния изменений | "Найди неиспользуемые функции" |
| 6 | Анализ производительности | Выявление узких мест производительности | "Найди N+1 запросы к БД" |
| 7 | Покрытие тестами | Анализ тестового покрытия и рекомендации по тестам | "Какие функции не покрыты тестами?" |
| 8 | Проверка соответствия | Проверка соответствия 152-ФЗ, ГОСТ Р 56939, OWASP | "Проверь на соответствие OWASP Top 10" |
| 9 | Обзор кода | Автоматизированный обзор изменений в запросах на слияние | "Проверь этот PR на проблемы" |
| 10 | Кросс-репозиторный анализ | Анализ межмодульных зависимостей | "Найди дублирующийся код между репо A и B" |
| 11 | Анализ архитектуры | Выявление нарушений архитектурных ограничений | "Найди циклические зависимости" |
| 12 | Оценка технического долга | Количественная оценка технического долга | "Оцени технический долг модуля" |
| 13 | Массовый рефакторинг | Автоматизация массового рефакторинга (миграции API) | "План миграции с API v1 на API v2" |
| 14 | Реагирование на инциденты ИБ | Реагирование на инциденты ИБ с рекомендациями | "Проанализируй CVE-2024-XXXX" |
| 15 | Поддержка отладки | Помощь в отладке на основе потоков данных | "Найди все места с elog(ERROR)" |
| 16 | Точки входа и поверхность атаки | Анализ поверхности атак и точек входа | "Какие функции принимают пользовательский ввод?" |
| 17 | Редактирование файлов | Точечное редактирование кода на основе AST | "Переименуй функцию X в Y во всех файлах" |
| 18 | Оптимизация кода | Комплексная оптимизация: безопасность, рефакторинг, архитектура | "Оптимизируй модуль авторизации" |
| 19 | Проверка по стандартам | Проверка кода по эталонным стандартам и руководствам | "Проверь код на соответствие стандартам проекта" |
| 20 | Анализ зависимостей | Анализ зависимостей и импортов | "Покажи дерево зависимостей модуля" |
| 21 | Структурный поиск паттернов | Поиск по структурным шаблонам с CPG-ограничениями | "Найди все функции с цикломатической сложностью >20" |
7. Результаты и бенчмарки
7.1 Производительность системы
| Метрика | Значение | Комментарий |
|---|---|---|
| Сквозное время ответа | от 30 мс до 71 с | 30 мс для сценариев соответствия — до 71 с для реагирования на инциденты, в зависимости от сценария |
| GoCPG парсинг | ускорение в 30–60 раз | По сравнению с Joern через Appender API |
| Пропускная способность | 50+ запросов/с | 100+ параллельных пользователей |
| Память на экземпляр | < 4 ГБ | Нативный бинарник GoCPG без JVM |
7.2 Качество анализа
Комплексный бенчмарк на 160 вопросах по 21 сценарию, с двуязычным эталонным набором ответов (RU/EN), на кодовой базе PostgreSQL 17 (~1 млн строк на C):
| Метрика | Значение | Комментарий |
|---|---|---|
| Общая точность | 95.6% | 153 из 160 вопросов |
| Сценарии с точностью ≥80% | 16 из 16 | Все протестированные сценарии |
| MRR (средняя обратная ранговая позиция) | 0.83 | Диапазон 0.58–0.95 |
| Полнота@10 | 0.78 | Диапазон 0.44–0.97 |
Метрики CPG: GoCPG и Joern
| Метрика | GoCPG | Joern | Коэффициент |
|---|---|---|---|
| Узлы CPG | 1 419 954 | 1 804 013 | 0.79x (компактнее) |
| Рёбра CPG | 15 598 692 | 18 340 154 | 0.85x (компактнее) |
| Методы | 47 335 | 27 825 | 1.70x (больше) |
7.3 Квалификационный бенчмарк ГОСТ Р 71207-2024
23 марта 2026 года тестовый корпус для статических анализаторов кода разработанный ИСП РАН sa-tests-db был проверен на актуальной версии CodeGraph отдельно для каждого языка. Критерий соответствия: для каждого типа ошибок по отдельности требуется FP < 50% и FN < 50%. Сводные значения FP/FN в таблице ниже приведены только для ориентира. В текущем снимке корпуса представлены языки C/C++, C#, Go, Java, JavaScript и Python.
| Язык | Тестов | Сводный FP/FN | Статус |
|---|---|---|---|
| C/С++ | 11 511 | 44.07% / 29.82% | Пройден |
| C# | 15 155 | 37.65% / 41.54% | Пройден |
| Java | 21 429 | 45.90% / 29.95% | Пройден |
| Go | 7 123 | 38.44% / 26.75% | Пройден |
| JavaScript | 84 | 35.56% / 30.95% | Пройден |
| Python | 747 | 41.83% / 35.76% | Пройден |
Отдельно 23 марта 2026 года был проверен специализированный корпус 1c-tests. Проверка выполнялась базовым запуском gocpg parse/scan, без дополнительных метаданных в оценщике.
| Корпус 1C | Кейсов | Результат | Категорий правил | FP/FN по категориям |
|---|---|---|---|---|
| core | 24 | 24/24 | 12 | 0.0% / 0.0% |
| experimental | 7 | 7/7 | 3 | 0.0% / 0.0% |
| Итого | 31 | 31/31 | 15 | 0.0% / 0.0% |
Примечание: 1c-tests пока остаётся внутренним тестовым набором. Часть кейсов в манифесте помечена как черновая или экспериментальная, поэтому эти цифры показывают соответствие текущему эталонному набору, а не результаты внешней сертификационной проверки.
7.4 Бизнес-эффект
Измеримые результаты внедрения CodeGraph:
| Сценарий | Без CodeGraph | С CodeGraph | Ускорение |
|---|---|---|---|
| Онбординг разработчика | 3-6 месяцев | 2-4 недели | в 6 раз |
| Аудит безопасности | 2-4 недели | 2-4 часа | в 40 раз |
| Обзор кода при изменениях | 2-4 часа | 10-15 минут | в 15 раз |
| Поиск функции в коде | 5-30 минут | 2-3 секунды | в 600 раз |
| Генерация документации | 1-2 дня | 5 минут | в 200 раз |
Экономический эффект для команды из 50 разработчиков: экономия около 60 млн руб. в год на понимании кода (60% → 10% времени) и снижение рисков безопасности за счёт автоматического аудита.
8. Команда
CodeGraph разрабатывается командой с опытом в области:
- Статический анализ кода — собственный CPG-генератор GoCPG, опыт работы с CodeQL, Semgrep
- Машинное обучение — обработка естественного языка, векторные представления, дообучение LLM
- Корпоративная разработка — масштабируемые системы, высокие нагрузки
- Информационная безопасность — статический и динамический анализ, фаззинг, нормативные требования и стандарты
Контакт: Для обсуждения технических деталей или партнёрства свяжитесь с нами через форму на главной странице или напишите на hello@codegraph.ru
9. Заключение
CodeGraph решает фундаментальную проблему корпоративной разработки: как ускорять поставку изменений, не теряя структурное понимание кодовой базы, управляемую память проекта и контроль над тем, кто именно продолжает ту же ИИ-сессию дальше.
- Слой структуры кода на базе GoCPG и DuckDB даёт детерминированные факты о коде, зависимостях и последствиях изменений.
- Слой проектной памяти на базе OpenViking превращает документацию, подготовленные навыки и память сессий в управляемый проектный контекст.
- Слой управления на базе PostgreSQL делает память и сессии пригодными для корпоративной работы: владелец, совместный доступ, передача, аудит, фильтрация знаний.
- Совместные ИИ-сценарии позволяют одной цепочке доказательств переходить между разработчиком, ревьюером, тестировщиком и разными инструментами, оставаясь в рамках того же проекта.
Итог платформы в текущем состоянии:
- 95.6% точность на бенчмарке из 160 вопросов (153/160).
- 21 готовый сценарий плюс новый слой совместных рабочих процессов.
- 6 специализированных дашбордов на уровне проекта и сравнительный анализ портфеля проектов.
- 3 состояния знания для защиты от устаревшей памяти: «актуально», «требует проверки», «устарело».
Подробнее по направлениям
Безопасность
Межпроцедурный анализ потоков данных, доля ложных срабатываний 12%, интеграция с SIEM, экспорт в SARIF 2.1.0.
Продуктивность
Онбординг быстрее в 6 раз, поиск быстрее в 600 раз, экономический эффект более 60 млн руб. в год для команды из 50 человек.
Соответствие
152-ФЗ, ГОСТ Р 56939, DLP-защита исходного кода, RBAC с интеграцией LDAP/AD.
Инженерия ИИ и машинного обучения
Проверка кода, созданного ИИ, очистка завершённых экспериментов, аудит ML-конвейеров.
Готовы увидеть CodeGraph в действии?
Запросите персональную демонстрацию для вашей команды и кодовой базы
Запросить демо