Приёмка проекта после смены подрядчика: технический чек-лист

Как принять кодовую базу, доступы и зависимости так, чтобы новая команда не унаследовала чужие риски

Зачем нужна формальная техприёмка при смене подрядчика

Передача проекта от одного подрядчика к другому — это момент, когда риски, накопленные за месяцы или годы разработки, либо становятся видимыми, либо окончательно прячутся под капотом. Материалы по управлению вендорами сходятся в одном: офбординг подрядчика — это управляемый процесс с владельцем, сроками и чек-листом, а не разовое «спасибо, до свидания» [13, 15]. Без структуры это превращается в зону риска: задержки сервисов, утечка данных, спор о правах на код.

Отдельная категория риска — технологическая зависимость, выстроенная сознательно или неосознанно: код без документации, проприетарные инструменты, доступы, которые остаются только у прежнего подрядчика [16]. Вопрос «как вы передадите материалы, если мы решим сменить подрядчика» стоит задавать ещё на этапе заключения контракта — но если этот момент пропущен, приёмку всё равно нужно проводить, просто более тщательно.

Полноценный software handover должен закрывать четыре вещи одновременно: код передан, документация предоставлена, доступы к развёртыванию переданы, права на интеллектуальную собственность закреплены [8]. Пока хотя бы одно из этого не выполнено, проект формально не передан — даже если новая команда уже что-то чинит в продакшене.

Слой 1: код и репозиторий

Первый и самый очевидный пункт — но именно здесь чаще всего экономят время.

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

1. Полная история коммитов передана, а не «чистая» ветка без истории — иначе теряется контекст решений и авторство.
2. Все рабочие, feature- и hotfix-ветки переданы, включая незавершённые.
3. Исходный код в репозитории соответствует тому, что реально развёрнуто в продакшене — расхождение между репозиторием и продакшеном встречается часто и является отдельным риском [8].
4. Права на репозиторий (owner, admin) переведены на организацию заказчика, а не остаются личными аккаунтами сотрудников подрядчика.
5. Лицензии на используемый код, торговые знаки и права на брендинг явно зафиксированы как принадлежащие заказчику [8].
6. CI/CD-конфигурация (pipeline-файлы, workflow-описания) передана вместе с кодом, а не хранится отдельно у подрядчика.

S-PRO, описывая свой опыт перехвата более 25 проектов от других вендоров, подчёркивает, что именно код — самая важная часть передачи, и в процесс стоит вовлекать тимлида, менеджера, бизнес-аналитика, разработчиков и дизайнера с обеих сторон [6].

Слой 2: зависимости и supply chain

Это слой, который чаще всего недооценивают, хотя именно здесь прячутся самые «тихие» риски.

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

1. Сформировать SBOM — машиночитаемый перечень всех компонентов: открытых библиотек, внутреннего кода, транзитивных зависимостей. NIST описывает SBOM как аналог состава продукта на этикетке: он даёт прозрачность и происхождение каждого компонента [3].
2. Сверить lock-файлы (package-lock, yarn.lock, poetry.lock и т. п.) с фактически используемыми версиями — расхождения говорят о бесконтрольных обновлениях или ручных правках.
3. Проверить каждую зависимость, которая выглядит непривычно или нетипично для проекта, на существование в публичном реестре. Это особенно важно, если часть кода писалась с помощью AI-инструментов (подробнее — в разделе ниже).
4. Проверить лицензии всех open-source компонентов на совместимость с продуктом и обязательствами заказчика — отдельный юридический риск, который SBOM также помогает закрыть [3].
5. Сверить устаревшие и уязвимые версии библиотек через известные базы уязвимостей; CISA отдельно рекомендует операционализировать SBOM именно для этой задачи — превращать перечень компонентов в реальный мониторинг рисков [4].
6. Проверить, использует ли проект бинарные сборки или скомпилированные артефакты, чьё происхождение нельзя проверить по исходникам — для них OWASP рекомендует сканирование финального билда обеими сторонами, поставщиком и потребителем [10] (пояснение слоя: это рекомендация стандарта, а не подтверждённая практика конкретного проекта — степень применимости зависит от стека).

Слой 3: доступы, секреты и инфраструктура

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

Что проверять и делать:

1. Составить полный список всех систем: облачные аккаунты, домены, DNS, SSL-сертификаты, CI/CD-платформы, мониторинг, базы данных, сторонние SaaS-интеграции [8].
2. Ротировать все секреты и пароли, к которым подрядчик имел доступ — не выборочно «подозрительные», а все. OWASP формулирует это прямо: при инциденте экспонирования секрет должен быть немедленно отозван, а новый — выпущен по возможности автоматизированно [1].
3. Отозвать физический и цифровой доступ: ключи, бейджи, VPN, учётные записи в системах коллаборации [7, 14].
4. Перевести владение доменом, облачным аккаунтом и биллингом на организацию заказчика — это частая точка, где подрядчик остаётся формальным владельцем годами после окончания контракта.
5. Проверить наличие сервисных аккаунтов и токенов автоматизации (CI/CD-боты, webhook-интеграции) — такие токены часто переживают людей-сотрудников на месяцы или годы и несут широкие права [3].
6. Получить письменное подтверждение, что у подрядчика не осталось копий конфиденциальных данных и кода после завершения работ [7].
7. Проверить логи доступа за последний период работы подрядчика на предмет аномальной активности перед расторжением контракта.

Важно различать слои: то, что секреты нужно ротировать всегда — это прямая рекомендация стандарта (OWASP) [1]; то, что конкретный подрядчик действительно скопировал данные — это предположение, которое без подтверждения нельзя считать доказанным, но и не проверять тоже нельзя.

Слой 4: документация и архитектура

Код без документации — это код, который новая команда будет реверс-инжинирить за деньги заказчика.

Минимальный набор документов при приёмке:

1. Документ архитектуры системы и технологический стек.
2. Схема базы данных и описание её структуры.
3. Документация API (эндпоинты, форматы запросов/ответов, авторизация).
4. Описание интеграций с внешними сервисами.
5. Инструкции по развёртыванию и конфигурации окружений (dev/staging/prod).
6. Описание известных ограничений системы и нерешённых проблем — этот пункт подрядчики передают реже всего, и именно он экономит новой команде недели на самостоятельное открытие тех же проблем [8].

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

Слой 5: качество кода и технический долг

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

Практические метрики:

1. Цикломатическая сложность — показывает, сколько независимых путей выполнения проходит через функцию; чем выше, тем сложнее тестировать и поддерживать код [9, 12].
2. Технический долг как соотношение стоимости исправления проблем поддерживаемости к общей стоимости разработки [9].
3. Code churn — частота изменений одних и тех же участков кода; высокий churn в сочетании с низким покрытием тестами часто указывает на нестабильные, проблемные зоны [9, 12].
4. Процент дублирования кода.
5. Покрытие тестами и наличие автоматизированных тестов вообще — для унаследованного проекта это часто более показательный индикатор риска, чем стиль кода.
6. Регулярность и качество предыдущих код-ревью — если их не было, стоит закладывать более тщательную ручную проверку критичных модулей при приёмке.

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

Особый риск 2025–2026: AI-сгенерированный код от прежнего подрядчика

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

Ключевая проблема — package hallucinations, или «слопсквоттинг» (slopsquatting): LLM при генерации кода иногда советует импортировать несуществующие пакеты. Исследование, представленное на USENIX Security 2025, проанализировало 2,23 миллиона сгенерированных кодовых фрагментов от 16 моделей и обнаружило, что около 19,7% содержали как минимум один такой фантомный пакет [19]. При этом 43% таких названий стабильно повторялись при одном и том же запросе, что делает их предсказуемой и удобной целью для злоумышленников, которые заранее регистрируют такие имена в публичных реестрах [19, 20]. Подтверждённый кейс — пакет, маскировавшийся под легитимный eslint-plugin, который успел набрать тысячи загрузок до того, как его удалили из реестра [17, 20].

Дополнительно стоит учитывать данные индустрии за 2025–2026 годы: по оценке Veracode (приводится в обзоре 2026 года), AI-сгенерированные pull request содержат примерно в 1,7 раза больше дефектов, чем написанные человеком, и порядка 45% вносят минимум одну уязвимость из категории OWASP Top 10 [17]. Отдельное исследование также фиксирует, что AI-ассистированные коммиты содержат экспонированные секреты более чем в два раза чаще, чем коммиты, написанные только человеком [18].

Что это означает для приёмки практически:

1. Каждый незнакомый или нетипичный импорт в зависимостях нужно явно проверить на существование в реестре — нельзя по умолчанию считать его «просто новой библиотекой» [17].
2. Если у прежнего подрядчика не было формализованной политики ревью AI-сгенерированного кода, стоит закладывать более долгий, а не более быстрый цикл проверки таких участков — обзор 2026 года прямо отмечает: если время ревью AI-кода совпадает со временем ревью обычного кода, фактически происходит не проверка, а штамповка [17].
3. Стоит явно спросить у прежнего подрядчика (или выяснить по истории коммитов), использовались ли AI-инструменты систематически, и в каких модулях — это не показатель плохой работы само по себе, но определяет, где концентрировать усилия аудита.

Важная оговорка по слоям доказательности: цифры о доле дефектов и хаотичности фантомных пакетов взяты из конкретных исследований 2025–2026 годов и относятся к изученным на тот момент моделям — для каждого нового поколения моделей цифры могут отличаться [19]. Это не повод их игнорировать, но повод не воспринимать конкретный процент как универсальную константу навсегда.

Decision framework: что блокирует приёмку, а что фиксируем как долг

Чтобы не утонуть в списке из полусотни находок, стоит заранее разделить их на три категории.

Блокер — приёмка не подписывается, пока не закрыто:

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

Предупреждение — приёмка подписывается, но риск фиксируется письменно и берётся в работу в первую очередь:

• Отсутствует документация архитектуры или API.
• Низкое покрытие тестами критичных модулей.
• Обнаружены устаревшие или уязвимые зависимости без активного эксплоита в моменте.
• Не подтверждено происхождение части импортов — требуется отдельная проверка.

Принимается с оговоркой — фиксируется как технический долг в бэклоге, не блокирует старт работы:

• Высокая цикломатическая сложность отдельных модулей.
• Дублирование кода.
• Несоответствие стиля кода внутренним стандартам новой команды.

Типичные ошибки при приёмке

1. Полагаться на устные заверения подрядчика вместо письменного акта с конкретным перечнем переданного.
2. Считать, что «работает в проде» автоматически означает «безопасно принять» — рабочий функционал не равен отсутствию уязвимостей или скрытых обязательств.
3. Откладывать ротацию секретов «на потом», после официального завершения контракта — к этому моменту бывший подрядчик формально уже не несёт ответственности за инциденты.
4. Проверять только код, забывая про инфраструктурный и юридический слои.
5. Не привлекать к приёмке людей, которые будут реально поддерживать систему — без их участия теряется значимая часть контекста.

Где здесь уместен HighVibe

Технический чек-лист закрывает разовую точку перехода, но риск не исчезает после подписания акта приёмки: новая команда продолжает работать с унаследованным кодом, его зависимостями и, всё чаще, с AI-инструментами в собственном цикле разработки. Здесь HighVibe выступает не заменой техприёмки и не альтернативой SAST/SCA/SBOM-инструментам, а дополнительным слоем контроля непосредственно перед merge и релизом: он анализирует конкретное изменение в коде, конфигурации и зависимостях, обращает внимание на новые или транзитивные пакеты, служебные файлы и конфиги, которые обычно читают хуже всего, и даёт команде короткий, понятный сигнал — можно ли безопасно принять именно это изменение сейчас, а не очередной длинный отчёт, который никто не дочитывает.

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

Заключение

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

Источники

[1] OWASP — "Secrets Management Cheat Sheet" — https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

[2] OWASP — "Protect Data Everywhere" (Developer Guide) — https://devguide.owasp.org/en/04-design/02-web-app-checklist/08-protect-data/

[3] NIST — "Software Security in Supply Chains: Software Bill of Materials (SBOM)" — https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1

[4] CISA — "Securing the Software Supply Chain: Recommended Practices for SBOM Consumption" — https://www.cisa.gov/sites/default/files/202408/SECURING_THE_SOFTWARE_SUPPLY_CHAIN_RECOMMENDED_PRACTICES_FOR_SOFTWARE_BILL_OF_MATERIALS_CONSUMPTION-508.pdf

[5] AWS — "Well-architected best practices for software supply chain security" — https://aws.amazon.com/blogs/security/well-architected-best-practices-for-software-supply-chain-security/

[6] S-PRO — "Project Handover Template for Effective Transition" — https://s-pro.io/blog/project-handover-how-to-change-a-software-development-vendor

[7] Auditive — "Vendor Offboarding Best Practices and Checklist" — https://auditive.io/blog/vendor-offboarding-best-practices-checklist

[8] tech4lyf — "Software Handover Checklist (2026)" — https://www.tech4lyf.com/blog/software-handover-documentation-checklist-2026/

[9] Sonar — "Measuring and Identifying Code-level Technical Debt" — https://www.sonarsource.com/resources/library/measuring-and-identifying-code-level-technical-debt-a-practical-guide/

[10] OWASP — "Software Supply Chain Security Cheat Sheet" — https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html

[11] Sonar — "Software Bill of Materials (SBOM) Definition & Component Inventory" — https://www.sonarsource.com/resources/library/software-bill-of-materials/

[12] Codacy — "The Inverse of Technical Debt Is Code Quality" — https://blog.codacy.com/the-inverse-of-technical-debt-is-code-quality

[13] Opstream — "Vendor Offboarding: Full 7-Step Checklist" — https://www.opstream.ai/blog/vendor-offboarding-checklist-a-practical-7-step-process-with-risks-to-avoid/

[14] Mitratech — "Vendor Offboarding: A Checklist for Reducing Risk and Simplifying the Process" — https://mitratech.com/resource-hub/blog/vendor-offboarding-checklist/

[15] Stitchflow — "Free vendor offboarding checklist for IT teams" — https://www.stitchflow.com/blog/vendor-offboarding-checklist

[16] 66 Бит — "Чек-лист вопросов подрядчику перед разработкой ПО для бизнеса" — https://66bit.ru/blog/detail/checklist-of-questions-for-the-contractor

[17] metacto — "Code Review for AI-Generated Code: 2026 Standards" — https://www.metacto.com/blogs/establishing-code-review-standards-for-ai-generated-code

[18] Cloud Security Alliance — "Vibe Coding Security Crisis: Credential Sprawl and SDLC Debt" — https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-security-vibe-coding-202/

[19] Cloud Security Alliance — "Slopsquatting: AI Code Hallucinations Fuel Supply Chain Threat" — https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/04/CSA_research_note_slopsquatting-ai-supply-chain_20260419-csa-styled-1.pdf

[20] Aikido — "Slopsquatting: The AI Package Hallucination Attack Already Happening" — https://www.aikido.dev/blog/slopsquatting-ai-package-hallucination-attacks

[21] Snyk — "Package Hallucination: Impacts, and Mitigation" — https://snyk.io/articles/package-hallucinations/