Судебная экспертиза программного обеспечения (ПО) г.Москва

Привет, коллега. 👨‍💻 Если ты читаешь это, возможно, тебе уже пришла повестка в арбитражный суд Москвы, или ты только начинаешь подозревать, что спор с заказчиком или партнером может туда попасть. Я разработчик с 12-летним стажем, и последние несколько лет я также выступаю в роли эксперта. Не теоретика, а того самого человека, который проводит судебную экспертизу программного обеспечения (ПО). Давай без воды: расскажу, как это работает на самом деле и почему в спорах о коде судьи слушают именно таких, как мы.

👨💻 Код под прицелом: как выглядит судебная программная экспертиза глазами разработчика из Москвы 👨💻

Привет, коллега! ✋ Сидел недавно на митапе в Москве, и зашла речь о том, что делать, если твой код становится объектом судебного разбирательства. Решил разобраться, что такое судебная программная экспертиза на практике, а не в сухих юридических терминах. Спойлер: это похоже на самый жесткий код-ревью в твоей жизни, только с последствиями.

🚨 Когда код идет в суд: реальность московского IT

Представь: ты год пахал над проектом, сдал его, получил оплату. А через полгода — письмо из суда. Заказчик утверждает, что ты сдал нерабочий продукт, или скопировал код у конкурента, или оставил уязвимости. Вот тут и начинается судебная экспертиза программ — процесс, когда твой код разбирают по косточкам другие разработчики, но не для помощи, а для доказательства чего-то в суде.

В Москве и МО, где я работаю уже 8 лет, такие истории случаются всё чаще. По данным знакомого юриста, только в Арбитражном суде Москвы в прошлом году было 150+ дел, где требовалась экспертиза программного обеспечения для суда. И это только те случаи, которые дошли до суда!

🔍 Что на самом деле происходит во время экспертизы

Когда я впервые попал в ситуацию, где потребовалось проведение судебной экспертизы ПО, думал, будет что-то вроде собеседования в Google. Но оказалось ещё интереснее.

Что делают эксперты, когда проводят судебное исследование кода:

Делают полный дамп твоего репозитория— со всеми ветками, тегами, историей коммитов (даже тех, что ты пытался удалить) 📦
• Запускают статические анализаторы — те самые SonarQube, ESLint, Pylint, которые мы иногда игнорируем в проде
• Считают все возможные метрики — от цикломатической сложности до coverage тестами 📈
• Сравнивают твой код с «подозреваемым» — ищут не только текстовые совпадения, но и структурные, алгоритмические
• Воспроизводят заявленные баги — если кто-то говорит «не работает», эксперты пробуют заставить это работать (или доказать, что действительно не работает)
• Анализируют архитектуру — как будто самый дотошный архитектор из твоей компании проверяет каждое решение 🏗️

Программно-техническая экспертиза для суда — это не просто «посмотреть код». Это:

Фиксация всего процесса (скриншоты, логи, видео)
Использование сертифицированного ПО для анализа
Строгий протокол: что, когда и как делалось
Возможность повторить всё точно так же через месяц или год

❓ Вопросы, которые задают при экспертизе (на языке разработчика)

Давай представим, что суд — это самый требовательный продукт-менеджер. Какие задачи он ставит в Jira для судебной экспертизы программного обеспечения?

Про авторство и плагиат:

«Этот кусок кода — твое оригинальное решение или скопирован?»
По-нашему: писал ли ты это сам или copy-paste из Stack Overflow?
«Сколько процентов кода уникально, а сколько — стандартные библиотеки?»
Реально: твой вклад vs фреймворки и либы
«Есть ли в коде уникальные «отпечатки» — специфичные названия, структура, комментарии?»
У каждого разработчика свой стиль, как почерк

Про качество и соответствие ТЗ:

«Сделано ли то, что было обещано в техническом задании?»
Классика: «В ТЗ было 20 фич, а реализовано 15»
«Работает ли система так, как заявлено в документации?»
Бывает: в документации одно, в коде — другое
«Соответствует ли код заявленному уровню разработчика (junior/middle/senior)?»
Интересный момент: если брали деньги за senior-разработку, а код на уровне junior…

Про баги и уязвимости:

«Есть ли критические ошибки, которые ломают основную функциональность?»
Типа: «При загрузке файла больше 1 ГБ падает вся система»
«Насколько безопасен код? Есть ли SQL-инъекции, XSS, проблемы с аутентификацией?»
Security — больная тема для многих проектов в Москве
«Используются ли устаревшие библиотеки с известными уязвимостями?»
Мы все знаем про legacy-проекты на старых версиях Spring или Django

Про производительность и масштабируемость:

«Выдерживает ли система обещанную нагрузку?»
Было в ТЗ «10000 пользователей онлайн», а реально — 1000 и уже лагает
«Насколько хорошо оптимизирован код? Есть ли memory leaks, bottlenecks?»
Профилирование в режиме «найди слабое место»
«Можно ли легко расширять систему, добавлять новые функции?»
Проверка на «спагетти-код» и технический долг

🛠️ Инструменты, которые реально используют

Как разработчики, мы уважаем инструменты. Вот что я видел в работе у экспертов:

Для анализа качества:SonarQube, CodeClimate, Codacy
• Для поиска уязвимостей: Checkmarx, Fortify, Veracode
• Для сравнения кода: Beyond Compare, WinMerge, собственные diff-утилиты
• Для метрик: NDepend, SourceMonitor, Understand
• Для безопасности: Burp Suite, OWASP ZAP, sqlmap
• Для нагрузочного тестирования: JMeter, Gatling, Locust
• Для анализа Git: git log, git blame, git bisect (да-да, они могут найти, когда именно появилась проблема)

При этом судебная экспертиза программ требует, чтобы инструменты были либо open-source, либо имели сертификаты. Нельзя просто взять и сказать: «А вот мой кастомный скрипт показал, что…».

💻 Реальные истории из практики судебной экспертизы в Москве и МО

Кейс 1: Два стартапа и спорный алгоритм матчинга

Ситуация: В Сколково стартап А сделал алгоритм подбора персонала. Через полгода стартап Б выпустил похожий продукт с сопоставимой точностью.

Что делала экспертиза программ для судебного разбирательства:
• Сравнила Python-код обоих проектов
• Построила графы вызовов — совпадение 68%
• Нашла одинаковые «костыли» — временные решения, которые потом забыли убрать
• Обнаружила совпадающие комментарии с опечатками

Фишка: Алгоритм был сложный, с машинным обучением. Эксперты разобрались и в feature engineering, и в выборе моделей. Оказалось, скопировали не просто код, а всю pipeline.

Кейс 2: CRM-система, которая «почти работает»

Ситуация: Заказчик из Москвы заплатил 3 млн за CRM, но система постоянно падала. Подрядчик говорил: «Это баги окружения, у нас всё работает».

Судебная программно-техническая экспертиза показала:
• Из 40 модулей ТЗ сделано 28
• В 12 модулях — критические баги (данные терялись при любой ошибке)
• Архитектура — монолит на MySQL без индексов, с JOIN на 5 таблиц в основном запросе
• 70% кода — копипаста из документации и Stack Overflow

Цитата из отчёта: «Уровень кода соответствует junior developer с опытом менее 1 года». При том, что в договоре было «команда senior-разработчиков».

Кейс 3: Утечка данных в системе для врачей

Ситуация: В Подмосковье из системы записи к врачам утекли данные пациентов. Подозревали хакеров, но оказалось всё проще.

Проведенная судебная экспертиза ПО обнаружила:
• API-эндпоинт /api/patients/exportAll без какой-либо авторизации
• Пароли в БД хранились как plain text (да, в 2023 году!)
• Логирование отключено «для оптимизации»
• В коде — хардкоденные доступы к продовой БД из тестового окружения

Эксперты восстановили цепочку: нашёл эндпоинт → скачал данные → продал. Всё заняло 15 минут.

Кейс 4: Мобильное приложение банка, которое всех бесило

Ситуация: Банк заказал приложение. После релиза — 1-звёздочные отзывы, постоянные падения.

Судебная экспертиза программного кода выявила:
• Утечки памяти в 90% экранов (даже на сплэш-скрине!)
• Весь сетевой код — в main thread
• Ноль обработки ошибок (при падении сети — креш)
• Deprecated API, которые скоро перестанут работать
• Размер приложения — 300 МБ (неоптимизированные картинки, 5 версий одной библиотеки)

Метрики были убийственные: 40 кадров в секунду только на пустом экране, холодный запуск 20 секунд.

Кейс 5: Игровой движок и подозрительно похожая физика

Ситуация: Инди-разработчик из Москвы сделал физический движок для 2D-игр. Крупная студия выпустила хит с очень похожей физикой объектов.

Экспертиза для суда по программному обеспечению использовала:
• Дизассемблирование бинарников игры
• Сравнение алгоритмов расчёта физики (с точностью до погрешности float)
• Анализ шейдеров и эффектов
• Сравнение структур данных в памяти

Оказалось, студия купила «чистый» код у фрилансера, который стажировался у инди-разработчика и унёс с собой копию репозитория. Сложность была в C++17 со множеством шаблонов и constexpr.

🛡️ Как не попасть под раздачу: советы от бывалого

Пообщавшись с экспертами и теми, кто через это прошёл, собрал советы:

До начала проекта:

Веди git как положено: осмысленные коммиты, чистая история
• Сохраняй всю переписку про требования (Telegram, почта, Jira — всё)
• Пиши документацию на архитектурные решения
• Используй линтеры и formatters с первого дня

Во время разработки:

Пиши unit-тесты (они не только для качества, но и как доказательство, что ты понимал требования)
• Настрой CI/CD с проверками качества
• Веди changelog, фиксируй изменения требований
• Делай code review и сохраняй результаты

Если уже начались проблемы:

Ничего не удаляй из репозитория (даже если очень хочется)
• Сохрани все версии, билды, миграции
• Собери все метрики качества заранее
• Подготовь документацию: что, как и почему сделано

📊 Какие метрики реально смотрят

Мы, разработчики, любим цифры. Вот что интересует экспертов при судебном исследовании программ:

Покрытие тестами— меньше 70% = вопросы
• Цикломатическая сложность методов — больше 15 = проблема
• Дублирование кода — больше 10% = плохо
• Технический долг — в человеко-днях, расчётный
• Время ответа API — против заявленного в ТЗ
• Количество critical/severe багов — по классификации

В Москве у экспертов есть даже «таблицы норм», собранные по сотням проектов. Знакомый эксперт говорил: «Мы знаем, как в среднем выглядит код московской fintech-компании, сап-стартапа или госзаказчика».

🤔 FAQ от разработчиков про экспертизу

Вопрос: Смогут ли эксперты разобраться в моём кастомном фреймворке/алгоритме?
Ответ: Обычно да. Эксперты — это senior’ы с опытом 10-15 лет. Видели и нейросети, и блокчейн, и embedded.

Вопрос: Что важнее — чтобы код работал или чтобы был красивым?
Ответ: Смотря что в ТЗ. Если в ТЗ было «чистая архитектура», то да. Если просто «работает», то нет.

Вопрос: Придерутся к тому, что я использовал ChatGPT для генерации кода?
Ответ: Если это нарушает договор или права — да. Если нет — обычно нет. Но лучше указывать в комментариях.

Вопрос: Насколько глубоко они копают?
Ответ: Зависит от суммы иска и сложности дела. Иногда хватает поверхностного анализа, иногда разбирают каждую строчку неделями.

🚀 Тренды в Москве и МО

Смотрю на последние дела — тенденции такие:

Больше дел про AI— кто-то скопировал модель, датасет или весь pipeline
• Блокчейн и смарт-контракты — особенно про безопасность и уязвимости
• Мобильные приложения — сбор данных, performance, батарея
• Legacy-системы — когда старый код модернизируют и возникают споры
• Cloud-архитектуры — правильность использования облачных сервисов

💎 Итог для разработчика

Коллеги, судебная экспертиза программного обеспечения — это не конец света, если ты:

Работаешь честно и не копируешь чужое
Ведёшь нормальную разработку с тестами и документацией
Фиксируешь требования и их изменения
Следишь за качеством кода (хотя бы на базовом уровне)

В Москве и МО IT-тусовка тесная. Одна неудачная судебная экспертиза может сильно ударить по репутации.

🆘 Если уже случилось

Если тебе предстоит судебная экспертиза ПО, ищи профессионалов, которые говорят на нашем языке. В Москве есть экспертные организации, где работают бывшие senior-разработчики из топовых компаний.

Одна из таких — https://kompexp.ru/ 👨💻⚖️

Они не только проводят экспертизу программ для суда, но и помогают подготовиться, дают советы по коду. Как говорит мой знакомый, который через это прошёл: «Лучше потратить деньги на консультацию у эксперта перед проверкой, чем потом объяснять в суде, почему в коде бардак».