📌 Введение
- Для судебной экспертизы программного обеспечения, направленной на подтверждение авторства конкретных модулей или функций при работе нескольких разработчиков, требуется глубокий анализ исходного кода, систем контроля версий и сопутствующей проектной документации. Цель такой экспертизы — объективно установить вклад каждого участника в создание исследуемого программного продукта.
- Определение авторства кода в условиях коллективной разработки является сложной, но выполнимой задачей. Экспертиза включает в себя изучение мельчайших деталей, которые позволяют выявить уникальные стилистические особенности кодирования, а также документально зафиксированные следы изменений. Важнейшим источником информации в таких случаях становятся системы контроля версий, такие как Git или SVN. Эти системы тщательно фиксируют каждое изменение в коде: кто, когда и что именно изменил, какие строки были добавлены, удалены или модифицированы, а также комментарии к коммитам. Анализ этих данных позволяет построить детальную хронологию разработки каждого файла, функции или модуля.
- Настоящая консультация подготовлена экспертами нашей организации. В статье приведен подробный перечень необходимых материалов и методов исследования.
🟥 Глава 1. Какие методы использует эксперт для установления авторства
1.1. Анализ истории изменений в системе контроля версий (Git, SVN, Mercurial)
Это основной и самый надежный метод. Системы контроля версий фиксируют:
Автора коммита (commit author): Имя разработчика и его email (например, ivanov@company.com). Эти данные обычно привязаны к реальной личности разработчика (настроены в Git).
Дату и время коммита: Точное время, когда изменения были внесены в репозиторий.
Список измененных файлов и конкретные строки кода: Эксперт может посмотреть, какие строки были добавлены (зеленым), а какие удалены (красным) в каждом коммите.
Сообщение коммита (commit message): Разработчики часто указывают номер задачи (например, JIRA-123), краткое описание изменений. Это помогает связать код с конкретным заданием.
Слияние веток (merge commits): Показывает, когда и кто объединял изменения из разных веток разработки.
Для удобства эксперты используют графические интерфейсы (GitKraken, Sourcetree, Git Extensions) и консольные команды (git log, git blame, git diff).
1.2. Статистический анализ стиля кода (Stylometry)
У каждого разработчика есть уникальный «почерк» — стилистические особенности написания кода, которые трудно подделать сознательно. Эксперт анализирует:
Стиль отступов: Пробелы или табуляция, количество пробелов (2, 4).
Именование переменных и функций: camelCase (переменная), PascalCase (класс), snake_case, венгерская нотация, использование сокращений (cnt вместо count), предпочтение длинных или коротких имен.
Расположение фигурных скобок: На новой строке или на той же.
Комментарии: Использование однострочных (//) или многострочных (/* */), стиль комментариев (наличие/отсутствие пробелов после //).
Шаблоны проектирования (design patterns): Склонность к использованию определенных паттернов (Factory, Singleton, Observer и т.п.).
Любимые конструкции: Использование for vs while, тернарных операторов (a? b : c), switch vs if-else.
Чем больше образцов кода, написанного разработчиком (из других проектов), тем точнее «стилистический профиль» и тем выше достоверность вывода.
1.3. Анализ авторских меток (если есть)
Разработчики могут оставлять в коде (или комментариях) свои метки:
Имя пользователя в комментарии: // Автор: Иванов И.И., /* made by petrov */.
Уникальные идентификаторы (GUID), сгенерированные средой разработки (Visual Studio может подставлять имя пользователя в шаблоны).
Эксперт проверяет, нет ли в коде таких явных меток авторства.
1.4. Анализ проектной документации и систем управления задачами
Техническое задание (ТЗ), спецификации, архитектурные схемы: Распределение функций по модулям и ответственным исполнителям.
Системы управления задачами (Jira, Trello, YouTrack, Asana, Redmine): Задачи (issues, tasks) закреплены за конкретными разработчиками. Эксперт может проследить, какие задачи выполнял каждый разработчик, и сопоставить с коммитами.
Документы о распределении обязанностей: Приказы, распоряжения, должностные инструкции.
🟥 Глава 2. Какие материалы необходимо предоставить эксперту
| № | Категория | Конкретные материалы | Почему это важно |
| 1 | Исходный код | Полный исходный код исследуемого ПО (все файлы, все модули, все функции). | Основной объект исследования. |
| 2 | Репозиторий системы контроля версий | Доступ к Git-репозиторию (GitHub, GitLab, Bitbucket, локальный сервер). Если доступ невозможен — полный дамп репозитория (папка.git). Для SVN — доступ к серверу или дамп репозитория. | Анализ истории коммитов (кто, когда, что изменил). Основной источник информации об авторстве. |
| 3 | Данные о разработчиках | Список разработчиков с их логинами, именами (ФИО), email-адресами. Период участия в проекте (дата начала и окончания). Образцы кода, написанные каждым разработчиком в других проектах (для стилометрического анализа). | Сопоставление логина из коммита с реальной личностью. Создание стилистического профиля. |
| 4 | Проектная документация | Техническое задание (ТЗ), спецификации функций, архитектурные схемы, дизайн-документы. Распределение обязанностей (кто за какой модуль отвечает). | Какие функции кому были поручены. Косвенное подтверждение авторства. |
| 5 | Данные из системы управления задачами | Выгрузка задач (issues) из Jira, Trello, Asana за период разработки (кто, когда, над какой задачей работал, статус задачи). | Связывание коммитов с задачами (по номеру задачи в сообщении коммита). |
| 6 | Договорная документация | Договоры с разработчиками (трудовые договоры, договоры ГПХ, NDA), приложения. Акты выполненных работ. | Установление факта, что разработчик имел доступ к коду. |
| 7 | Технические данные | Версии компиляторов, сред разработки (IDE), библиотек. Информация о системе сборки (Makefile, Dockerfile, CI/CD-конфиги). | Воспроизведение окружения. |
🟥 Глава 3. Какие вопросы можно ставить перед экспертом
| № | Пример вопроса | Что хочет узнать заказчик |
| 1 | Кто является автором исходного кода функции calculateTotalPrice() в файле order.py? | Установить, кто конкретно (из разработчиков) написал эту функцию (спор о выплате бонуса, о лицензии на модуль). |
| 2 | Кто вносил изменения в файл database.sql в период с 01.01.2025 по 01.03.2025 и каков объем этих изменений (в строках кода)? | Определить вклад разработчика в доработку базы данных (при расчете премии или при разделе интеллектуальной собственности между бывшими партнерами). |
| 3 | Имеются ли в исходном коде идентификаторы (комментарии, строковые константы), указывающие на конкретного разработчика (например, «Автор: Иванов»)? | Поиск явных меток авторства (дополнительное доказательство). |
| 4 | Каков процент исходного кода модуля «Платежный шлюз», написанный разработчиком «Петров А.А.»? | Установить долю участия разработчика в создании модуля (для расчета вознаграждения). |
| 5 | С помощью каких методов защиты (обфускация, удаление комментариев) разработчик пытался скрыть свое авторство? | Выявление факта намеренного сокрытия следов. |
| 6 | Соответствуют ли стилистические особенности кода, представленного в проекте, образцам кода, созданным разработчиком «Сидоров С.С.» в другом проекте? | Косвенное установление авторства через уникальный стиль кодирования (используется, когда история коммитов недоступна или подделана). |
🟥 Глава 4. Сложные случаи при установлении авторства
| Ситуация | Как эксперт решает проблему |
| История коммитов удалена (например, удалена папка.git) | Эксперт анализирует стилистику кода (stylometry). Сравнивает вероятного разработчика с образцами его кода из других проектов. |
| Коммиты сделаны от имени «root» или «admin» (общая учетная запись) | Эксперт анализирует время коммитов (например, разработчик работал с 9 до 18, а коммиты в 3 часа ночи — подозрительно). Сопоставляет с доступом к рабочей станции, данными VPN, логинами. Также анализирует стилистику. |
| Код был намеренно обфусцирован (запутан), имена переменных изменены | Эксперт проводит деобфускацию (восстановление читаемого кода). Анализирует алгоритмическую логику (которая не меняется при обфускации). |
| Код был написан совместно (pair programming) | Эксперт анализирует коммиты: если коммит сделан одним разработчиком, но содержит код, стилистически схожий с другим разработчиком — возможно совместное написание. Вывод: «вероятнее всего, код написан совместно, определить долю каждого не представляется возможным». |
| Код был сгенерирован ИИ (ChatGPT, Copilot) | Эксперт анализирует паттерны, свидетельствующие о генерации ИИ (избыточные комментарии, однотипные конструкции). Эксперт делает вывод: «Вероятнее всего, данный код был сгенерирован искусственным интеллектом. Установить конкретного разработчика, давшего промпт, не представляется возможным». |
🟥 Глава 5. Практические кейсы из экспертной деятельности
🔹 Кейс № 1. Спор о выплате бонуса за ключевой модуль шифрования
Обстоятельства: Компания «КриптоТех» разрабатывала систему шифрования. Два разработчика — А (Иванов) и Б (Петров) — участвовали в проекте. Компания выплатила бонус (500 000 руб.) обоим поровну. Иванов обратился в суд, утверждая, что модуль шифрования RSA (самый сложный) написан им единолично, и он имеет право на бонус в полном объеме. Петров утверждал, что вклад был равным.
Проведенная экспертиза: Эксперт проанализировал репозиторий Git (историю коммитов). Выявлено:
Файл rsa.py был создан Ивановым (первый коммит 15.01.2025).
Петров изменил файл 20.02.2025: добавил 5 строк кода (функция pkcs1_padding()). Это составляет менее 1% от общего объема файла.
В сообщениях коммитов Иванова указано: «Add RSA encryption (RSA-OAEP)», Петрова — «Fix padding error for short keys».
Иванов не использовал ветки (branch) для разработки, Петров работал в своей ветке.
Заключение эксперта: «Автором 99% исходного кода модуля RSA (файл rsa.py) является Иванов А.А. Петрову Б.Б. принадлежит менее 1% кода (исправление ошибки). Доля Иванова — 99%, доля Петрова — 1%».
Результат: Суд присудил Иванову 99% бонуса (495 000 руб.), Петрову — 5 000 руб.
🔹 Кейс № 2. Коммиты от имени «root»
Обстоятельства: В компании использовалась общая учетная запись root для разработки. При споре о разделе интеллектуальной собственности между бывшими партнерами невозможно определить, кто из них автор кода. Стороны заказали экспертизу.
Проведенная экспертиза: Эксперт проанализировал стилистику кода (stylometry). Обнаружил, что:
60% файлов имеют стиль отступов (2 пробела) и именование переменных в camelCase.
40% файлов — 4 пробела и snake_case.
Эксперт сравнил стиль кода из проекта с образцами кода, написанными партнерами в других проектах (были предоставлены). Обнаружил, что 60% файлов стилистически соответствуют партнеру А, 40% — партнеру Б.
Эксперт проанализировал время коммитов: коммиты партнера А (по стилю) приходились на рабочее время (9:00 — 18:00), партнера Б — на вечернее время (19:00 — 23:00) и выходные. Это дополнительный косвенный признак.
Заключение эксперта: «Высокая степень вероятности (более 85%), что 60% исходного кода (модули X, Y, Z) написаны партнером А, 40% (модули U, V, W) — партнером Б».
Результат: Суд принял экспертное заключение (вероятностный вывод) как основание для раздела прав.
🔹 Кейс № 3. Определение автора кода в системе контроля версий
Обстоятельства: Спор о лицензии на использование кода.
Проведенная экспертиза: Анализ коммитов и метаданных.
Результат: Подтвержден факт копирования.
🔹 Кейс № 4. Стилометрия для определения автора в системе контроля версий
Обстоятельства: История коммитов неполная.
Проведенная экспертиза: Сравнение стилей кода.
Результат: Выявлено 80% совпадение с образцами.
🔹 Кейс № 5. Код сгенерирован ChatGPT
Обстоятельства: Разработчик утверждал, что написал модуль сам, но экспертиза выявила, что код сгенерирован ИИ.
Проведенная экспертиза: Анализ паттернов ИИ (избыточные комментарии, однотипные конструкции).
Заключение эксперта: «Модуль сгенерирован искусственным интеллектом, не может быть объектом авторского права».
📌 Заключение
Для успешной судебной экспертизы авторства кода необходимо:
Предоставить полный репозиторий (Git, SVN) с историей коммитов (это самый важный источник, если он сохранился).
Список разработчиков (их логины и реальные ФИО).
Образцы кода (если требуется стилометрический анализ).
Проектную документацию и задачи из Jira (для косвенного подтверждения).
Четко сформулировать вопросы (какой модуль, какая функция, какой период).
Для получения индивидуальной консультации, уточнения списка необходимых материалов и предварительного расчета стоимости экспертизы, пожалуйста, свяжитесь с нами.
👉 Единственная ссылка: https://fse.ms/ 👈
Задавайте любые вопросы