💻 1. Введение в проблематику аудита исходного кода и контроля выполнения ТЗ

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

• Инженерно-техническая экспертиза исходного кода программы на предмет его соответствия техническому заданию (ТЗ) — это комплексное научно-методическое исследование, проводимое специалистами в области программной инженерии, кибербезопасности и информационных систем. Данное исследование направлено на углубленный технический анализ архитектуры, алгоритмов, структуры, стека технологий и функциональных возможностей представленного исходного кода. Экспертиза позволяет объективно установить, выполнен ли объем работ в соответствии с условиями договора и ТЗ, обладает ли программный продукт заявленной производительностью и надежностью, и пригоден ли он к эксплуатации в целевой IT-инфраструктуре.

⚖️ 2. Правовой статус, институциональное значение и нормативная база IT-экспертизы

• Исходный код программы с точки зрения гражданского законодательства Российской Федерации (Гражданский кодекс РФ, Часть 4) охраняется как произведение литературы и является объектом авторского права. При этом программный продукт одновременно выступает результатом выполнения договора подряда или договора на разработку программного обеспечения. Экспертное заключение, составленное по результатам исследования исходного кода, представляет собой официальный процессуальный документ, обладающий высокой доказательной силой в рамках судебных споров и претензионных процедур.
• Правовой статус экспертизы определяется нормами Гражданского процессуального кодекса РФ (ГПК РФ), Арбитражного процессуального кодекса РФ (АПК РФ) и Федерального закона № 73-ФЗ «О государственной судебно-экспертной деятельности в Российской Федерации». IT-эксперт берет на себя процессуальную ответственность за объективность, полноту и научную обоснованность сделанных выводов. Экспертиза исходного кода позволяет суду или заказчику получить квалифицированную оценку абстрактных цифровых объектов, конвертируя сложный технический контекст в понятные юристам и арбитрам выводы о наличии или отсутствии нарушений условий договора.

🎯 3. Цели, ключевые задачи и предмет исследования программного обеспечения

Главная цель проведения IT-экспертизы исходного кода — установление степени соответствия фактически разработанного программного обеспечения требованиям, зафиксированным в техническом задании, спецификациях, приложениях к договору и иных нормативно-технических документах.

Для достижения поставленной цели в ходе экспертизы решается широкая колоссальная матрица узкоспециализированных задач:

• Идентификация и атрибуция исходного кода: подтверждение того, что представленный на исследование код принадлежит именно разрабатываемой программе и соответствует исследуемой версии.

• Проверка соответствия стека технологий: анализ языков программирования, фреймворков, компиляторов, СУБД и сторонних библиотек зафиксированным в ТЗ параметрам.

• Аудит функциональной полноты: сопоставление реализованных алгоритмов и бизнес-логики с требованиями каждого пункта ТЗ.

• Исследование качества и архитектуры кода: оценка модульности, читаемости, соблюдения кодинг-стандартов, отсутствия мертвых фрагментов (dead code) и жестко зашитых данных (hardcoding).

• Оценка информационной безопасности: поиск уязвимостей, системных закладок, недекларированных возможностей (НДВ) и каналов утечки данных.

• Оценка работоспособности и сборки: проверка возможности успешной компиляции, развертывания (deployment) и запуска программного комплекса в целевой среде.

📜 4. Нормативно-техническая база, ГОСТы и международные стандарты инженерии ПО

Судебный IT-эксперт при проведении исследования исходного кода не имеет права опираться лишь на субъективный программистский опыт. Каждая претензия или вывод об отсутствии соответствия должны подкрепляться ссылками на государственные стандарты и международные спецификации программной инженерии.

В экспертной практике используются следующие ключевые нормативные документы:

• ГОСТ 19.101-77 и серия стандартов ЕСПД (Единая система программной документации), определяющие требования к составу и оформлению программных документов и ТЗ.

• ГОСТ Р ISO/IEC 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств».

• ГОСТ Р ISO/IEC 25010-2015 «Информационные технологии. Системная и программная инженерия. Требования к качеству и оценка систем и программного обеспечения (SQuaRE)».

• ГОСТ Р 56939-2016 «Защита информации. Разработка безопасного программного обеспечения».

• Международные стандарты и руководства OWASP (Open Web Application Security Project) для оценки безопасности веб-приложений и исходных текстов.

⚙️ 5. Архитектурный анализ исходного кода и проверка структуры программного комплекса

Архитектура программного обеспечения определяет его устойчивость к нагрузкам, простоту поддержки и возможности последующего масштабирования. На этапе архитектурного анализа эксперт изучает общую организацию кодовой базы, паттерны проектирования (Design Patterns) и распределение ответственности между модулями системы.

В ходе проверки эксперты анализируют, соответствуют ли примененные архитектурные решения (например, микросервисная архитектура, монолит, MVC, Clean Architecture, CQRS) требованиям, прописанным в техническом задании. Эксперты устанавливают, не приводит ли текущая организация кода к высокой связности (High Coupling) и низкой связности внутри модулей (Low Cohesion), что делает систему хрупкой и неработоспособной при внесении минимальных изменений. Выявление хаотичной структуры («spaghetti code») служит прямым доказательством нарушения профессиональных стандартов разработки.

🔍 6. Методология проведения экспертизы: сочетание статического и динамического анализа

Качественная IT-экспертиза исходного кода строится на совмещении двух фундаментальных подходов аналитической диагностики: статического анализа (Static Application Security Testing / Code Review) и динамического анализа (Dynamic Testing).

Статический анализ заключается в исследовании исходных текстов программы без их фактического исполнения. Эксперты используют специализированные статические анализаторы (SonarQube, Checkmarx, Fortify), а также проводят ручной экспертный ревью (Manual Code Review). Это позволяет выявить синтаксические ошибки, антипаттерны, неэффективные алгоритмы и уязвимости. Динамический анализ требует сборки программного продукта, его развертывания в тестовом контуре и отслеживания поведения программы во время выполнения функций с фиксацией использования памяти, процессора и корректности обработки входных данных.

📐 7. Анализ стека технологий, фреймворков и библиотек на соответствие ТЗ

Техническое задание часто содержит жесткие требования к технологическому стеку. Заказчик может зафиксировать использование определенной версии языка (например, Python 3.11, Java 17, C# 11), конкретной СУБД (PostgreSQL, PostgreSQL Pro) и специфических фреймворков (React, Angular, Spring Boot, Django).

Эксперт проводит детальный аудит файлов конфигурации проекта (pom.xml, package.json, requirements.txt, build.gradle и т.д.) и деклараций импорта в самом коде. Изменение стека технологий без согласования с заказчиком часто квалифицируется как существенное нарушение условий ТЗ. Например, замена серверного языка с Go на PHP или применение устаревшего фреймворка с прекращенной поддержкой создает для заказчика критические риски в области безопасности и поддержки продукта, что подробно отражается в экспертном заключении.

🔌 8. Проверка реализации функциональных требований и бизнес-логики

Функциональные требования ТЗ описывают, что именно должна делать программа: какие действия выполняет пользователь, как обрабатываются документы, какие отчеты формируются и какие математические алгоритмы применяются для расчетов.

Экспертный аудит функциональности включает пошаговую трассировку исходного кода (Code Tracing). Эксперт берет каждый пункт функциональных требований из ТЗ и ищет в исходном коде программные модули, классы, функции и контроллеры, ответственные за его выполнение. Если функция задекларирована в ТЗ, но в коде присутствует лишь «заглушка» (stub) или логика функции реализована с ошибками (например, неверно рассчитывается налоговая ставка или алгоритм скидок), эксперт фиксирует невыполнение конкретного пункта ТЗ с приведением листинга соответствующего участка кода.

⚡ 9. Оценка нефункциональных требований: производительность, отказоустойчивость и масштабируемость

Нефункциональные требования определяют свойства системы: скорость отклика, время обработки запроса, количество одновременно обслуживаемых пользователей, стойкость к сбоям оборудования и восстанавливаемость после ошибок.

Для проверки производительности кода эксперт анализирует алгоритмическую сложность реализованных функций (нотация $O(n)$), наличие узких мест в обработке массивов данных, заблокированных потоков (deadlocks) и утечек памяти (memory leaks). Путем проведения нагрузочного тестирования на смонтированном из исходного кода стенде эксперты фиксируют, справляется ли программа с предусмотренной в ТЗ пиковой нагрузкой (например, 10 000 RPS). Несоответствие времени отклика системы значениям из ТЗ прямо свидетельствует об огрехах в оптимизации исходного кода.

🔒 10. Экспертиза информационной безопасности и поиск уязвимостей в коде

Требования к защите информации являются важнейшей частью ТЗ для банковских, медицинских, государственных и корпоративных информационных систем. Исходный код проверяется на отсутствие критических векторов атак.

В ходе специализированного аудита безопасности эксперт проверяет исходный код на наличие стандартных уязвимостей из списков OWASP Top 10 и CWE Top 25:

• SQL-инъекции (SQLi) из-за отсутствия параметризации запросов к базе данных.

• Межсайтовый скриптинг (XSS) и подделка межсайтовых запросов (CSRF).

• Уязвимости аутентификации, хранение паролей в открытом виде или использование слабых хэш-функций (MD5, SHA1 вместо bcrypt/Argon2).

• Жестко зашитые в коде пароли, API-ключи, токены и приватные ключи шифрования (Hardcoded Credentials).

• Наличие программных закладок, обеспечивающих скрытый доступ к системе в обход штатных средств защиты.

📝 11. Анализ качества кода, рефакторинга, кодинг-стандартов и документирования

Качество кода напрямую влияет на стоимость его будущей поддержки и сопровождения. В ТЗ или стандартах разработки компании часто прописываются требования к оформлению кода, уровню покрытия модульными тестами (Unit Tests) и наличию внутренней технической документации.

Эксперт проверяет соответствие кода общепринятым гайдлайнам (PEP 8 для Python, PSR для PHP, Google Java Style Guide и т.д.). Также рассчитываются метрики качества программного обеспечения: циклическая сложность Маккейба (Cyclomatic Complexity), индекс поддерживаемости (Maintainability Index) и процент покрытия кода модульными тестами. Если ТЗ требовало покрытие Unit-тестами не менее 80%, а фактический аудит показывает 15% или полное отсутствие тестовых классов, это фиксируется как безусловное несоответствие качественным критериям договора.

🗄️ 12. Исследование структуры баз данных, ORM и корректности работы с данными

Информационные системы в подавляющем большинстве активно взаимодействуют с системами управления базами данных. Качество проектирования схемы БД и запросов из исходного кода определяет общую стабильность комплекса.

Экспертиза включает аудит DDL-скриптов создания таблиц, индексов, внешних ключей и триггеров. Эксперт исследует файлы миграций и слой взаимодействия с данными (Data Access Layer / ORM). Оценивается наличие необходимых индексов для ускорения поиска, отсутствие проблемы N+1 запросов при работе с ORM, правильность использования транзакций и уровней изоляции для предотвращения искажения данных при одновременном многопользовательском доступе.

🌐 13. Проверка интеграционных модулей, API и внешних сервисов

Современное программное обеспечение не работает изолированно: оно интегрируется с платежными шлюзами, государственными информационными системами (СМЭВ, ЕГАИС), CRM-системами, картографическими сервисами и внешними REST/SOAP API.

Эксперт сопоставляет спецификации интеграционных протоколов из ТЗ с их фактической реализацией в коде. Проверяется корректность обработки ошибок внешних сервисов (таймауты, сетевые сбои, коды ответов 5xx), наличие механизма повторных запросов (retry pattern), шифрование передаваемых данных по протоколам TLS/HTTPS и правильно реализованная авторизация по стандартам OAuth 2.0 или JWT.

🛠️ 14. Оценка версионности, использования систем Git и исполнительной документации

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

В ходе экспертизы исследуется история коммитов в системе контроля версий (Git). Это позволяет эксперту определить хронологию разработки, установить авторов конкретных фрагментов кода, проверить интенсивность работ и выявить факты экстренной «подгонки» кода перед самой сдачей. Также проверяется полнота инструкций: может ли сторонний квалифицированный специалист на основе представленной документации и репозитория развернуть и собрать рабочий дистрибутив программы без участия разработчика.

⚠️ 15. Классификация дефектов ПО, несоответствий ТЗ и критических багов

Все выявленные в процессе экспертизы несоответствия, ошибки и отклонения от ТЗ систематизируются и классифицируются по степени их влияния на работоспособность программного продукта.

Применяется следующая классификация дефектов:

• Критические дефекты (Blocker/Critical): дефекты, приводящие к неработоспособности ключевых функций программы, падению системы, полному отсутствию реализации важных разделов ТЗ или наличию фатальных уязвимостей.

• Значительные дефекты (Major): ошибки в реализации отдельных функций, существенные отклонения от производительности или несоблюдение стека технологий, не блокирующие работу системы целиком, но требующие серьезных трудозатрат на устранение.

• Незначительные дефекты (Minor/Trivial): опечатки в интерфейсе, небольшие отклонения в оформлении кода, отсутствующие комментарии или некритичные замечания к документации.

📊 16. Расчет сметной стоимости доработки ПО и устранения выявленных дефектов

Критически важной частью экспертного заключения для арбитражных споров является финансовая оценка выявленных недостатков. Эксперт-сметчик в сфере IT на базе дефектной ведомости рассчитывает объем трудозатрат в человеко-часах (Man-Hours), необходимых для приведения кода в полное соответствие с ТЗ.

Расчет стоимости включает:

• Оценку затрат на рефакторинг и переписывание некачественно реализованных модулей.

• Стоимость разработки полностью отсутствующих функций, зафиксированных в ТЗ.

• Затраты на устранение найденных уязвимостей и проведение оптимизации производительности.

• Стоимость доработки технической и пользовательской документации.

• Оценку трудозатрат на повторное интеграционное и нагрузочное тестирование.

🤝 17. Досудебное урегулирование споров между заказчиком и IT-подрядчиком

Получение квалифицированного независимого экспертного заключения до подачи иска в суд дает сторонам конфликта мощный инструмент для объективной оценки правовых и финансовых перспектив спора.

Заказчик, получив экспертное заключение с зафиксированными критическими дефектами, направляет подрядчику официальную претензию с требованием возместить уплаченные средства, выплатить неустойку или безвозмездно устранить недостатки в установленный срок. В свою очередь, подрядчик, видя детальный технический анализ, подкрепленный скриншотами, листингами кода и ссылками на ГОСТы, в большинстве случаев отказывается от необоснованных требований и соглашается на компромиссное решение без несения судебных издержек.

⚖️ 18. Судебная компьютерно-техническая экспертиза исходного кода

В случае если досудебное соглашение не достигнуто, судом назначается судебная компьютерно-техническая экспертиза (СКТЭ). Экспертам поручается дать четкие ответы на вопросы, поставленные в определении суда.

Судебный эксперт предупреждается об уголовной ответственности по статье 307 УК РФ за дачу заведомо ложного заключения. Исследование проводится на предоставленных суду материалах (флеш-накопители, жесткие диски, доступы к Git-репозиториям, запечатанные в соответствии с процессуальными нормами). Выводы эксперта становятся определяющим доказательством при вынесении решения о взыскании убытков, расторжении договоров или признании прав на программное обеспечение.

📁 19. Подробные практические кейсы проведения экспертиз Союзом «Федерация судебных экспертов»

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

🏢 Кейс 1

Крупный ритейлер заключил договор с IT-компанией на разработку масштабируемой микросервисной системы управления складской логистикой стоимостью 45 миллионов рублей. Согласно ТЗ, бэкенд должен был быть написан на языке Go с использованием СУБД PostgreSQL, а система должна была выдерживать нагрузку в 5000 операций в секунду. Исполнитель сдал работу с задержкой и передал исходный код. При запуске системы в опытно-промышленную эксплуатацию на первом же складе происходили постоянные зависания базы данных и сбои при проведении накладных. Подрядчик утверждал, что проблема заключается в слабой аппаратной инфраструктуре заказчика.

Заказчик обратился в Союз «Федерация судебных экспертов» для проведения комплексной IT-экспертизы исходного кода. Эксперты провели статическо-динамический аудит репозитория. В ходе исследования выяснилось, что вместо заявленной микросервисной архитектуры на Go подрядчик поставил монолитное приложение на Python (Django), завернутое в Docker-контейнеры для создания видимости микросервисов. Аудит кода взаимодействия с БД показал полное отсутствие индексов и присутствие критической проблемы N+1 запросов: при формировании одного складского отчета программа совершала более 40 000 отдельных запросов к базе данных в цикле, что намертво блокировало СУБД. Кроме того, в коде были обнаружены хардкод-пароли суперпользователя. На основании подробного заключения экспертов с детальными листингами и графиками нагрузочного тестирования арбитражный суд полностью взыскал с подрядчика сумму аванса в размере 30 миллионов рублей, неустойку и расходы на экспертизу.

🏬 Кейс 2

Финтех-компания заказала разработку мобильного банка для iOS и Android с платежным модулем и интеграцией с процессовым центром по защищенному протоколу. Подрядчик сдал исходный код, подписав промежуточные акты. Однако при попытке пройти обязательный аудит безопасности для подключения к международным платежным системам сторонний аудитор выдал категорический отказ. Подрядчик отказался возвращать деньги, заявляя, что код полностью работоспособен, а требования аудиторов безопасности не входили в ТЗ.

Эксперты, которых задействовал Союз «Федерация судебных экспертов», провели глубокий аудит исходного кода мобильных приложений и серверной части. Исследование показало, что в коде мобильного приложения токены авторизации пользователей и приватные ключи подписи платежных транзакций сохранялись в незашифрованном виде в текстовый лог-файл устройства, доступный любым сторонним приложениям. В серверном коде обработчика платежей была обнаружена уязвимость типа SQL-инъекция, позволяющая путем отправки модифицированного JSON-пакета изменить баланс любого кошелька. Эксперты доказали, что код не соответствует требованиям раздела ТЗ «Информационная безопасность» и ГОСТ Р 56939-2016. Подрядчик, ознакомившись с доказательной базой экспертного заключения, подписал мировое соглашение, доработав код и устранив все 48 выявленных уязвимостей за свой счет.

🏡 Кейс 3

Заказчик (владелец крупной сети медицинских клиник) обратился к разработчикам за созданием веб-портала личного кабинета пациента с возможностью просмотра электронных медкарт и интеграцией с МИС (медицинской информационной системой). Стоимость контракта составила 12 миллионов рублей. По истечении срока договора подрядчик передал архив с исходным кодом и заявив, что продукт готов на 100%. При попытке развернуть проект инженеры заказчика не смогли собрать приложение из-за отсутствия файлов конфигурации и зависимостей.

Для проведения экспертизы был привлечен Союз «Федерация судебных экспертов». Эксперты провели попытку сборки и статический анализ кода. Выяснилось, что предоставленный архив содержит лишь компилированные бинарные файлы и фрагменты чужого опенсорс-проекта, из которого были удалены авторские лицензии. Из 12 заявленных в ТЗ модулей (запись на прием, телемедицина, оплата, интеграция с МИС и др.) реальный рабочий код присутствовал только для формы авторизации и страницы с контактами. Все остальные разделы состояли из статичной верстки без бизнес-логики (mock-данные). Эксперты доказали факт имитации разработки и фальсификации исходного кода. Суд признал договор неисполненным по вине исполнителя и обязал подрядчика вернуть выплаченный аванс в полном объеме.

🏭 Кейс 4

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

Команда специалистов, которую сформировал Союз «Федерация судебных экспертов», провела сравнительный синтаксический и семантический аудит исходных текстов (Plagiarism Code Review) переданной программы и базовой версии продукта подрядчика. С помощью специализированного программного обеспечения эксперты выявили 87% смыслового совпадения структуры классов, наименований переменных, базы данных и даже комментариев разработчиков (включая сохраненные опечатки в комментариях пятилетней давности). Эксперты доказали, что переданный продукт является модификацией существующего ПО, а оригинальный код составляет менее 13%. Это позволило заказчику в арбитражном суде расторгнуть договор, взыскать компенсацию за нарушение интеллектуальных прав и вернуть уплаченные деньги.

🏛️ Кейс 5

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

Назначенная судом экспертиза была поручена организации Союз «Федерация судебных экспертов». Эксперты развернули тестовый контур и провели аудит исходного кода модулей распознавания автомобильных номеров и параллельной обработки видео. Было установлено, что алгоритм распознавания был написан без использования аппаратного ускорения GPU, а обработка кадров выполнялась в один поток на CPU, что физически не позволяло достичь требуемой в ТЗ производительности в 60 кадров в секунду на канал. Эксперты сформировали дефектную ведомость и рассчитали стоимость необходимого рефакторинга кода. На основании судебного заключения суд уменьшил сумму контракта на стоимость доработки (22 миллиона рублей) и обязал подрядчика устранить недостатки перед получением окончательного расчета.

📋 20. Практические рекомендации заказчикам и разработчикам по составлению ТЗ и приемке кода

Чтобы свести к минимуму риск возникновения судебных разбирательств и гарантировать получение качественного программного продукта, сторонам IT-контракта рекомендуется соблюдать четкий регламент взаимодействия.

Рекомендации для заказчиков и разработчиков:

• Составлять предельно детализированное ТЗ с четко сформулированными критериями приемки (Acceptance Criteria) и метриками нефункциональных требований.

• Фиксировать в договоре стек технологий, версии языков, фреймворков, СУБД и обязательные стандарты оформления кода.

• Проводить поэтапную приемку исходного кода с обязательной проверкой промежуточных коммитов в Git-репозитории заказчика.

• Требовать от исполнителя предоставления автотестов (Unit и Integration тесты) с зафиксированным уровнем покрытия кода.

• Проводить независимый аудит и IT-экспертизу исходного кода до подписания итоговых актов выполненных работ и выплат финальных траншей.

📌 21. Итоговые заключения и экспертные выводы

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

Применение современных методик статического и динамического анализа, соблюдение ГОСТов и привлечение квалифицированных судебных экспертов обеспечивают высокую точность выводов, позволяя успешно разрешать самые сложные арбитражные и досудебные споры в сфере высоких технологий.

Полную контактную информацию, телефон и адрес офиса, а также более подробную информацию по вашему вопросу вы можете найти на нашем официальном сайте 🔴 https://fse.ms/