Судебная экспертиза исходного кода на PHP

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

Если спор уже начался, сначала зафиксируйте состояние сервера. Правка файла через FTP или панель хостинга может не попасть в историю репозитория. Каталог сайта, выгрузка базы и резервные копии провайдера способны измениться или быть удалены по правилам хранения. Что именно сохранять и в каком порядке, описано ниже, в разделе «Что сохранить, пока площадка не изменилась».

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

С какими спорами приходят

Экспертиза уместна, когда спор касается проверяемых обстоятельств: состояния сайта, состава переданных файлов, поведения программы и зафиксированного хода работ. До начала исследования нужно определить версию, площадку и период; иначе предмет останется неопределённым.

Вот с чем приходят чаще всего:

• подрядчик сдал сайт или интернет-магазин на «1С-Битрикс», WordPress, Laravel или самописном движке, а заказчик считает техническое задание невыполненным;
• стороны расходятся в объёме: подрядчик считает работой весь каталог сайта, заказчик — только то, что подрядчик написал сам, а не получил вместе с коробочной системой и модулями из каталога;
• сайт взломали, на страницах появился чужой код, и стороны спорят, чья это зона ответственности;
• после расторжения договора заказчику передали архив, который не разворачивается: не хватает файлов, настроек или выгрузки базы;
• подрядчик закрыл часть кода энкодером и после спора отказывается продлевать лицензию, а заказчик не может ни доработать сайт, ни сменить исполнителя;
• заказчик утверждает, что подрядчик выдал за свою разработку купленный шаблон или чужой модуль;
• требуется установить, когда появились спорные файлы или страницы, если репозитория нет или стороны спорят о датах.

Если ваш вопрос звучит иначе — например, спор идёт о самом факте публикации на странице, а не о коде, — точнее начать с экспертизы веб-сайтов.

Почему исходный код на PHP обычно цел — и почему это не упрощает дело

PHP-проекты отличаются от типичной поставки скомпилированной программы. Для C++ заказчику могут передать машинный код, а для Java — промежуточный байт-код; восстановленный из них текст не тождествен исходникам разработчика. Браузерная часть на JavaScript также может быть собрана и минифицирована. На PHP-сервере часто сохраняются читаемые файлы приложения с именами и комментариями, но это не гарантирует их полноту и авторское происхождение: часть кода может быть сгенерирована, поставлена в зависимостях или закрыта защитным средством.

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

Архив сохраняют вместе с описанием получения и рассчитанными контрольными суммами. Порядок расчёта приведён ниже.

До чтения кода проверяют, соответствуют ли файлы фактически исполнявшемуся состоянию. При отключённой проверке временных отметок OPcache изменённый файл может не примениться до сброса кеша или перезапуска; влияют также предварительная загрузка, кеши приложения, сгенерированные контейнеры и защищённые компоненты. Поэтому фиксируют каталог, конфигурацию и сведения о развёртывании, а вывод об исполнявшейся версии обосновывают совокупностью данных.

Чем это отличается от аудита кода и от проверки сайта

Три разные работы часто называют одним словом. Разница между ними — в адресате и предмете, а не в глубине.

Аудит кода проводят для владельца системы; его задача — определить, что следует улучшить, по заранее объявленным критериям и с учётом цели аудита. Судебный эксперт отвечает на поставленный вопрос и опирается на применимый проверяемый критерий — например, пункт технического задания или документацию используемой системы. Формулы «код написан плохо» недостаточно: нужно указать конкретное несоответствие и способ проверки.

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

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

Если в проекте не только PHP

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

Границу проводят до постановки вопросов, иначе объём поручения может выйти за пределы предмета исследования:

• спор о серверной логике — расчёты, заказы, права доступа, обмен с внешними системами: это как раз тема страницы, которую вы читаете;
• спор о поведении интерфейса в браузере — вёрстка, динамические формы, корзина на стороне клиента: экспертиза исходного кода на JavaScript;
• рядом с сайтом работает корпоративная система или сервис на других платформах: экспертиза кода на Java, экспертиза кода на Python;
• спор касается обмена с учётной системой: он разбирается на странице экспертизы 1С.

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

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

Битрикс, WordPress, Laravel: что пришло с системой, а что написал подрядчик

Многие сайты на PHP используют систему управления содержимым — «1С-Битрикс», WordPress, Joomla, Drupal, MODX, — торговую платформу вроде OpenCart или Magento либо каркас разработки: Laravel, Symfony, Yii. К ним добавляют модули, темы и собственный код. Соотношение этих частей устанавливают по конкретному проекту, а не оценивают заранее по размеру каталога.

Слои проекта разделяют по проверяемым признакам. Каталог сопоставляют с подтверждённой эталонной поставкой той же версии и выделяют совпавшие, изменённые и отсутствующие в эталоне файлы. Перед содержательным сравнением отдельно учитывают различия кодировок, переводов строк и служебных меток. Совпавшие файлы не являются собственным кодом подрядчика, но их установка и настройка могут входить в выполненные работы. Изменения поставки и неизвестные файлы исследуют отдельно: они могут быть доработками, библиотеками либо посторонними вставками. Вмешательство в ядро способно осложнить обновление, но его техническое и договорное значение устанавливают по конкретной системе и документам.

Эталонный дистрибутив используют как справочный источник и описывают его происхождение. Архивную страницу, по которой устанавливают фактическое содержание или период, предоставляют эксперту в установленном процессуальном порядке. Копию сайта, базу и журналы при судебной экспертизе также представляет назначивший орган; эксперт не собирает доказательственные объекты самостоятельно.

Сравнение с эталоном возможно не всегда. Дистрибутив коммерческой системы «1С-Битрикс» нужной версии может быть недоступен; многократно обновлённая установка — не соответствовать одной поставке; каркас разработки задаёт структуру, а у самописной системы эталона нет. Тогда происхождение и историю фрагментов оценивают по репозиторию, документам и иным представленным источникам. Эти данные не отождествляют код с конкретным автором.

Структура зависит от платформы. В «1С-Битрикс» часть решений выносят из ядра, а настройки и шаблоны могут храниться в базе. В WordPress исследуют темы, плагины, конфигурацию и таблицы содержимого. В проектах на Laravel или Symfony сопоставляют собственный код с зависимостями и каркасом. Файл блокировки фиксирует разрешённые версии пакетов и доступные ссылки на их исходные или собранные архивы, но фактический состав проверяют отдельно. Поэтому трудоёмкость определяют после изучения проекта.

Зависимости PHP обычно устанавливает Composer. Файл блокировки содержит разрешённые версии прямых и косвенных пакетов и сведения об источниках. Фактический каталог vendor сопоставляют с ним, а также фиксируют версию и конфигурацию Composer, параметры платформы, сценарии установки и доступные контрольные данные пакетов. Сами библиотеки не считаются собственным кодом подрядчика, но их подбор, интеграция и обновление могут входить в объём работ. Отсутствие файла блокировки ограничивает реконструкцию состава на спорную дату.

Версия PHP как самостоятельный предмет спора

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

Код для PHP 5.6 может отказаться работать на PHP 7: удалены старые расширения, изменена обработка ошибок, часть конструкций больше не поддерживается. В PHP 8 некоторые диагностические сообщения стали предупреждениями, а правила нестрогого сравнения строк с числами изменились. Проявление и запись предупреждений зависят от настроек; изменение результата расчёта может пройти без явного сообщения пользователю. Поэтому отказ связывают не только с кодом, но и с версией и конфигурацией среды.

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

Обновление платформы, коробочной системы и модулей требует технических действий. Эксперт описывает их наличие и результат, а вопрос о том, входили ли они в договорные обязанности, решает суд.

Что устанавливает эксперт по коду на PHP

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

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

Эксперт не оценивает добросовестность сторон, не толкует условия договора и не определяет размер убытков: это вопросы права и, при необходимости, отдельной экономической экспертизы.

Как проверяют соответствие заданию на развёрнутой копии

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

Сайт разворачивают, если материалы позволяют воспроизвести существенные части среды: версию PHP, расширения, веб-сервер, СУБД, права файлов, настройки, фоновые задания и внешние службы либо их заменители. Проект для PHP 7.4 на PHP 8 может отказаться работать по причинам, не связанным со спором, а отдельный дефект — проявиться только в исходной среде. Отличия стенда и недостающие компоненты перечисляют; невозможность развёртывания не приравнивают к дефекту программы.

Результат формулируют как проверяемый факт: требование выполнено, выполнено частично, не выполнено либо его невозможно проверить на представленных объектах. Указывают способ, условия и полученные данные. Существенность недостатка и влияние на приёмку определяет суд. Если язык не влияет на вопрос, подходит экспертиза соответствия работ техническому заданию.

Как считают объём работ и почему объём не равен деньгам

При споре о стоимости сначала определяют, какие части проекта созданы, настроены или интегрированы подрядчиком. Размер каталога сам по себе этого не показывает.

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

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

Степень готовности показывает, какая часть заказанного доведена до работоспособного состояния на спорную дату. Этому вопросу посвящена экспертиза степени готовности программного обеспечения.

Если репозитория нет, а всё выкладывали по FTP

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

Для реконструкции используют резервные копии провайдера, журналы FTP и панели управления, журналы веб-сервера, переписку с вложениями, документы хостинга и архивные страницы. Срок хранения зависит от тарифа и настроек. Журналы связывают событие с технической учётной записью, адресом и временем в пределах сохранённого периода, но не с человеком; веб-журнал подтверждает обращения лишь в этот период. Сведения из разных источников сопоставляют, а их происхождение и целостность проверяют отдельно.

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

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

Закрытый код и посторонние вставки: как их различают

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

Первое — коммерческая защита. В таких проектах, в частности, встречается ionCube PHP Encoder: преобразованные файлы исполняются при наличии совместимого загрузчика, а отдельные продукты используют лицензионные ограничения. Zend Guard характерен для старых проектов и не поддерживает PHP 7. Эксперт устанавливает средство и доступные метаданные защиты, перечень закрытых файлов, связанные функции и условия запуска. Если соответствующий читаемый исходник не обнаружен, фиксируют наличие только защищённой версии; полноту комплекта оценивают отдельно. Восстановление закрытого текста не проводят без отдельного законного основания и проверяемой методики.

Второе — признаки постороннего вмешательства. Веб-оболочка может быть коротким фрагментом либо сложным или обфусцированным набором файлов. Её отличают от штатного компонента по совокупности признаков: расположению, отсутствию в подтверждённой поставке, поведению, связям с другими файлами и журналами. При достаточных записях иногда удаётся установить способ и период проникновения; иначе фиксируют обнаруженные признаки и пределы датировки.

В споре о взломе одна сторона может связывать уязвимость с разработкой, а другая — с отсутствием сопровождения и обновлений. Эти версии проверяют по разным материалам и формулируют отдельными вопросами.

Если доступы удерживает подрядчик

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

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

Эксперт не обходит средства доступа, не восстанавливает чужие пароли и не работает с системой без законного основания. Основанием могут быть согласие владельца, договорное полномочие или процессуальное решение. Если нужные материалы находятся у другой стороны либо провайдера, вопрос об их истребовании решает суд; назначенный эксперт обращается за дополнительными материалами к назначившему органу.

Какие объекты исследуются на площадке с PHP

Перечень зависит от вопросов и устройства проекта. Обычно материалы делят на две группы.

Код, поставка и площадка

Основной материал — то, из чего сайт состоит и на чём работает:

• каталог сайта целиком, включая скрытые файлы и файлы настроек;
• описание зависимостей и файл блокировки версий, каталог установленных пакетов;
• дистрибутивы использованной коробочной системы, модулей и тем той же версии — для сравнения с поставкой;
• репозиторий системы контроля версий — чаще всего Git — со всеми доступными ветками, метками и достижимой историей изменений;
• настройки веб-сервера Apache или nginx и самого PHP: конфигурация, правила обработки адресов, список включённых расширений, версия;
• выгрузка базы данных MySQL, MariaDB или PostgreSQL: в ней могут храниться настройки, состояние и содержимое, влияющие на поведение сайта.

Следы работы и документы

Материалы, по которым восстанавливают ход событий и устанавливают требования:

• журналы веб-сервера, FTP и панели управления хостингом за спорный период;
• журналы ошибок PHP и журналы самой коробочной системы;
• резервные копии за период до спора — у хостинг-провайдера или у заказчика;
• техническое задание, приложения, акты, переписка сторон, задачи в системе учёта;
• лицензии на коробочную систему, платные модули и шаблоны с датами приобретения.

Что сохранить, пока площадка не изменилась

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

Копируйте только то, к чему у вас есть законное право доступа. Для чужой системы основанием могут быть согласие владельца, договорное полномочие или процессуальное решение. После назначения экспертизы дополнительные материалы и доступ предоставляют через назначивший орган.

Минимум такой:

• снимите каталог сайта архивом или специализированным средством копирования с заранее проверенными параметрами; какие файлы, ссылки, права и временные отметки сохранятся, зависит от формата и инструмента. Базу выгрузите способом, обеспечивающим согласованный снимок, либо зафиксируйте пределы согласованности и время операции; снимки файлов и базы синхронизируйте настолько, насколько позволяет площадка;
• сохраните опись: перечень файлов с размерами и датами изменения на момент снятия. Она нужна, чтобы позже было видно, что именно вы взяли и в каком состоянии;
• храните архив в зашифрованном хранилище с ограниченным доступом: в нём могут быть пароль к базе, ключи платёжных систем и персональные данные. Не собирайте клиентскую базу «на всякий случай» — объём копии должен соответствовать цели фиксации;
• письменно запросите у хостинг-провайдера доступные резервные копии за нужные периоды: срок хранения зависит от тарифа и настроек, а старые копии могут заменяться новыми;
• скачайте журналы веб-сервера, FTP и панели управления за весь доступный период;
• зафиксируйте окружение: версию PHP, список расширений, версию и настройки веб-сервера — снимком экрана панели управления хостингом или письмом от хостинг-провайдера. Не создавайте для этого новых файлов на спорной площадке: диагностическая страница может раскрыть пути, переменные окружения и секреты; если доступ не ограничить, её сможет открыть любой, кто знает адрес. Сама она также меняет сохраняемый каталог;
• посчитайте контрольную сумму каждого архива и запишите её отдельно. Она позволяет позднее проверить соответствие файла записанному значению, но сама по себе не подтверждает дату, источник и неизменность до расчёта. В Windows используют Get-FileHash архив.zip -Algorithm SHA256 или certutil -hashfile архив.zip SHA256; в Linux — sha256sum архив.zip, в macOS — shasum -a 256 архив.zip;
• составьте короткую записку: что именно скачано, с какого адреса и сервера, когда, под какой учётной записью, кто присутствовал.

Фиксацию поручают специалисту, у которого есть полномочия и опыт работы с площадкой: системному администратору, штатному разработчику или сотруднику провайдера. Если безопасного исполнителя нет, не экспериментируйте с работающим сайтом: позвоните по номеру 8 (800) 333-24-09, и мы поможем определить порядок действий. Важно сохранить происхождение и состав материалов, а не оформление отчёта.

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

Это не значит, что бизнес должен встать. Если сайт уже пришлось срочно чинить или восстанавливать после взлома, требование «ничего не трогать» задним числом бессмысленно: зафиксируйте нынешнее состояние, сохраните всё, что осталось от прежней версии, и запишите, что и когда вы меняли при восстановлении. После этого сайт обслуживают штатно, включая обновления безопасности.

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

Как передать копию сайта и не раскрыть лишнего

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

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

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

Соглашение с экспертом не определяет доступ других участников к материалам дела: порядок и ограничения зависят от процедуры и решений назначившего органа. Защищённое хранилище, носитель с описью или иной канал согласуют до отправки.

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

Порядок исследования сайта на PHP

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

1. Эксперт принимает материалы, фиксирует состав и контрольные суммы, описывает происхождение каждой копии.
2. Определяет систему, её версию и состав модулей; при возможности подбирает эталонные дистрибутивы.
3. Сопоставляет каталог с подтверждённой поставкой и выделяет совпавшие, изменённые и отсутствующие в ней файлы.
4. При достаточных материалах разворачивает сайт в изолированной среде и воспроизводит существенные параметры окружения.
5. Проверяет каждое требование выбранным способом и фиксирует результат вместе с условиями получения.
6. Проверяет возможные причины: настройки среды, действия третьих лиц и пользовательские данные.
7. Формулирует выводы в пределах вопросов, перечисляет ограничения и неустановленные обстоятельства.

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

Примеры вопросов эксперту по коду на PHP

Корректный вопрос называет объект, его состояние или период и проверяемый критерий. Для PHP это может быть адрес площадки и дата получения копии либо конкретный архив с контрольной суммой; критерием служит пункт технического задания или иной указанный документ. В судебной экспертизе окончательный круг вопросов определяет суд, а в других предусмотренных законом процедурах — назначивший орган или лицо. Эксперт действует в пределах специальных знаний и представленных материалов, а при неясности вопроса обращается к назначившему органу; помощь с формулировками возможна до назначения.

Ниже — примеры формулировок; подробные перечни под конкретные задачи собраны на страницах экспертизы качества исходного кода и экспертизы плагиата исходного кода.

1. Соответствует ли программное обеспечение, содержащееся в архиве с контрольной суммой SHA-256 …, требованиям пунктов … технического задания (приложение № … к договору от …)?
2. Какая система управления содержимым использована и какова её версия; какие файлы каталога совпадают с подтверждённой поставкой, какие изменены и какие в ней отсутствуют?
3. Каков объём программного кода в архиве … после отдельного выделения и оценки коробочной поставки, библиотек Composer и сгенерированных компонентов?
4. Содержится ли в файлах сайта программный код, не относящийся к штатной работе системы управления содержимым и обеспечивающий выполнение произвольных команд?
5. Имеются ли в файлах архива … и архива … совпадения программного кода; какие из них объясняются общей коробочной системой, библиотеками или типовыми конструкциями?
6. Позволяет ли комплект, переданный по акту от …, развернуть работоспособную копию сайта; если нет — каких компонентов недостаточно?

Форматы работы: суд, досудебная стадия, рецензия

Форматов несколько, и выбирают их по стадии спора:

• судебная экспертиза по определению суда или постановлению органа расследования — с предупреждением эксперта об уголовной ответственности за заведомо ложное заключение;
• внесудебное исследование по договору со стороной — до подачи иска или параллельно с ним;
• письменная консультация по материалам, когда нужно понять перспективу и правильно поставить вопросы;
• участие специалиста в судебном заседании для пояснений по проведённому исследованию;
• рецензирование чужого заключения — подробнее на странице рецензии на заключение о процессе разработки.

После назначения судебной экспертизы дополнительные выгрузки, журналы, доступ и вопросы передают через суд или орган расследования, а не напрямую эксперту. Назначенный эксперт не принимает дополнительные материалы непосредственно от сторон и не даёт им частных оценок по существу поручения. Если специалист раньше работал для одной из сторон, об этом сообщают при рассмотрении его кандидатуры; решение о назначении и отводе принимает назначивший орган.

От чего зависят стоимость и срок по проекту на PHP

Стоимость и срок определяют три обстоятельства. Первое — число слоёв: сайт на коробочной системе с двумя десятками модулей требует проверки поставок и изменений каждого компонента. Второе — сохранность окружения: срок развёртывания зависит от файлов, базы, версии PHP, расширений, настроек сервера и внешних служб. Третье — качество истории изменений: даты репозитория сопоставляют с журналами, резервными копиями и документами, поскольку их можно изменить. Кроме того, учитывают объём спорной части, число требований и вопросов, необходимость смежных специалистов. Ориентировочная стоимость судебной экспертизы — от 100 000 ₽, срок — от 10 рабочих дней; точные условия определяются после просмотра материалов.

Для первого обращения архивы не нужны. Назовите программу, опишите спор и перечислите имеющиеся документы и доступы. Позвоните по номеру 8 (800) 333-24-09 или оставьте заявку: мы определим, относится ли задача к нашей компетенции, предложим порядок фиксации и скажем, каких данных не хватает для расчёта стоимости.