Введение: ПО как объект инженерного анализа

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

Инженерный подход: одинаковый стэк, разный контекст

С технической точки зрения, судебная и независимая программная экспертиза используют один и тот же инструментарий и методологию. Разница процессуальная: первая назначается судом, вторая — инициируется сторонами для due diligence или досудебного урегулирования. Но ядро — инженерное расследование.

Этап 1: Создание эталонного снапшота (Baseline)
Перед любым анализом мы фиксируем состояние системы. В инженерных терминах это создание снапшота с контрольными суммами. Для судебной экспертизы ПО это криминалистическое копирование с протоколом и хэшами (SHA-256). Для независимой экспертизы — та же процедура для обеспечения целостности данных. Без этого этапа любые выводы некорректны. 🔐

Этап 2: Анализ архитектуры и зависимостей (Architecture & Dependency Review)
• Построение графа зависимостей: Используем deptry, dependency-check, npm audit (или аналоги для других языков). Цель — получить карту всех компонентов: внутренних модулей и сторонних библиотек. Это помогает понять структуру и выявить скрытые связи. 📦
• Метрики кода (Code Metrics): Рассчитываем цикломатическую сложность, поддержанность (maintainability index), связность модулей. Высокие значения — объективный индикатор потенциально проблемного кода, который сложно тестировать и поддерживать. 📊

Этап 3: Сравнительный анализ (Comparative Analysis)
Ключевой этап для вопросов авторства и заимствований. Мы идем дальше простого diff.
• Поиск дубликатов (Clone Detection): Инструменты вроде jscpd ищут дублированный код даже после рефакторинга и переименований.
• Семантическое сравнение (Semantic Code Analysis): Сравниваем абстрактные синтаксические деревья (AST) или графы потоков данных (DFG). Это позволяет найти схожую логику, даже если переменные и функции названы по-разному. 🔍

Этап 4: Динамический анализ и тестирование (Dynamic Analysis & Testing)
Код существует для выполнения. Мы проверяем его в действии.
• Воспроизведение сценариев: Воссоздаем условия, при которых, по утверждению сторон, возникает ошибка или проявляется некорректное поведение.
• Нагрузочное тестирование (Load Testing): Используем k6, JMeter или Yandex.Tank для проверки соответствия заявленным характеристикам производительности (RPS, latency). 📈➡️⏱️
• Профилирование (Profiling): Инструменты вроде async-profiler или Py-Spy показывают, где система тратит процессорное время и память. Это помогает найти узкие места (bottlenecks). 🔧

Этап 5: Формирование инженерного отчета (Engineering Report)
Итог — не просто заключение, а технический отчет, где каждый вывод подкреплен:
• Конкретными метриками и их интерпретацией
• Фрагментами кода или конфигураций
• Результатами тестов (графики, логи)
• Рекомендациями по исправлению (если это входит в задачу)

Какие вопросы решает инженерная экспертиза ПО? Примеры из практики Москвы и МО

Блок по качеству кода и соответствию ТЗ:
• Соответствует ли фактическая архитектура микросервисов (количество сервисов, паттерны коммуникации) диаграммам, утвержденным в дизайн-документе? 🏗️
• Превышает ли цикломатическая сложность критических модулей порог в 15, что делает код трудным для тестирования и поддержки? 🧮
• Обнаруживается ли в коде SQL-инъекция или иная известная уязвимость (CWE), которая могла привести к инциденту? 🛡️
• Является ли падение производительности на 70% при нагрузке в 1000 RPS следствием ошибки в алгоритме (O(n²) вместо O(n log n)) или недостатка инфраструктуры? ⚡

Блок по авторству и оригинальности:
• Какова степень семантического сходства (в %) алгоритма рекомендаций в продукте А и продукте Б после исключения шаблонного кода? 🧩
• Можно ли статистически доказать, что два модуля написаны разными авторами, на основе анализа стиля (длина идентификаторов, использование языковых конструкций)? 📊
• Содержит ли код «артефакты» — уникальные, неочевидные решения, комментарии или ошибки, указывающие на общее происхождение? 🔎

Блок по расследованию инцидентов:
• Какой именно запрос к БД и при каких условиях вызывает deadlock, приводящий к отказу системы? 💥
• Можно ли по логам и модификациям кода установить точное время и способ внедрения вредоносного функционала (backdoor)? 🕵️‍♂️
• Приводит ли утечка памяти (memory leak) в конкретном модуле к постепенной деградации производительности и перезапускам сервиса? 🧠

Пять кейсов из практики Москвы и Московской области

Кейс 1: Арбитражный спор о несоответствии SLA системы расчетов (Москва, финтех)
Задача: Банк-заказчик подал иск к подрядчику: система расчёта процентов не укладывалась в согласованное время отклика (<100 мс).
Инженерный подход (судебная экспертиза ПО):

1. Развернули точную копию системы в изолированном контуре.
2. Провели серию нагрузочных тестов, постепенно увеличивая RPS. Снимали метрики с помощью APM-инструментов.
3. При достижении 80% от целевой нагрузки обнаружили экспоненциальный рост latency.
4. Профилирование (CPU Flame Graph) указало на метод calculateCompoundInterest, где в цикле выполнялся синхронный вызов логгера в БД.
   Результат: Предоставили суду отчет с графиками нагрузочного тестирования и Flame Graph, доказывающими, что архитектурная ошибка (синхронный I/O в цикле) — причина нарушения SLA. Иск удовлетворён. 🏦➡️📉➡️⚖️

Кейс 2: Due diligence перед покупкой SaaS-платформы для ритейла (Московская область)
Задача: Инвестор хотел оценить технические риски и качество кода стартапа.
Инженерный подход (независимая экспертиза ПО):

1. Проанализировали граф зависимостей: нашли 15 устаревших библиотек с критическими CVE.
2. Рассчитали метрики: средняя цикломатическая сложность по проекту — 28 (высокий риск).
3. Обнаружили в ключевом модуле анализа продаж SELECT N+1 проблему, неочевидную при малых данных.
   Результат: В отчете указали конкретные риски: 1) необходимость срочного обновления библиотек (стоимость ~X чел./мес.), 2) высокий «технический долг» в ядре. Это позволило снизить оценку компании. 💼➡️🔍➡️📉

Кейс 3: Спор о плагиате алгоритма гео-роутинга (Москва, логистика)
Задача: Компания А обвинила компанию Б в копировании уникального алгоритма построения маршрутов.
Инженерный подход (комплексная экспертиза ПО):

1. Выделили ядро алгоритма из обеих кодовых баз (C++ и Go), отбросив стандартные части (парсинг JSON, работа с сетью).
2. Построили графы вычислений (DFG) для каждого и применили алгоритм сравнения графов.
3. Проанализировали набор и значения эвристик, используемых для оптимизации.
   Результат: Обнаружили 94% совпадение в структуре DFG. Уникальные, неоптимальные эвристики совпали. Вероятность случайного совпадения — менее 0.1%. Заключение помогло сторонам достичь мирового соглашения. 🚚➡️🗺️➡️🤝

Кейс 4: Расследование аварийной остановки АСУ ТП на производстве (Московская область)
Задача: После обновления ПО контроллера произошел сбой, остановивший линию.
Инженерный подход (независимая экспертиза ПО с элементами реверс-инжиниринга):

1. Проанализировали дампы памяти и логи контроллера до и после сбоя.
2. Декомпилировали обновление прошивки.
3. Обнаружили, что в новой версии изменили тип переменной cycle_counter с uint32 на uint16 для «экономии памяти».
   Результат: При длительном работе (более 65535 циклов) происходило переполнение переменной, приводящее к некорректному расчету таймингов. Предоставили отчет с дизассемблированным кодом и математическим доказательством причины сбоя. ⚙️➡️💥➡️🔧

Кейс 5: Аудит безопасности API мобильного банка (Москва)
Задача: После публикации статьи об уязвимостях в СМИ банку нужна была срочная независимая проверка.
Инженерный подход (независимая экспертиза ПО):

1. Провели статический анализ кода (SAST) для поиска шаблонных уязвимостей.
2. Выполнили динамический анализ (DAST) и ручное тестирование API через Burp Suite.
3. Сфокусировались на механизмах аутентификации и смены пароля.
   Результат: Обнаружили, что эндпоинт сброса пароля не проверял лимит попыток ввода кода подтверждения, позволяя организовать брутфорс. Предоставили PoC-эксплойт и рекомендации по исправлению. Банк оперативно закрыл уязвимость до возможной эксплуатации. 📱➡️🔓➡️🛡️

Заключение

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

Ключевые инженерные принципы нашей работы:
• Воспроизводимость: любой анализ можно повторить с теми же артефактами и получить тот же результат.
• Объективность: выводы основаны на метриках и данных, а не на мнениях.
• Прагматизм: отчеты содержат конкретные технические детали и, где уместно, рекомендации по исправлению.

Для заказа судебной или независимой экспертизы программного обеспечения, основанной на строгом инженерном подходе, обращайтесь: https://kompexp.ru/ 👨‍💻⚖️🔍📊🔧