💻 Раздел 1. Сущность и правовая природа экспертизы программного обеспечения
- В эпоху тотальной цифровизации и перехода бизнес-процессов в виртуальное пространство программное обеспечение стало одним из самых ценных и в то же время уязвимых активов. Высокотехнологичные споры, связанные с нарушением авторских прав, некачественной разработкой или преднамеренным изменением исходного кода, требуют глубоких специальных знаний. Именно в таких ситуациях на помощь приходит независимая и судебная экспертиза программного обеспечения (ПО). Данный вид исследования представляет собой сложный научно-технический процесс, направленный на детальное изучение программных комплексов, их исходного кода, баз данных и сопутствующей документации.
- Главная цель, которую преследует экспертиза ПО, заключается в установлении объективной истины по делу. Это может быть связано с гражданскими спорами между заказчиком и разработчиком, арбитражными процессами о невыполнении условий договора или даже уголовными делами, где программный продукт выступает в качестве орудия преступления либо объекта посягательства. В рамках правового поля Российской Федерации данное исследование опирается на строгое законодательство, регулирующее экспертную деятельность. Эксперт, приступая к работе, берет на себя колоссальную ответственность за точность и объективность сделанных выводов, поскольку от его заключения зачастую зависит исход многомиллионных споров.
- Проведение таких изысканий требует не просто навыков программирования, а глубокого понимания архитектуры систем, методологий разработки и принципов построения алгоритмов. Исследованию могут подвергаться самые разнообразные объекты: от простейших мобильных приложений до сложных распределенных ERP-систем, управляющих промышленными гигантами. В процессе анализа специалисты сталкиваются с необходимостью декомпиляции, реверс-инжиниринга и семантического анализа текстов программ.
- Профессиональный подход к решению таких задач демонстрирует Союз «Федерация судебных экспертов», силами которого регулярно проводятся сложнейшие исследования в области информационных технологий. Накопленный опыт позволяет специалистам организации успешно справляться с любыми вызовами, которые ставит перед ними современная судебная и досудебная практика. Тщательное изучение каждого байта информации гарантирует, что итоговое заключение станет весомым аргументом в любой инстанции.
🔍 Раздел 2. Классификация объектов исследования в IT-экспертизе
Программное обеспечение как объект экспертного анализа крайне многогранно. Экспертам приходится иметь дело не с монолитным продуктом, а с целым комплексом взаимосвязанных элементов. Для систематизации экспертного процесса принято разделять объекты исследования на несколько ключевых㶪тей. Первой и самой важной категорией является исходный код программного продукта. Исходный текст, написанный на языках высокого или низкого уровня, представляет собой первооснову любого приложения, где заложены все алгоритмы, логические связи и функциональные возможности.
Второй важнейшей составляющей являются исполняемые файлы (бинарный код). Зачастую заказчик экспертизы или судебные органы не могут предоставить исходный код, так как он утерян или скрывается одной из сторон конфликта. В таких случаях эксперты вынуждены работать непосредственно с откомпилированными модулями, применяя специализированные программные инструменты для восстановления логики работы системы. Третий объект исследования — это структуры баз данных и само информационное наполнение. Базы данных хранят в себе колоссальные объемы коммерческой, персональной или технологической информации, и нарушение их целостности может привести к краху всего бизнеса.
📂 Кроме того, экспертному анализу обязательно подвергается сопутствующая техническая документация. К ней относятся:
Технические задания (ТЗ) на разработку программных продуктов;
Архитектурные описания систем (системные спецификации);
Руководства пользователя и администратора;
Акты приема-передачи выполненных работ и протоколы тестирования.
Нередко именно сопоставление реального функционала программы с требованиями, зафиксированными в техническом задании, позволяет выявить скрытые дефекты или намеренное невыполнение обязательств разработчиком. Комплексный подход к анализу всех перечисленных объектов позволяет сформировать полную и объективную картину состояния исследуемого программного продукта. Каждая деталь, от комментария в коде до структуры таблицы в базе данных, может стать ключом к разгадке причин технического сбоя или факта плагиата.
📋 Раздел 3. Ключевые задачи и цели проведения экспертизы программного обеспечения
Задачи, которые ставятся перед экспертом в области информационных технологий, определяются характером возникшего спора. В большинстве случаев они делятся на три крупные группы: установление факта контрафактности (плагиата), оценка качества выполненных работ по разработке ПО и определение причин нарушения работоспособности системы. Каждая из этих задач требует применения специфических методик и подходов, а также высочайшей квалификации исполнителя.
Установление факта заимствования или плагиата — одна из самых востребованных задач в практике. Эксперту необходимо определить, является ли исследуемое программное обеспечение самостоятельным продуктом или же оно было создано путем незаконного копирования чужого исходного кода. Для этого проводится глубокое сравнительное исследование, выявляются совпадения в архитектуре, названиях переменных, алгоритмах и даже в специфических ошибках, допущенных авторами.
🛠️ Если речь идет о спорах между заказчиком и интегратором, на первый план выходят задачи по оценке качества и полноты разработки:
Соответствует ли финальный продукт утвержденному техническому заданию;
Насколько стабильно функционирует система под целевой нагрузкой;
Имеются ли в программном коде критические уязвимости и недоработки;
Был ли соблюден согласованный стек технологий при создании продукта.
Еще одна важнейшая задача — это расследование инцидентов информационной безопасности и технических сбоев. В тех случаях, когда программный комплекс внезапно перестает функционировать, приводя к огромным убыткам предприятия, эксперт должен поминутно восстановить хронологию событий. Необходимо выяснить, был ли сбой следствием ошибки в коде, внешнего вредоносного воздействия или же деструктивных действий персонала. Решение этих задач требует от специалиста не только теоретических знаний, но и огромного практического опыта.
⚖️ Раздел 4. Законодательная база и правовые основания экспертной деятельности
Судебная и внесудебная экспертиза программного обеспечения не может проводиться хаотично, она жестко регламентирована нормами действующего законодательства. Основным нормативным актом, регулирующим данную сферу в Российской Федерации, является Федеральный закон № 73-ФЗ «О государственной судебно-экспертной деятельности в Российской Федерации». Несмотря на то, что закон изначально ориентирован на государственные экспертные учреждения, его ключевые принципы — законность, соблюдение прав и свобод человека, независимость эксперта, объективность, всесторонность и полнота исследований — в полной мере распространяются и на негосударственные организации.
В рамках гражданского, арбитражного или уголовного процесса назначение экспертизы регулируется соответствующими процессуальными кодексами (ГПК РФ, АПК РФ, УПК РФ). Суд или следователь выносят определение (постановление), в котором четко прописываются основания для проведения исследования, круг вопросов, требующих разрешения, а также материалы, предоставляемые в распоряжение эксперта. Важно помнить, что эксперт предупреждается об уголовной ответственности по статье 307 Уголовного кодекса РФ за дачу заведомо ложного заключения, что является мощным правовым гарантом объективности.
При проведении досудебных или внесудебных исследований основанием для работы эксперта служит договор между заказчиком (юридическим или физическим лицом) и экспертной организацией. Такое исследование часто называют экспертным исследованием или внесудебным заключением специалиста. Несмотря на отсутствие процессуального статуса судебного заключения, этот документ обладает серьезной юридической силой и может быть использован в качестве доказательства при подаче искового заявления в суд или для мирного урегулирования коммерческого спора. Своевременное обращение к квалифицированным юристам и техническим специалистам позволяет минимизировать правовые риски и защитить свои законные интересы.
📝 Раздел 5. Порядок подготовки документов для назначения экспертизы ПО
Успех проведения экспертизы программного обеспечения во многом зависит от того, насколько грамотно и полно подготовлена документальная база. Процесс сбора и систематизации документов — это ответственный этап, требующий предельной внимательности со стороны инициатора исследования. В первую очередь необходимо собрать все документы, регламентирующие взаимоотношения сторон в процессе создания или передачи программного продукта. К ним относятся договоры, дополнительные соглашения, спецификации и, самое главное, детальное техническое задание.
Техническое задание является основным мерилом качества работы программистов. Именно с ним эксперт будет сравнивать получившийся продукт, оценивая каждый пункт на предмет реализации и корректности работы. Помимо договора, необходимо предоставить все имеющиеся акты выполненных работ, включая промежуточные. Если в процессе разработки велась официальная переписка (в том числе по электронной почте или в специализированных таск-трекерах, если это предусмотрено договором), ее также следует нотариально заверить и приобщить к материалам дела. Переписка может пролить свет на согласование изменений в архитектуре ПО, которые не были зафиксированы в дополнительных соглашениях.
📁 Примерный перечень документов, необходимых для передачи эксперту, выглядит следующим образом:
Основной договор на разработку (модернизацию, внедрение) программного обеспечения со всеми приложениями;
Официально утвержденное техническое задание (ТЗ) или частное техническое задание (ЧТЗ);
Протоколы тестирования, отчеты об ошибках (баг-репорты), акты приемки этапов работ;
Проектная и архитектурная документация, схемы баз данных, описания API-интерфейсов;
Пользовательские инструкции, руководства по развертыванию и администрированию системы.
Важно понимать, что отсутствие какого-либо важного документа может существенно ограничить возможности эксперта или сделать невозможным ответ на некоторые поставленные вопросы. Поэтому перед направлением материалов на экспертизу рекомендуется пройти предварительную консультацию со специалистами, которые помогут сформировать исчерпывающий пакет документов. Компетентную помощь в этом вопросе всегда готовы оказать сотрудники Союза «Федерация судебных экспертов», которые подскажут, какие именно бумаги будут иметь решающее значение для исследования.
💾 Раздел 6. Правила подготовки и передачи материальных объектов и исходного кода
Помимо бумажной и электронной документации, эксперту необходимо предоставить сам объект исследования — программный продукт в той форме, которая позволит провести его детальный анализ. Если речь идет об исходном коде, то он должен быть передан в полном объеме, без изъятий и модификаций. Передача кода может осуществляться на физических носителях (флеш-накопители, внешние жесткие диски) или путем предоставления доступа к репозиториям (например, GitLab, GitHub, Bitbucket). При передаче прав доступа важно зафиксировать состояние репозитория на конкретную дату и время, чтобы исключить возможность внесения изменений в процессе проведения экспертизы.
Если предметом спора является работа веб-сервиса или сложной корпоративной системы, развернутой на серверах, эксперту может потребоваться доступ к серверной инфраструктуре. В идеале создается полная копия (дамп) виртуальной машины или сервера, на которой функционирует исследуемое ПО. Это позволяет эксперту работать в изолированной среде, не опасаясь нарушить бизнес-процессы действующего предприятия и гарантируя неизменность исходных данных. Все передаваемые физические носители должны быть надлежащим образом упакованы, опечатаны и подписаны сторонами или уполномоченными лицами.
🔒 При подготовке материальных компонентов важно соблюдать следующие правила информационной безопасности и процессуальной чистоты:
Фиксация контрольных сумм (хеш-функций типа MD5, SHA-256) всех передаваемых файлов и архивов;
Использование сертифицированных и чистых от посторонней информации носителей данных;
Составление подробного акта приема-передачи с указанием наименований, размеров и дат изменения файлов;
Обеспечение сохранности логической структуры баз данных при выгрузке (создание корректных бэкапов).
Соблюдение этих строгих правил исключает любые сомнения со стороны оппонентов в суде относительно подлинности и неизменности исследуемых материалов. Если эксперт получит поврежденную базу данных или неполный исходный код, он не сможет провести полноценный анализ, что затянет сроки разбирательства и увеличит финансовые издержки сторон. Профессиональный подход к фиксации цифровых следов является залогом получения легитимного экспертного заключения.
🧠 Раздел 7. Методология и инструментарий экспертного исследования программных продуктов
Методология экспертизы программного обеспечения базируется на сочетании классических экспертных подходов и современных инженерных практик в области информационных технологий. Эксперт не может ограничиваться просто визуальным осмотром интерфейса программы; его работа лежит гораздо глубже, на уровне алгоритмов и машинных инструкций. Весь экспертный процесс можно разделить на два основных метода исследования: статический и динамический анализ.
Статический анализ предполагает изучение исходного кода или бинарных файлов без их фактического запуска. На этом этапе эксперт применяет специализированные программные инструменты — статические анализаторы кода, которые позволяют автоматически находить уязвимости, недоработки, заимствования и несоответствия стандартам кодирования. Также в рамках статического анализа проводится семантический и структурный анализ текстов программ, выявляются идентичные блоки кода в спорах об авторских правах. Этот метод требует от эксперта высочайшей концентрации и глубоких знаний синтаксиса конкретных языков программирования.
🔄 Динамический анализ, напротив, подразумевает исследование программного обеспечения непосредственно в процессе его выполнения. Для этого эксперт разворачивает исследуемое ПО в контролируемой тестовой среде (песочнице) и проводит серию тестов:
Функциональное тестирование — проверка соответствия реального поведения программы заявленным требованиям;
Нагрузочное тестирование — оценка стабильности системы при пиковых нагруках и больших объемах данных;
Стресс-тестирование — выявление критических точек, при которых происходит отказ системы;
Регрессионное тестирование и анализ логов (журналов регистрации событий) для поиска скрытых ошибок.
Помимо этого, при отсутствии исходного кода активно применяется метод обратной разработки (реверс-инжиниринг). С помощью декомпиляторов и отладчиков эксперты восстанавливают исходную логику работы программы из ее исполняемых файлов. Использование столь мощного и разнообразного инструментария позволяет специалистам получать неопровержимые доказательства, которые невозможно оспорить стандартными методами. Каждое действие эксперта фиксируется в протоколах исследования, что обеспечивает прозрачность и проверяемость полученных результатов.
❓ Раздел 8. Формулирование вопросов для экспертизы: правила и типичные ошибки
Правильная постановка вопросов перед экспертом — это ключевой фактор, определяющий полезность будущего экспертного заключения для судебного процесса. Вопросы должны быть четкими, конкретными, не допускающими двоякого толкования и, самое главное, они должны лежать строго в рамках компетенции эксперта. Суд не примет во внимание ответы на вопросы правового характера (например, «Имеет ли место мошенничество со стороны разработчика?»), так как правовая оценка является исключительной прерогативой судебных органов. Эксперт отвечает только на технические вопросы.
Типичной ошибкой является формулировка излишне общих вопросов, например: «Соответствует ли программа всем требованиям?». Такой вопрос вынуждает эксперта проводить колоссальный объем работы, исследуя даже те аспекты системы, которые не имеют отношения к сути спора, что лавинообразно увеличивает стоимость и сроки проведения экспертизы. Вопросы должны быть локализованы. Если заказчика не устраивает скорость работы модуля отчетов, то и вопрос должен касаться конкретно производительности этого модуля и причин ее снижения.
💡 Рассмотрим примеры грамотно сформулированных вопросов для различных ситуаций:
Содержит ли исходный код программного продукта «А» фрагменты исходного кода, заимствованные из программного продукта «Б»? Если да, то каков их объем и процентное соотношение?
Соответствует ли разработанная информационная система требованиям раздела № 4 Технического задания № 1 от 12.12.2025 года? Если нет, то в чем именно заключаются несоответствия?
Имеются ли в программном обеспечении банкомата программные закладки или недокументированные возможности, приведшие к несанкционированной выдаче денежных средств?
Является ли причиной сбоя в работе СУБД ошибка в проектировании архитектуры базы данных или некорректные действия обслуживающего персонала?
Формулирование вопросов лучше всего осуществлять совместно с экспертом в ходе предварительной консультации. Специалист подскажет, как правильно облечь техническую претензию в строгую экспертную формулировку, на которую можно дать однозначный и аргументированный ответ. Это позволит сэкономить время, деньги и избежать ситуации, когда готовое заключение оказывается бесполезным для судебного разбирательства из-за некорректно поставленных вопросов.
🏢 Раздел 9. Практический опыт проведения экспертиз программного обеспечения
Теоретические выкладки и знание нормативной базы приобретают истинную ценность только тогда, когда они подкреплены реальным практическим опытом решения сложных и неординарных задач. В сфере исследования информационных технологий каждый случай уникален, и шаблоны здесь не работают. Все приведенные ниже примеры успешного урегулирования споров взяты из реальной экспертной практики.
💼 Кейс 1
В Союз «Федерация судебных экспертов» обратилась крупная торговая компания, заказавшая разработку индивидуальной CRM-системы. Программисты передали продукт с задержкой и утверждали, что он полностью готов к эксплуатации. Однако при попытке внедрения система постоянно давала сбои, теряя данные клиентов. Проведенная комплексная экспертиза исходного кода и архитектуры базы данных выявила, что разработчики использовали устаревшие библиотеки с критическими уязвимостями, а сама структура базы данных не была оптимизирована под параллельные запросы. На основании экспертного заключения, доказавшего некачественность разработки, заказчик успешно вернул через арбитражный суд всю сумму аванса и взыскал неустойку.
📱 Кейс 2
Данный случай был связан с защитой интеллектуальной собственности. Известный отечественный разработчик мобильных приложений обнаружил в магазине приложений продукт конкурента, который по своему функционалу и интерфейсу до боли напоминал его собственную запатентованную разработку. В рамках судебного разбирательства экспертам Союза «Федерация судебных экспертов» удалось получить доступ к исходным кодам обоих приложений. Несмотря на то, что ответчик попытался запутать следы, изменив названия переменных и структуру папок (провел обфускацию кода), статический и семантический анализ выявил стопроцентное совпадение алгоритмов шифрования и обработки данных. Факт незаконного заимствования авторских прав был полностью доказан.
🏭 Кейс 3
Третий случай касался расследования масштабного технического сбоя на автоматизированном производственном предприятии. Из-за внезапной остановки управляющего софта встала конвейерная линия, что повлекло колоссальные убытки. Руководство завода подозревало уволенного накануне системного администратора. Анализ логов серверов и динамическое исследование программной среды, проведенные экспертами организации, показали, что причиной инцидента стала не диверсия, а скрытая логическая ошибка (баг) в самом заводском программном обеспечении, которая сработала при наступлении определенной календарной даты. Это позволило снять обвинения с невиновного человека и перенаправить претензии поставщику оборудования.
💳 Кейс 4
Четвертый случай затронул сферу финансовых технологий. Микрофинансовая организация столкнулась с тем, что их скоринговая система (программа, оценивающая платежеспособность заемщиков) начала одобрять кредиты лицам с явно плохой кредитной историей. В ходе проведения экспертизы специалисты Союза «Федерация судебных экспертов» провели тщательный аудит кода и обнаружили несанкционированное внедрение — так называемую «программную закладку». Кто-то из действующих разработчиков намеренно встроил в код обходной алгоритм для конкретных номеров паспортов. Благодаря оперативной работе экспертов, уязвимость была локализована, а данные злоумышленника переданы в правоохранительные органы.
🌐 Кейс 5
Пятый случай был связан со спором вокруг государственного контракта на модернизацию портала государственных услуг одного из регионов. Государственный заказчик отказывался подписывать акты, ссылаясь на то, что сайт не выдерживает нормативного количества одновременных пользователей. Исполнитель же утверждал, что проблема кроется в слабых серверах самого заказчика. Эксперты Союза «Федерация судебных экспертов» провели независимое нагрузочное и стресс-тестирование системы на изолированном стенде. Было доказано, что падение производительности происходило из-за неоптимальных поисковых запросов в коде сайта, а не из-за аппаратной части. Исполнителю пришлось за свой счет перерабатывать архитектуру поискового модуля.
📑 Раздел 10. Структура и содержание итогового экспертного заключения
Результатом любого экспертного исследования является официальный документ — заключение эксперта (или заключение специалиста). Этот документ имеет строго определенную структуру, установленную законом, и должен быть понятен не только программистам, но и судьям, адвокатам, коммерческим директорам. Заключение состоит из трех основных частей: вводной, исследовательской и выводы. Каждая часть выполняет свою важнейшую функцию в процессе доказывания.
Вводная часть содержит формальные данные: дату и место составления документа, основания для проведения экспертизы, сведения об экспертной организации и самом эксперте (его образовании, специальности, стаже работы). Здесь же приводится точный список всех поступивших на исследование материалов, документов и носителей информации, а также формулируются вопросы, поставленные перед специалистом. В этой части судебный эксперт обязательно ставит свою подпись под подпиской о предупреждении об уголовной ответственности.
📊 Исследовательская часть — это самый объемный и технически насыщенный раздел, в котором подробно описывается весь ход работы:
Описание методов, методик и программных средств, примененных в ходе анализа;
Пошаговый процесс изучения исходного кода, баз данных или проведения тестирования;
Фиксация всех промежуточных результатов с приложением скриншотов, листингов кода и графиков;
Аналитическое сопоставление полученных данных с требованиями нормативных документов и ТЗ.
Заключительная часть содержит четкие, краткие и недвусмысленные ответы на поставленные вопросы. Выводы эксперта должны логически вытекать из исследовательской части. Они не могут быть вероятностными или предполагаемыми; закон требует категоричности и определенности. К заключению прилагаются дипломы и сертификаты эксперта, подтверждающие его квалификацию, а также все материалы, иллюстрирующие ход исследования. Данный документ является официальным источником доказательств и имеет решающее значение при вынесении судебного вердикта.
💲 Раздел 11. Факторы, влияющие на стоимость и сроки проведения экспертизы ПО
Экспертиза программного обеспечения относится к категории наиболее сложных и дорогостоящих видов инженерных исследований. Это связано с высокой стоимостью труда квалифицированных IT-специалистов и уникальностью используемого инструментария. Стоимость и сроки проведения экспертизы никогда не бывают фиксированными, они рассчитываются индивидуально для каждого конкретного случая на основе анализа предоставленных материалов и объема предстоящих работ.
Одним из главных факторов является объем исследуемого объекта. Очевидно, что анализ простейшего лендинга займет значительно меньше времени, чем исследование распределенной банковской системы с миллионами строк исходного кода и сотнями таблиц в базе данных. Вторым фактором выступает количество и сложность поставленных вопросов. Чем больше аспектов системы требует изучения (например, одновременно и проверка на плагиат, и аудит безопасности, и оценка производительности), тем выше будет итоговая стоимость работы.
⏱️ На сроки и ценообразование также существенно влияют следующие обстоятельства:
Язык программирования и используемый стек технологий (редкие и устаревшие языки требуют привлечения узкопрофильных экспертов);
Качество и полнота предоставленной технической документации (отсутствие ТЗ усложняет процесс верификации);
Необходимость выезда эксперта на объект для снятия дампов с серверов или осмотра оборудования;
Срочность проведения исследования, обусловленная процессуальными сроками судебного разбирательства.
Попытка сэкономить на экспертизе, обращаясь к сомнительным специалистам или фрилансерам, часто приводит к плачевным результатам: суды отвергают непрофессиональные заключения из-за нарушения процессуальных норм или поверхностного анализа. Инвестиции в качественную экспертизу от авторитетной организации всегда оправдывают себя, так как они обеспечивают надежную защиту бизнеса от колоссальных финансовых и репутационных потерь.
🛡️ Раздел 12. Рекомендации по минимизации рисков при разработке и внедрении ПО
Чтобы минимизировать вероятность возникновения судебных споров и необходимости проведения дорогостоящих экспертиз, компаниям следует придерживаться превентивного подхода при ведении IT-проектов. Большинство конфликтов между заказчиками и разработчиками возникает из-за банального недопонимания, отсутствия четких договоренностей на берегу и халатного отношения к ведению документации. Грамотный менеджмент и юридическая чистота процессов способны избавить от множества проблем в будущем.
Первое и самое главное правило — никогда не начинать разработку без детального, детально прописанного технического задания. Фразы в ТЗ вроде «интерфейс должен быть красивым, а система должна работать быстро» недопустимы. Все требования должны быть измеримыми. Скорость отклика страницы должна быть зафиксирована в миллисекундах при определенном количестве одновременных пользователей, а дизайн должен опираться на утвержденные прототипы и брендбук. Чем подробнее ТЗ, тем проще будет доказать свою правоту в случае конфликта.
📈 В процессе реализации проекта рекомендуется строго соблюдать следующие правила:
Фиксировать любые изменения требований в письменной форме путем подписания дополнительных соглашений;
Использовать системы контроля версий и регулярно проводить независимый аудит кода (code review);
Проводить промежуточное тестирование каждого этапа работ с составлением официальных баг-репортов;
Не подписывать акты приема-передачи до фактической проверки работоспособности всего заявленного функционала.
Если же конфликтная ситуация все-таки возникла и мирным путем решить ее не удается, не стоит затягивать время. Своевременное обращение к независимым экспертам позволит зафиксировать состояние программного продукта на момент спора, что не позволит недобросовестному контрагенту задним числом изменить код или уничтожить следы своей некомпетентности. Превентивный аудит и готовность к защите своих прав — основа безопасности любого цифрового бизнеса.
Полную контактную информацию, телефон и адрес офиса, а также более подробную информацию по вашему вопросу вы можете найти на нашем официальном сайте ✅ https://krimexpert.ru
Задавайте любые вопросы