📌 Введение: ПО как актив на десятилетия

• Программное обеспечение (ERP, CRM, мобильные приложения, веб-порталы) — это не «одноразовая покупка». Компании эксплуатируют код годами, наращивая функционал, подключая новые интеграции и обслуживая тысячи пользователей. Однако скрытые дефекты, заложенные на этапе разработки, могут сделать поддержку невозможной или привести к катастрофической утечке данных. 😰
• Согласно исследованию Standish Group, 60% бюджетов IT-подразделений уходит на поддержку legacy-кода (устаревшего ПО). Вот почему превентивная экспертиза процесса разработки (до того, как система перейдёт в режим долгосрочной эксплуатации) — это инвестиция в предсказуемость бюджета и безопасность. 🔒

🔐 Глава 1. Риски для безопасности данных (Data Security Risks)

Эти риски могут привести к утечке коммерческой тайны, персональных данных (нарушение 152-ФЗ), финансовым потерям и уголовной ответственности. ⚖️

1.1. Инъекции SQL и отсутствие валидации ввода

• Что это: Злоумышленник вводит вредоносный код в поле ввода (например, ‘ OR ‘1’=’1) и получает доступ к базе данных.
• Как выявляет эксперт: Статический анализ кода (scan for taint flow), динамическое тестирование (DAST — Dynamic Application Security Testing). 🕵️

1.2. Недостатки аутентификации и управления сессиями

• Что это: Пароли хранятся в открытом виде, отсутствует многофакторная аутентификация (MFA), сессионные токены передаются по HTTP (не HTTPS).
• Как выявляет эксперт: Аудит конфигураций, сниффинг трафика (Wireshark). 📡

1.3. Отсутствие шифрования персональных данных (нарушение 152-ФЗ)

• Что это: База данных (БД) с ПДн (паспорта, ИНН, адреса) хранится в открытом виде, диски не зашифрованы.
• Как выявляет эксперт: Проверка policy шифрования на уровне СУБД (Transparent Data Encryption — TDE), анализ дампов БД.

1.4. Зависимости с известными уязвимостями (CVE)

• Что это: Использование старых библиотек с дырами (например, Log4Shell в log4j).
• Как выявляет эксперт: Сканеры зависимостей (Snyk, OWASP Dependency Check). 🦠

📉 Глава 2. Риски для долгосрочной поддержки (Maintainability Risks)

Эти риски делают код «неподдерживаемым»: каждое изменение занимает недели вместо часов, а стоимость владения (TCO) растёт экспоненциально. 📊

2.1. «Запутанная архитектура» (Big Ball of Mud)

• Признаки: Отсутствие слоёв (presentation, business logic, data access), циклы зависимостей (A зависит от B, B зависит от A).
• Последствия: Невозможно добавить новый модуль без переписывания старого.

2.2. Высокое зацепление (High Coupling)

• Признаки: Один модуль «знает» детали реализации другого, изменения в модуле X ломают модуль Y.
• Последствия: Каждый релиз — это серия багов в неожиданных местах.

2.3. Отсутствие тестов (Low Test Coverage)

• Что это: Нет юнит-тестов, интеграционных тестов, e2e-тестов.
• Последствия: Каждое изменение приходится тестировать вручную (часы → дни). Разработчики боятся рефакторить.

2.4. «Dead code» («мёртвый» код)

• Признаки: Функции, которые никогда не вызываются, классы, не используемые в проекте.
• Риск: Новые разработчики тратят время на изучение неработающего кода, увеличивается когнитивная нагрузка.

📋 Глава 3. Примеры из практики (кейсы экспертизы)

Кейс №1: Утечка через SQL-инъекцию после 3 лет эксплуатации

Ситуация: CRM-система работала 3 года без видимых проблем. Внезапно Роскомнадзор оштрафовал компанию на 2 млн ₽ за утечку базы клиентов (150 000 записей). Внутренний аудит показал, что SQL-инъекция присутствовала в коде с момента запуска, но никто её не искал. 😱

Действия эксперта: Статический анализ кода (Python Django) выявил прямое встраивание параметров в SQL-запрос (cursor.execute(f»SELECT * FROM users WHERE id = {user_id}»)) — вместо параметризованных запросов (placeholders). 💡

Рекомендация: Использовать ORM (Object-Relational Mapping) с автоматическим экранированием.

Кейс №2: Вендор-лок-ин из-за проприетарного API

Ситуация: Компания решила сменить облачного провайдера (IaaS), но обнаружила, что 60% кода написано под AWS S3 API (проприетарные вызовы), которые не работают в Yandex Cloud без переписывания. 😨

Действия эксперта: Эксперт проанализировал код и выявил привязку к aws-sdk напрямую, а не через абстрактный слой (интерфейс).

Рекомендация: Внедрить паттерн Adapter (адаптер), который позволит в будущем переключаться между провайдерами.

Кейс №3: Отсутствие тестов привело к коллапсу после обновления

Ситуация: Разработчик добавил новую функцию в интернет-магазин, не написав тестов. При деплое полетела оплата (Payments API). Простой 8 часов, убытки 2 млн ₽. 😤

Действия эксперта: Эксперт выявил, что code coverage составлял 0% (юнит-тестов нет). После исправления «руками» гарантировать качество невозможно.

Рекомендация: Внедрить CI/CD (Continuous Integration/Continuous Deployment) с requirement на прохождение тестов (80% coverage). 💪

🛠 Глава 4. Как экспертиза помогает снизить риски (план действий)

📂 Глава 5. Какие материалы нужно предоставить эксперту

Рекомендация: Проводить экспертизу до того, как ПО перейдёт в фазу «долгосрочной поддержки». Оптимально — за 3–6 месяцев до окончания активной разработки.

💲 Глава 6. Стоимость и сроки (ориентиры на 2025 г.)

🎯 Заключение

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

• риски безопасности (SQL-инъекции, CVE, нарушения 152-ФЗ);
• риски поддержки (запутанная архитектура, отсутствие тестов, вендор-лок-ин).

Без экспертизы вы рискуете получить через 2–3 года «костыльный» монолит, который любой новый разработчик боится трогать, а каждый релиз — это хождение по тонкому льду. 😨

Для заказа экспертизы ПО обращайтесь в Союз «Федерация судебных экспертов» (сайт: https://lingex.ru/).