Как студии встроить проверку безопасности в сдачу проекта

Почему «работает» не значит «безопасно» — и что с этим делать до подписания акта

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

Когда разработчик закрывает последний тикет и пишет «проект готов к сдаче», он имеет в виду функциональность. Клиент, получая код, тоже думает о функциональности. Между ними почти нет разговора о том, что именно передаётся с точки зрения безопасности.

Это нормально для 2010 года. Но не для 2025-го.

Во-первых, атаки на цепочку поставок резко выросли: по данным Ivanti, в 2024 году 75% организаций, работающих с программным обеспечением, зафиксировали инциденты в своей software supply chain [1]. Аутсорсинговый проект — это ровно такая же точка входа. Студия передаёт не просто код, но и все зависимости, которые она туда включила, все конфигурации, которые она написала, и все секреты, которые разработчики нечаянно зафиксировали в истории репозитория.

Во-вторых, масштаб утечки секретов стал измеримым. GitHub опубликовал данные: в 2024 году его инструмент Secret Scanning обнаружил более 39 миллионов случаев попадания чувствительной информации в репозитории — рост 67% год к году [2]. GitGuardian в своём отчёте State of Secrets Sprawl 2025 добавляет: 35% приватных репозиториев содержат секреты в открытом виде, а 70% секретов, утёкших в 2022 году, до сих пор валидны [3]. Студия, которая передаёт клиенту репозиторий с токенами в истории коммитов — передаёт ему активную уязвимость.

В-третьих, зависимости в современном проекте — это не несколько библиотек. По данным Ivanti, среднее приложение содержит около 150 зависимостей, 90% из которых являются транзитивными [1]. Каждая из них потенциально несёт CVE. SCA-сканирование перед сдачей — это не паранойя, это базовая гигиена.

Наконец, регуляторная среда меняется. CISA в 2025 году обновила требования к SBOM (Software Bill of Materials) [4], NIST выпустил draft SSDF 1.2 в декабре 2025 года [5]. Стандарты всё чаще предполагают, что поставщик ПО обязан передавать не только код, но и документацию о его составе и безопасности.

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

Где именно возникает риск

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

Секреты в git-истории

Это самая недооценённая угроза. Разработчик добавил токен в .env, зафиксировал изменение в коммите, потом удалил файл. В рабочей ветке токена нет. Но в git-истории он остался навсегда. При передаче репозитория клиенту вместе с историей уходят все когда-либо зафиксированные секреты: API-ключи, пароли к базам данных, приватные сертификаты.

GitGuardian фиксирует, что AI-ассистированные коммиты утекают секреты с частотой примерно вдвое выше базовой: инструменты автодополнения не распознают структуру секрета в контексте [3]. По мере роста использования AI-кодинга в студиях этот риск будет нарастать.

Уязвимые зависимости

В 2025 году npm стал основной площадкой для supply chain атак: по данным Sonatype, 99% случаев распространения вредоносного кода через открытые реестры произошло именно там [6]. Lazarus Group за год опубликовала более 800 вредоносных пакетов в npm [6]. Dependency confusion — атака, при которой публичный пакет с тем же именем, что и внутренний, скачивается сборщиком автоматически, — по оценкам Orca Security, затрагивает 49% организаций [7].

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

Конфигурационные ошибки

Debug-режим в production. CORS с *. Слишком широкие права сервисных аккаунтов. Незакрытые порты. Эти ошибки не попадают в SCA-отчёты, потому что они не в коде зависимостей — они в инфраструктурных и конфигурационных файлах. При этом именно они чаще всего становятся точкой входа для атакующего после деплоя.

OWASP DevSecOps Guideline прямо указывает на конфигурационные файлы как на один из ключевых объектов проверки в pipeline [8]. Но при сдаче аутсорсингового проекта конфигурации часто вообще не рассматриваются как предмет security-проверки.

Логика аутентификации и авторизации

Automated tools плохо обнаруживают business logic vulnerabilities. SAST не проверяет, правильно ли реализована логика смены пароля или передачи прав. Это задача ручного code review или пентеста. При сдаче проекта, содержащего аутентификацию, управление ролями или финансовые операции, такая проверка не должна быть опциональной.

Документация о безопасности

Один из самых частых результатов аудита переданных проектов: новая команда не знает, какие security-решения были приняты и почему. Нет документации о threat model, нет описания механизмов аутентификации, нет инструкции по ротации секретов. Это не только операционный риск — это долг, который клиент берёт при приёмке.

Что такое security-готовность к сдаче

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

• результаты автоматизированных проверок (SAST, SCA, secrets scanning);
• статус найденных уязвимостей (исправлены, приняты как риск, отложены — с обоснованием);
• документацию о составе зависимостей (SBOM);
• описание конфигурации и инфраструктуры с точки зрения безопасности;
• рекомендации по дальнейшему обслуживанию.

Именно это понимание закладывает NIST SSDF (Secure Software Development Framework) под термином «ответственность производителя ПО»: организация должна не только выпускать безопасный продукт, но и помогать потребителю принимать обоснованные решения о рисках [5].

Как выстроить security-процесс при сдаче: от pipeline до чеклиста

Уровень 1 — автоматизация внутри CI/CD

Первый и самый масштабируемый шаг — встроить security-проверки прямо в pipeline. Согласно OWASP DevSecOps Guideline, идеальная цель — обнаруживать проблемы как можно раньше, до merge в основную ветку [8].

Минимальный набор инструментов для работающего pipeline:

1. SAST (Static Application Security Testing) — анализ исходного кода без запуска. Запускается на каждый pull request. Популярные опции: Semgrep, SonarQube, GitHub CodeQL. Wiz рекомендует настраивать security gates, блокирующие merge при критических находках [9].

1. SCA (Software Composition Analysis) — проверка зависимостей по базам CVE. Запускается при каждом обновлении lock-файла и перед релизом. Опции: Dependabot, Snyk, OWASP Dependency-Check.

1. Secrets scanning — поиск секретов в коде и git-истории. Инструменты: Gitleaks, TruffleHog, GitGuardian. GitHub Push Protection с февраля 2024 года включён по умолчанию для публичных репозиториев [2], но приватные репозитории требуют отдельной настройки.

1. IaC scanning — анализ Terraform, Helm, Dockerfile, GitHub Actions на небезопасные конфигурации. Checkov, tfsec, kics.

По данным Total Shift Left, зрелые DevSecOps-программы снижают количество уязвимостей в production на 60% и сокращают затраты на remediation на 90% по сравнению с командами без shift-left практик [10].

Принципиально важный момент, который часто упускают: security feedback должен приходить через те же каналы, что и обычный code review. Если находка появляется как комментарий в PR — разработчик её видит. Если она уходит в отдельный отчёт через две недели — её игнорируют [10]. Это не техническая, а организационная проблема.

Уровень 2 — release gate перед сдачей

Pipeline работает на каждый коммит, но сдача проекта — это отдельное событие, требующее финального контроля. ISO 27001 Annex A 8.29 описывает именно такой формальный security sign-off перед выходом в production: технический руководитель или security lead проверяет, что все критичные и высокие уязвимости устранены или задокументировано приняты как риск [11].

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

По коду и зависимостям:

1. SAST-сканирование пройдено, все Critical и High находки закрыты или задокументированы с объяснением принятия риска.
2. SCA-сканирование показывает отсутствие критичных CVE в зависимостях, которые эксплуатируются в текущих атаках.
3. Lock-файлы (package-lock.json, poetry.lock, Pipfile.lock) зафиксированы в репозитории.
4. Secrets scanning по git-истории прогнан, найденные секреты ротированы или признаны инвалидными.
5. SBOM сформирован и включён в пакет сдачи.

По конфигурации и инфраструктуре:

1. Debug-режим выключен в production-окружении.
2. CORS настроен корректно, без wildcard там, где это не предусмотрено логикой приложения.
3. Сервисные аккаунты имеют минимально необходимые права (принцип least privilege).
4. Все API-ключи и пароли переведены из кода в environment variables или secret manager.
5. Конфигурация логирования не включает вывод чувствительных данных.

По аутентификации и авторизации:

1. Реализация аутентификации задокументирована и прошла ручной review.
2. Управление сессиями корректно: время жизни токенов, logout, инвалидация сессий.
3. Если есть управление ролями — задокументирована матрица доступа.

По документации:

1. Описан механизм ротации секретов.
2. Задокументированы сделанные security-компромиссы с обоснованием.
3. Передана инструкция по мониторингу и реагированию на security-инциденты.

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

Уровень 3 — пентест для продуктов с повышенным риском

SAST и SCA не обнаруживают все классы уязвимостей. Business logic flaws, цепочки атак через несколько запросов, уязвимости в реализации OAuth — это задача для пентеста.

ISO 27001 предписывает ежегодный пентест силами независимых специалистов [11]. Для студий разумное правило: пентест перед сдачей обязателен, если продукт содержит хотя бы один из следующих элементов:

• пользовательская аутентификация;
• обработка платёжных данных или персональных данных;
• API, доступное из внешних систем;
• административный интерфейс с управлением правами;
• интеграция с банками, государственными системами или healthcare-инфраструктурой.

Типичная стоимость внешнего пентеста для веб-приложения — от $5 000 до $25 000 USD в зависимости от сложности и глубины [12]. Для студии это либо отдельная статья в смете проекта, либо услуга, которую клиент заказывает самостоятельно при поддержке передающей команды.

Результат пентеста входит в пакет сдачи: отчёт с находками, статус каждой (исправлена, принята, в roadmap), подтверждение повторной проверки исправленных пунктов.

Уровень 4 — SBOM как артефакт сдачи

Software Bill of Materials — машиночитаемый реестр всех компонентов проекта с версиями, лицензиями и источниками. CISA в обновлённом руководстве 2025 года называет SBOM основой прозрачности supply chain [4].

Почему SBOM важен при сдаче проекта:

1. Клиент получает возможность проверять уязвимости в переданном продукте самостоятельно после получения кода — без повторного обращения к студии.
2. При появлении новой CVE (как это было с Log4j) клиент мгновенно может понять, затронут ли его проект.
3. SBOM снижает юридическую неопределённость в части лицензий open-source компонентов.

Форматы: CycloneDX и SPDX — два основных стандарта, оба поддерживаются большинством современных SCA-инструментов. Генерация SBOM при сборке проекта занимает минуты и полностью автоматизируема.

Типичные ошибки и как их избежать

Ошибка 1: «Мы прогнали SCA — уязвимостей нет»

SCA проверяет известные CVE на момент сканирования. Завтра может появиться новая. Более того, SCA не проверяет конфигурацию и не ищет секреты. Результат одного сканирования — это snapshot, а не гарантия.

Как избежать: регулярные сканирования в CI/CD + финальный прогон непосредственно перед сдачей + передача SBOM клиенту для самостоятельного мониторинга.

Ошибка 2: «Мы удалили секрет из кода — теперь всё в порядке»

Удаление из рабочей ветки не удаляет из git-истории. Любой, кто клонирует репозиторий, получает всю историю коммитов.

Как избежать: secrets scanning с проверкой всей истории (Gitleaks, TruffleHog с флагом --all). Найденные секреты необходимо ротировать в соответствующих сервисах — просто удалить из репозитория недостаточно.

Ошибка 3: «Мы использовали только проверенные библиотеки»

Проблема dependency confusion состоит в том, что атакующий публикует в npm или PyPI пакет с тем же именем, что и ваш внутренний приватный пакет, но с более высоким номером версии. Сборщик может скачать публичную версию [7]. Это не зависит от «проверенности» — это архитектурная уязвимость при наличии частных пакетов.

Как избежать: явное указание реестра в .npmrc или pip.conf, pin-версии в lock-файлах, аудит при добавлении каждой новой зависимости.

Ошибка 4: «Клиент примет — разберётся сам»

Студии, которые передают код без security-документации, фактически перекладывают на клиента долг, о котором он не знает. Это источник претензий через 6–12 месяцев после сдачи, когда инцидент всё же произойдёт.

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

Ошибка 5: «У нас нет времени на security перед сдачей»

Это структурная проблема планирования, а не реальное ограничение. SAST и SCA занимают минуты при наличии готового pipeline. Проблема возникает, когда pipeline не настроен и security-проверки не заложены в спринты.

Как избежать: security-проверки должны быть частью Definition of Done, а не отдельной задачей перед сдачей.

Как HighVibe помогает закрыть разрыв между «работает» и «безопасно»

Одна из причин, по которым security-проверки при сдаче не делаются — отсутствие инструмента, который даёт понятный и быстрый ответ именно на уровне конкретного изменения или конкретного релиза.

HighVibe — дополнительный слой контроля безопасности до merge и релиза, ориентированный на команды, которые уже используют AI-кодинг. Он анализирует конкретные изменения в коде, конфигурациях и зависимостях — не весь репозиторий целиком, а то, что изменилось в контексте текущего PR или релиза. Вместо длинного security-отчёта команда получает короткий и конкретный сигнал: что именно блокирует безопасный merge или выпуск.

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

Будущее: как меняются ожидания рынка

Несколько тенденций, которые будут усиливаться в 2026–2028 годах.

SBOM из опции в норму. EU Cyber Resilience Act, вступивший в силу в 2024 году, и американские требования к федеральным подрядчикам делают SBOM обязательным условием для всё большего круга проектов [4]. Студии, работающие с enterprise и госсектором, столкнутся с этим требованием в тендерной документации.

AI-кодинг умножает supply chain риски. По данным Snyk, AI-ассистированные коммиты утекают секреты с частотой вдвое выше базовой [3]. Рост использования AI-инструментов в разработке при отсутствии security-контроля означает пропорциональный рост числа уязвимостей, которые будут попадать в сдаваемые проекты.

Стандартизация ожиданий заказчиков. Крупные корпоративные клиенты уже сегодня включают security-требования в технические задания и договоры. Через 2–3 года security summary при сдаче станет таким же стандартным требованием, как документация и тесты.

Заключение: что делать студии прямо сейчас

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

1. Настроить SAST, SCA и secrets scanning в CI/CD — один раз, не к каждому проекту.
2. Добавить в Definition of Done: «критичные security-находки закрыты или задокументировано приняты».
3. Разработать шаблон security summary для пакета сдачи.
4. Включить генерацию SBOM в процесс сборки.
5. Для продуктов с аутентификацией, данными пользователей или внешними API — заложить пентест в смету или в явном виде передать эту задачу клиенту с рекомендациями.

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

Источники

[1] Ivanti — "Why You Can't Afford to Ignore Software Supply Chain Attacks" — https://www.ivanti.com/blog/software-supply-chain-attack-risk

[2] BleepingComputer — "GitHub expands security tools after 39 million secrets leaked in 2024" — https://www.bleepingcomputer.com/news/security/github-expands-security-tools-after-39-million-secrets-leaked-in-2024/

[3] GitGuardian — "The State of Secrets Sprawl 2025" — https://blog.gitguardian.com/the-state-of-secrets-sprawl-2025/

[4] CISA — "2025 Minimum Elements for a Software Bill of Materials (SBOM)" — https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom

[5] NIST — "Secure Software Development Framework (SSDF) Version 1.2 — Draft" — https://www.nist.gov/news-events/news/2025/12/secure-software-development-framework-ssdf-version-12-available-public

[6] Sonatype — "2026 Software Supply Chain Report — Open Source Malware" — https://www.sonatype.com/state-of-the-software-supply-chain/2026/open-source-malware

[7] Authgear — "OWASP Top 10 2025: A03 — Software Supply Chain Failures" — https://www.authgear.com/post/owasp-2025-software-supply-chain-failures/

[8] OWASP — "DevSecOps Guideline" — https://owasp.org/www-project-devsecops-guideline/

[9] Wiz — "CI/CD Security Scanning: Definition and Best Practices" — https://www.wiz.io/academy/application-security/ci-cd-security-scanning

[10] Total Shift Left — "Shift Left Security 2026: CI/CD Best Practices, SAST & SCA Tools" — https://totalshiftleft.com/blog/shift-left-security-protecting-your-ci-cd-pipeline-from-the-start

[11] HighTable — "ISO 27001 Annex A 8.29: Security Testing in Development and Acceptance" — https://hightable.io/iso27001-annex-a-8-29-security-testing-in-development-and-acceptance/

[12] Beagle Security — "How to outsource penetration testing the right way in 2025" — https://beaglesecurity.com/blog/article/how-to-outsource-penetration-testing.html

[13] Miquido — "Essential Software Project Handover Checklist" — https://www.miquido.com/blog/software-project-handover-checklist/

[14] Qualys — "CI/CD Security Best Practices: How to Secure DevSecOps Pipelines in 2026" — https://www.qualys.com/fundamentals/ci-cd-security-best-practices

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

[16] GoRegulus — "Secure Software Development Life Cycle: Phases + Checklist" — https://goregulus.com/cra-basics/secure-software-development-life-cycle/