Что проверить в коде перед передачей проекта клиенту

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

Почему это важно

Момент передачи проекта клиенту — это точка, в которой разработчик перестаёт контролировать контекст. Код, который «работал у нас», оказывается в другой инфраструктуре, с другими настройками среды, с другой командой поддержки. Именно здесь всплывают захардкоженные ключи, незакрытые CORS-политики, dev-флаги в продакшне и зависимости с уязвимостями, которые никто не проверял с начала проекта.

По данным Cortex, 98% технических руководителей сталкивались с серьёзными последствиями несоблюдения production-readiness стандартов [3]. Типичные причины — не экзотические атаки, а банальные: последние изменения без code review, непоследовательный version control, шаги, которые «выпали» в спешке перед дедлайном.

В эпоху AI-кодинга проблема стала острее. Veracode проанализировал код более 100 LLM на 80 реальных задачах и зафиксировал: ИИ генерирует код с уязвимостями в 45% случаев [2]. Исследователи OX Security, изучив 300+ репозиториев, сделали вывод: AI-код не более уязвим построчно, чем человеческий, — проблема в скорости. Bottlenecks в виде code review, командного надзора и дебага попросту убраны [4]. Код, на написание которого раньше уходили месяцы, теперь деплоится за дни — и нередко без того, чтобы кто-то задал вопрос «а это вообще безопасно?»

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

1. Секреты и credentials: самый недооценённый риск

Почему это первый пункт

В 2025 году в публичных GitHub-репозиториях появилось 28,65 миллиона новых захардкоженных секретов — рост на 34% по сравнению с предыдущим годом [1]. GitHub в собственном security-отчёте насчитал 39 миллионов утечек credentials за 2024-й [5]. Академическое исследование, опубликованное на IEEE S&P 2025, проанализировало более 80 миллионов файлов и пришло к выводу: до 30% проектов в зоне риска [1].

Отдельно настораживает тренд: AI-assisted коммиты «текут» секретами в 3,2 раза чаще базового уровня [1]. Инструменты вроде Cursor замечены в отправке содержимого .env-файлов на серверы для автодополнения, даже когда файлы добавлены в .cursorignore [1].

Последствия конкретны. В январе 2024 года токен аутентификации сотрудника Mercedes-Benz обнаружился в публичном репозитории GitHub: он давал неограниченный, немониторируемый доступ к внутреннему GitHub Enterprise Server компании [6]. В мае 2024 года исследователи из группы Rabbitude обнаружили в коде устройства Rabbit R1 захардкоженные API-ключи: среди них — ключ ElevenLabs с правами администратора, открывавший доступ к истории всех TTS-запросов всех устройств [7]. Ключи оставались валидными более месяца после того, как Rabbit Inc. была уведомлена об инциденте.

Что проверять

Перед передачей проекта необходимо пройтись по следующему списку:

1. Поиск по паттернам в коде и истории коммитов: password, secret, api_key, token, private_key, access_key, client_secret. Git-история помнит всё — даже если в последнем коммите секрет убран, он может присутствовать в более ранних.
2. Проверка .env-файлов: не попали ли в репозиторий, корректно ли прописаны в .gitignore.
3. Конфигурационные файлы: config.yaml, appsettings.json, application.properties, web.config — частые места размещения production credentials.
4. Инфраструктурные файлы: docker-compose.yml, Dockerfile, Helm values, Terraform-конфиги.
5. CI/CD-файлы: .github/workflows/, .gitlab-ci.yml, Jenkinsfile — нередко содержат инлайн-секреты.
6. Мобильные приложения: бинарные файлы, APK и IPA поддаются реверс-инжинирингу. Захардкоженные AWS-ключи были обнаружены в iOS-приложениях с сотнями тысяч загрузок [8].

Для автоматизации подходят: git-secrets, gitleaks, truffleHog, detect-secrets. Эти инструменты стоит встроить в pre-commit hook и в CI-пайплайн, а не запускать однократно перед сдачей.

Все production-секреты должны жить в secret management-системах: HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault или аналогах — и инжектироваться в runtime, а не храниться в репозитории.

2. Debug-код, тестовые данные и dev-режим

Что остаётся в коде после разработки

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

Что конкретно нужно найти и убрать или заблокировать в production-сборке:

1. console.log, console.debug, print(), var_dump(), dd() — оставлять следует только явные console.error для обработки ошибок.
2. Закомментированный код — мёртвый код, который «на всякий случай» оставили в репозитории. Он создаёт путаницу при поддержке и нередко содержит старые credentials или небезопасные паттерны.
3. TODO и FIXME без привязки к трекинговому тикету — это технический долг, который нужно задокументировать, а не прятать в комментариях.
4. Тестовые учётные записи и тестовые данные в production-базе: admin/admin, test@test.com, фиктивные платёжные данные.
5. Флаги feature flags или environment variables, которые переключают приложение в debug-режим: DEBUG=True, APP_ENV=development, ENABLE_DEV_TOOLS=true.
6. Хардкод localhost-адресов, внутренних IP и портов в конфигурации, ориентированной на production.

Для фронтенда в Next.js, React Native, Angular существуют конфигурационные опции (compiler.removeConsole, babel-plugin-transform-remove-console), которые автоматически убирают логи в production-сборке [9]. Это не замена ревью, но полезный слой автоматизации.

3. Зависимости: уязвимости и лицензии

Supply chain как основной вектор атаки

В OWASP Top 10 2025 появилась новая категория: A03 — Software Supply Chain Failures [10]. В опросе сообщества 50% респондентов назвали её угрозой номер один. 80–90% современного кода состоит из зависимостей [11]. Атакующие давно поняли: гораздо эффективнее компрометировать библиотеку, которой доверяют тысячи команд, чем атаковать каждую из них напрямую.

Veracode фиксирует: 70% критического security debt происходит из стороннего кода [12].

Что проверить перед передачей:

1. Прямые и транзитивные зависимости на наличие CVE. Транзитивные зависимости — это зависимости ваших зависимостей. Они часто остаются вне поля зрения, но именно через них произошли некоторые из самых громких инцидентов. Инструменты: npm audit, pip-audit, OWASP Dependency-Check, Snyk, Trivy.
2. Устаревшие и unmaintained пакеты — библиотека, последний коммит которой датирован 2018 годом, вероятно, не получит патч при обнаружении новой CVE. OWASP прямо указывает CWE-1104 (Use of Unmaintained Third Party Components) как типичную причину supply chain failures [10].
3. Lock-файлы — package-lock.json, yarn.lock, Pipfile.lock, poetry.lock, Gemfile.lock должны быть в репозитории и актуальными. Без них сборка нестабильна: одна и та же команда может установить разные версии в разное время.
4. Dependency confusion — проверить, нет ли внутренних пакетов с теми же именами, что у публичных, без правильной конфигурации реестра. Это классический вектор: публичный реестр перебивает внутренний.
5. Лицензии. Открытый исходный код занимает до 90% современного стека [13], и каждый компонент поставляется с лицензией. Copyleft-лицензии (GPL, AGPL) требуют раскрытия производного кода. При передаче продукта клиенту вы фактически «распространяете» ПО — и GPL-обязательства активируются. В 2024 году суд в деле SFC v. Vizio подтвердил, что потребители вправе принудительно исполнять GPL как третьи лица-бенефициары [14]. Для сканирования лицензий: license-checker, FOSSology, AboutCode ScanCode, SonarQube SCA.

Отдельного внимания заслуживает AGPL: в отличие от GPL, она активируется не только при распространении бинарника, но и при использовании ПО через сеть (SaaS-сценарий). Если клиент получает продукт, в котором есть AGPL-зависимость, он может быть обязан открыть свой код.

4. Безопасность: конфигурация, аутентификация, CORS

Почему «работает» не равно «безопасно»

OWASP Secure Coding Practices Quick Reference Guide — технологически нейтральный набор практик, который применим к любому SDLC [15]. Ключевые классы уязвимостей, которые нужно проверить перед передачей:

Инъекции и валидация входных данных

Параметризованные запросы вместо конкатенации строк в SQL. Санитизация пользовательского ввода на уровне сервера. Экранирование вывода в HTML-контексте для защиты от XSS.

Аутентификация и авторизация

• Пароли хранятся в виде salted hash, не plain text и не MD5.
• Принцип наименьших привилегий: сервисные аккаунты, API-ключи, роли в БД имеют только необходимые права.
• Токены с коротким сроком жизни, refresh-механизм настроен корректно.
• Нет дефолтных credentials (admin/admin, root/root).
• Тестовые bypass-механизмы аутентификации удалены из кода.

CORS

Это один из наиболее типичных примеров «работает в dev, сломано в prod». Анализ более 100 000 веб-приложений в 2025 году показал: 35% имели хотя бы одну CORS-misconfiguration, которую можно было эксплуатировать для кражи credentials или утечки данных [16]. CORS-ошибки входят в категорию Security Misconfiguration (#5 в OWASP Top 10).

Что проверить:

• Access-Control-Allow-Origin: * с Access-Control-Allow-Credentials: true — опасная комбинация.
• Origin reflection: сервер зеркально отражает любое значение заголовка Origin без валидации.
• CORS-политика прописана явным whitelist доменов, а не regex с уязвимыми паттернами вроде .*example.com (сматчит evilexample.com).

HTTP security headers

Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security, Referrer-Policy — минимальный набор, который должен присутствовать в production. Для проверки: securityheaders.com.

Конфигурация среды

• Режим отладки выключен (DEBUG=False).
• Error pages не отдают stack trace в продакшне.
• Директории с загрузками не имеют права на исполнение файлов.
• Неиспользуемые endpoints и features отключены.

5. Тесты: что покрыто, что нет

Тесты — это не только «зелёный CI»

Перед передачей проекта важно не просто убедиться, что тесты проходят, но и понять, что именно они покрывают. Тесты, написанные только для «happy path», не проверяют поведение системы при неожиданных входных данных, граничных условиях и сбоях.

Что проверить:

1. Покрытие бизнес-логики — ключевые пути (оплата, регистрация, аутентификация, критичные бизнес-операции) должны иметь тесты, которые команда клиента сможет понять и расширить.
2. Граничные случаи и обработка ошибок — null, пустые коллекции, граничные значения (min/max), недоступность внешних сервисов.
3. Тесты запускаются в изолированной среде, не зависят от production-данных и внешних сервисов без mock.
4. Тестовые среды и конфигурации задокументированы — команда клиента должна уметь воспроизвести тестовый прогон.
5. Known failures и пропущенные тесты (skip, xfail, pending) зафиксированы в трекере, а не скрыты в коде без объяснения.

6. Документация: то, что клиент получает вместе с кодом

Недокументированный код — это форма технического долга

Код, который работает, но не документирован, заставляет следующую команду тратить время на обратную инженерию логики. Это прямые затраты клиента. Согласно рекомендациям практиков по software handover, отсутствие документации — одна из наиболее частых причин friction при передаче проекта [17].

Что должно быть в пакете передачи:

1. README с актуальными инструкциями по установке, запуску и первичной настройке.
2. Архитектурная схема: структура компонентов, взаимодействие сервисов, внешние интеграции.
3. Описание API: эндпоинты, форматы запросов/ответов, коды ошибок, лимиты, версионирование. OpenAPI/Swagger-спецификация, если используется REST.
4. Список сторонних зависимостей и интеграций с пояснением: зачем, как обновлять, какие есть риски.
5. Руководство по деплою: шаги, переменные окружения, требования к инфраструктуре.
6. Известный технический долг — явный список с контекстом. Это не слабость, это честность. Команда, которая получает проект, должна знать, какие shortcut'ы были сделаны и почему. Скрытый техдолг всегда обнаруживается — но уже в production и уже за счёт клиента.
7. Инструкции по локальному запуску: «новый разработчик должен уметь поднять среду за 30 минут» — разумный ориентир.

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

7. AI-код: специальный режим внимания

Почему AI-генерированный код требует отдельного пункта

Если проект написан с активным использованием AI-инструментов (GitHub Copilot, Cursor, Claude и других), к стандартному чек-листу добавляется дополнительный уровень внимания. Исследователи из Y Combinator фиксируют, что 25% стартапов Winter 2025 cohort имеют кодовую базу, которая на 95% сгенерирована AI [18]. Сканирование около 5 600 vibe-coded приложений выявило более 2 000 уязвимостей и более 400 обнажённых секретов [18].

Специфические риски AI-кода:

• Функциональность без security constraints. AI решает задачу, которую ему поставили, — а security требования нужно формулировать явно. «Напиши endpoint для загрузки файлов» без уточнений вероятно даст код без валидации типов, проверки размера и контроля прав доступа.
• Package hallucinations. AI может ссылаться на несуществующие npm/PyPI-пакеты. Их нередко успевают зарегистрировать злоумышленники. Все зависимости нужно проверять на существование в официальных реестрах.
• Повторное использование шаблонов с уязвимостями. Если обучающие данные содержали небезопасные паттерны, AI их воспроизводит.
• Vibe Security Radar от SSLab Georgia Tech за первые три месяца 2026 года зафиксировал 56 подтверждённых уязвимостей в AI-генерированном коде — больше, чем за весь 2025 год [19].

CSET Georgetown University прямо рекомендует: существующие secure software development practices и NIST Cybersecurity Framework применимы ко всему коду, независимо от того, кто его написал — человек или модель [20]. Проверка перед production обязательна.

Именно для таких сценариев — когда AI ускорил написание кода, но контроль изменений не успел вырасти с той же скоростью — существует подход, который реализует HighVibe: анализ конкретных изменений в коде, конфигурации и зависимостях до merge и release, с фокусом на то, что действительно критично.

8. Инфраструктура и среды

То, что не в коде, но уходит вместе с проектом

Передача проекта — это не только код. Это ещё доступы, конфигурация инфраструктуры и понимание того, что где развёрнуто.

1. Актуальные credentials переданы клиенту через защищённый канал (password manager, secrets vault — не email и не Slack).
2. Права разработческой команды на production-окружение отозваны или переданы.
3. Переменные окружения задокументированы: какие нужны, какие обязательны, каков их формат.
4. Резервные копии настроены и проверены — клиент понимает, как они работают.
5. Мониторинг и алерты настроены — кто получает уведомления и по каким каналам.
6. Инструкции по ротации секретов: когда и как менять ключи и пароли.

Распространённые ошибки при передаче

«Мы не успели дописать документацию» — документация, которую пишут в последний день, обычно описывает только «счастливый путь» и не отражает реальных edge cases. Это системная проблема, а не вопрос одного спринта.

«Тесты зелёные — значит, всё хорошо» — тесты показывают, что то, что тестировалось, работает так, как ожидалось. Они не показывают, что всё задокументировано, что зависимости безопасны и что нет захардкоженных ключей.

«Мы убрали секреты из последнего коммита» — Git-история не перезаписывается стандартными коммитами. Для удаления секрета из истории нужен git filter-branch или BFG Repo-Cleaner, плюс принудительный push. Убирать нужно и ротировать сам ключ.

«Клиент всё равно сразу наймёт свою команду» — новая команда, получившая недокументированный проект с техдолгом без описания и зависимостями без lock-файлов, первым делом потратит время на разбор того, что за что отвечает. Это деньги клиента, не ваши — но это ваша репутация.

«AI написал, значит, проверено» — функционально работающий код не является безопасным по умолчанию. Особенно если security-требования не были частью промпта.

Практический decision framework: что блокирует передачу

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

Блокируют передачу (критично — исправить до сдачи):

• Захардкоженные production credentials, API-ключи, пароли (в том числе в истории git).
• Зависимости с CVE критической или высокой severity без patch или mitigation.
• Тестовые bypass аутентификации в production-коде.
• Debug-режим активен в production-конфигурации.
• GPL/AGPL-зависимости в закрытом коммерческом продукте без лицензионного анализа.
• Wildcard CORS (*) с Access-Control-Allow-Credentials: true.

Документируют как техдолг (зафиксировать, передать клиенту явно):

• Устаревшие зависимости без CVE, но без активной поддержки.
• Отсутствие тестов на некритичные части системы.
• TODO/FIXME без тикетов.
• Неоптимальная архитектура, которая работает, но имеет известные ограничения по нагрузке или масштабированию.

Не блокируют, но требуют упоминания в документации:

• Зависимости с low-severity CVE и известным workaround.
• Закомментированный код, который является историческим контекстом, а не мёртвым кодом.

Заключение: передача — это не кнопка, это процесс

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

Чек-лист выше — инструмент для того, чтобы сделать этот процесс явным. Пройдитесь по нему за две–три недели до передачи, а не в последний вечер. Часть пунктов — секреты в git-истории, ротация ключей, аудит лицензий — требует времени, которого нет, если начинать за день до сдачи.

И отдельный совет для команд, активно использующих AI-инструменты: не принимайте функциональность за безопасность. AI ускоряет разработку — но вопросы «а что будет при некорректном вводе», «а где хранится этот ключ» и «а эта зависимость вообще поддерживается» по-прежнему ваши.

Источники

[1] Snyk — "Why 28 million credentials leaked on GitHub in 2025, and what to do about it" — https://snyk.io/articles/state-of-secrets/

[2] Veracode — "AI-Generated Code Security Risks: What Developers Must Know" — https://www.veracode.com/blog/ai-generated-code-security-risks/

[3] Cortex — "2024 Software Release Checklist For Smooth Deployments" — https://www.cortex.io/post/software-release-checklist

[4] Help Net Security — "AI writes code like a junior dev, and security is feeling it" — https://www.helpnetsecurity.com/2025/10/27/ai-code-security-risks-report/

[5] Cyber Defense Magazine — "The Hidden Danger: Secrets Sprawl Beyond the Codebase" — https://www.cyberdefensemagazine.com/the-hidden-danger-secrets-sprawl-beyond-the-codebase/

[6] Codacy Blog — "Managing the Risks of Hard-Coded Secrets" — https://blog.codacy.com/hard-coded-secrets

[7] Medium / InstaTunnel — "Hardcoded API Keys: The Rookie Mistake That Costs Millions" — https://medium.com/@instatunnel/hardcoded-api-keys-the-rookie-mistake-that-costs-millions-fa6da9dcc494

[8] The Register — "Millions of Android and iOS users at risk from hardcoded creds in popular apps" — https://www.theregister.com/2024/10/23/android_ios_security/

[9] Medium / Halil Atilla — "Removing Console Logs in Next.js Projects" — https://medium.com/@halilatilla/removing-console-logs-in-next-js-projects-c55713a9f635

[10] OWASP — "A03 Software Supply Chain Failures - OWASP Top 10:2025" — https://owasp.org/Top10/2025/A03_2025-Software_Supply_Chain_Failures/

[11] IntelligenceX Blog — "Software Supply Chain Failures (A03:2025): How One Compromised Dependency Can Destroy Your Organization" — https://blog.intelligencex.org/software-supply-chain-failures-owasp-a03-2025-complete-guide

[12] Veracode — "Beyond Your Code: A Guide to Software Supply Chain Risk Management" — https://www.veracode.com/blog/software-supply-chain-risk-management/

[13] Sonar — "Open Source License" — https://www.sonarsource.com/resources/library/open-source-license/

[14] AppSec Santa — "Open-Source License Compliance for Developers (2026)" — https://appsecsanta.com/sca-tools/open-source-license-compliance

[15] OWASP Foundation — "Secure Coding Practices Quick-reference Guide" — https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/

[16] Seclinq — "CORS Misconfiguration and How to Test and Fix Them" — https://seclinq.com/cors-misconfiguration/

[17] Multishoring — "IT Project Handover Checklist – 8 Steps" — https://multishoring.com/blog/it-project-handover-checklist-steps-for-a-seamless-transition/

[18] Cycode — "Top AI Security Vulnerabilities to Watch out for in 2026" — https://cycode.com/blog/ai-security-vulnerabilities/

[19] Futurity — "AI-generated code is vulnerable" — https://www.futurity.org/ai-generated-code-vulnerable-3330542/

[20] CSET Georgetown University — "Cybersecurity Risks of AI-Generated Code" — https://cset.georgetown.edu/publication/cybersecurity-risks-of-ai-generated-code/