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

Практическое руководство для CTO, Tech Lead и менеджеров продукта — от требований в договоре до приёмки кода и пентеста

Введение: почему заказчику нельзя верить на слово

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

Это не гипотетический сценарий. По данным исследования Veracode 2025 года, 45% образцов кода, сгенерированных более чем 100 различными языковыми моделями, не прошли тесты безопасности и содержали уязвимости из OWASP Top 10 [1]. А отчёт GitGuardian State of Secrets Sprawl 2026 зафиксировал 28,65 миллиона новых захардкоженных секретов в публичных GitHub-коммитах за 2025 год — рост на 34% год к году, крупнейший за всё время наблюдений. При этом AI-assisted коммиты утекают секреты примерно в 3,2% случаев [2].

Эта статья — для заказчиков (CTO, VP Engineering, Tech Lead, менеджеры продукта), которые хотят понять: что конкретно проверять, когда проверять и как зафиксировать требования к безопасности, чтобы не оказаться в ситуации «а мы не договаривались».

Часть 1. Безопасность начинается до первой строчки кода

Почему требования важнее инструментов

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

OWASP Development Guide прямо указывает: все фазы SDLC должны иметь встроенные security-активности, а не добавлять безопасность как отдельный этап после разработки [3]. NIST SSDF (Special Publication 800-218) — один из наиболее зрелых международных фреймворков — рекомендует явно выражать требования к безопасной разработке в контрактах с третьими поставщиками [4].

В декабре 2025 года NIST выпустил публичный черновик SSDF Version 1.2, расширяющий практики под современные реалии AI-кодинга [5].

Что фиксировать в договоре или ТЗ

Минимальный перечень требований безопасности, который стоит включить в договор с подрядчиком:

1. Применение SAST (статический анализ кода) как обязательного этапа в CI/CD-конвейере.
2. Применение SCA (анализ состава ПО) для всех сторонних зависимостей.
3. Сканирование на секреты (hardcoded credentials, API keys, tokens) до мержа в основную ветку.
4. Хранение зависимостей с пинингом версий и наличие lock-файлов.
5. Разделение окружений: development, staging, production — с запретом использования боевых данных в тестовых средах.
6. Предоставление SBOM (Software Bill of Materials) — машиночитаемого реестра всех компонентов — на момент каждого релиза.
7. Исправление критических (Critical/High по CVSS) уязвимостей до приёмки.
8. Предоставление отчётов сканеров и результатов пентеста как обязательного артефакта сдачи.

В российском контексте для регулируемых отраслей (финтех, медицина, государственные системы) стоит ссылаться на ГОСТ Р 56939-2024 — обновлённый национальный стандарт «Защита информации. Разработка безопасного программного обеспечения. Общие требования», вступивший в силу в конце 2024 года [6]. Согласно приказу ФСТЭК №230 от 30 июня 2025 года, при сертификации средств защиты информации необходимо руководствоваться именно этим стандартом [6].

OWASP ASVS как основа для требований

Если вы разрабатываете веб-приложение или API и хотите предметно описать требования безопасности — используйте OWASP Application Security Verification Standard (ASVS). Он определяет три уровня верификации и охватывает 14 категорий контроля: от аутентификации и управления сессиями до криптографии и логирования. ASVS прямо позиционируется как инструмент для включения требований безопасности в закупочные контракты и тест-планы [7].

Часть 2. Что проверять в процессе разработки

CI/CD как первый рубеж контроля

Правильно выстроенный пайплайн не пускает небезопасный код в main-ветку. Заказчику важно не просто знать, что «у подрядчика есть CI», а понимать, какие проверки он включает.

Конкретные вопросы, которые стоит задать подрядчику или проверить в ходе аудита:

1. Какой SAST-инструмент интегрирован в пайплайн? Когда он последний раз запускался?
2. Есть ли SCA-сканирование зависимостей? Какой инструмент (Snyk, Dependabot, OWASP Dependency-Check, Black Duck)?
3. Настроен ли секрет-сканер (например, GitLeaks, truffleHog, detect-secrets) как pre-commit hook или шаг в CI?
4. Заблокирован ли merge при наличии Critical/High-уязвимостей — или это просто уведомление без gate?
5. Пинингуются ли версии зависимостей? Есть ли lock-файлы в репозитории?
6. Разделены ли окружения dev/staging/prod?

Согласно OWASP Product Security Guide, ключевые риски приходят через уязвимости в SDLC, скомпрометированные инструменты и библиотеки, а также через цепочку поставок — когда атакующий проникает через доверенного вендора или компонент [8].

Отдельная история: AI-генерируемый код

Большинство современных команд используют AI-ассистентов кодинга. Это ускоряет разработку, но создаёт специфические риски, о которых заказчик должен знать.

Исследование CodeRabbit (декабрь 2025) проанализировало 470 реальных open-source pull requests. Оно показало, что AI-генерируемые PR содержат примерно в 1,7 раза больше проблем в целом, в 1,4 раза больше критических issues и в 2,74 раза больше XSS-уязвимостей по сравнению с человеческим кодом [9]. Проблемы с некорректной обработкой паролей встречаются почти вдвое чаще; ошибки бизнес-логики — более чем вдвое [9].

Параллельно исследователи из Georgia Tech запустили Vibe Security Radar — систему отслеживания CVE, связанных с AI-инструментами. Из 74 подтверждённых случаев 14 получили статус критических, включая command injection, обход аутентификации и SSRF [10].

Что из этого следует для заказчика: если команда подрядчика применяет Copilot, Cursor или другие AI-ассистенты, в договоре стоит явно зафиксировать, что весь AI-генерируемый код проходит ревью человеком перед merge. Особую осторожность нужно проявлять к компонентам аутентификации, шифрования, обработки платёжных данных и конфигурационным файлам — именно там AI чаще всего вносит опасные паттерны [10].

Часть 3. Что проверять в зависимостях и supply chain

Зависимости как слепая зона

Современное приложение на 80–90% состоит из чужого кода — библиотек, фреймворков, транзитивных зависимостей. Уязвимость в одной популярной библиотеке может затронуть тысячи продуктов одновременно (классический пример — Log4Shell в 2021 году).

В июне 2024 года была обнаружена критическая уязвимость (CVE-2024-21495) в библиотеке Go github.com/greenpau/caddy-security, используемой для OAuth и аутентификации в веб-сервере Caddy. Уязвимость возникла из-за применения небезопасного генератора случайных чисел, что позволяло предсказывать токены и обходить MFA [11]. Пример показывает: даже зрелая, широко используемая библиотека может содержать серьёзный изъян.

В SolarWinds в июне 2024 года критический патч потребовался после обнаружения захардкоженных учётных данных прямо в коде продукта (CVE-2024-28987, CVSS 9.1) [11].

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

1. Все зависимости зафиксированы в lock-файле с точными версиями (не ^1.2.x, а 1.2.3).
2. SCA-инструмент регулярно сканирует зависимости на известные CVE.
3. Транзитивные (косвенные) зависимости тоже входят в область сканирования.
4. Неиспользуемые и устаревшие пакеты удалены из репозитория.
5. Есть процесс оперативного обновления при появлении новых advisories.

SBOM: реестр всего, что внутри

Software Bill of Materials — это машиночитаемый список всех компонентов, версий, лицензий и зависимостей продукта. После инцидента с Log4j организации, имевшие SBOM, смогли определить свою подверженность за минуты вместо дней [12].

После исполнительного приказа США EO 14028 SBOM стал фактически обязательным для поставщиков федерального правительства. В июле 2025 года индийский регулятор CERT-In выпустил SBOM Guidelines 2.0, сделав их обязательными для государственных, публичных и организаций критической инфраструктуры [13]. CISA опубликовала обновлённое руководство по SBOM в 2025 году [14].

Заказчику стоит требовать SBOM в формате SPDX или CycloneDX как часть пакета сдачи каждого релиза. Это даёт возможность быстро проверить состав ПО при появлении новой уязвимости и не зависеть от подрядчика в оценке рисков.

Часть 4. Аудит кода: когда и как

Виды аудита

Технический аудит кода решает разные задачи, и их важно не путать [15]:

1. Архитектурный аудит — оценивает структуру, модульность, соответствие принципам проектирования. Он не проверяет безопасность в деталях.
2. Аудит качества кода — технический долг, читаемость, соответствие стандартам оформления.
3. Аудит безопасности кода — поиск уязвимостей: SAST, ручной анализ логики доступа, проверка конфигураций, анализ зависимостей.

Эти виды дополняют, но не заменяют друг друга. Для приёмки с точки зрения безопасности нужен именно аудит безопасности, а не просто «аудит кода».

Автоматика vs. ручной анализ

Комбинация автоматизированного сканирования (SAST/SCA) и ручного анализа даёт наиболее полный результат [16]. Сканеры хорошо ловят известные паттерны уязвимостей: SQL-инъекции, XSS, захардкоженные секреты, уязвимые версии зависимостей. Но они не видят:

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

Именно поэтому перед приёмкой критически важных систем стоит заказывать ручной code review с фокусом на модули аутентификации, авторизации, работы с пользовательскими данными и внешних интеграций [8].

Когда проводить аудит

Оптимальная модель — три точки проверки:

1. В середине разработки (milestone review) — когда основная архитектура готова, но ещё можно вносить изменения без больших потерь.
2. Перед релизом (pre-release gate) — финальная проверка перед выходом в прод.
3. Периодически в ходе эксплуатации — особенно при значимых изменениях функционала или замене ключевых зависимостей.

Важный тезис из современных исследований: одноразовый ежегодный тест безопасности не соответствует темпу современной разработки. Команда может выпустить несколько значимых изменений между стартом и финальным отчётом — и часть из них окажется за пределами области проверки [17].

Часть 5. Пентест как инструмент приёмки

Что такое пентест и зачем он нужен заказчику

Penetration testing — это моделирование реальной атаки на систему, проводимое профессионалами с целью выявить уязвимости, которые могут быть эксплуатированы злоумышленником. В отличие от SAST/SCA, пентест смотрит на приложение снаружи и в комплексе — так же, как смотрит атакующий.

Третья сторона (внешняя компания) подходит к системе без внутренних допущений и слепых зон, которые возникают у тех, кто с ней работал месяцами [18]. Именно это делает пентест важным инструментом независимой оценки.

Что требовать от пентеста

Заказчик вправе потребовать от подрядчика организацию пентеста или предоставить отчёт от независимой компании. Ключевые параметры:

1. Scope: что входит в область тестирования — веб-приложение, API, мобильный клиент, инфраструктура, CI/CD-конвейер.
2. Методология: white-box (с доступом к коду) или black-box (без доступа). Для приёмки после разработки white-box даёт более полный результат.
3. Стандарт: OWASP Testing Guide, PTES (Penetration Testing Execution Standard) или аналог.
4. Отчёт: должен содержать найденные уязвимости, CVSS-оценку каждой, доказательство (proof-of-concept), приоритет устранения и рекомендации.
5. Ретест: после устранения уязвимостей проводится повторная проверка найденных точек.

Сертификаты OSCP у специалистов команды — один из признаков квалификации [19]. Проверяйте также, есть ли у компании киберстраховка и чёткие условия конфиденциальности тестовых данных.

Частота

Пентест раз в год — минимальная планка для большинства приложений. Для продуктов с высоким риском (финансовые сервисы, медицинские данные, критическая инфраструктура) оптимальна модель PTaaS (Penetration Testing as a Service) с непрерывным тестированием, интегрированным в цикл разработки [17].

Часть 6. Чек-лист заказчика: что проверять на каждом этапе

До старта разработки

1. Зафиксированы ли требования к безопасности в ТЗ или договоре?
2. Есть ли ссылка на стандарт (OWASP ASVS, НИСТ SSDF, ГОСТ Р 56939-2024)?
3. Описан ли порядок приёмки артефактов безопасности (отчёты SAST, SBOM, пентест)?
4. Прописана ли ответственность за критические уязвимости, найденные после приёмки?

В процессе разработки

1. Интегрирован ли SAST в CI/CD? Есть ли security gate?
2. Настроен ли SCA? Проверяются ли транзитивные зависимости?
3. Работает ли секрет-сканер на уровне pre-commit или CI?
4. Если используется AI-кодинг — есть ли обязательный ручной ревью AI-сгенерированных PR?
5. Разделены ли окружения? Производственные данные не используются в тесте?

Перед приёмкой

1. Получены ли отчёты SAST и SCA? Устранены ли Critical и High уязвимости?
2. Предоставлен ли SBOM в машиночитаемом формате?
3. Проведён ли пентест? Получен ли отчёт с CVSS-оценками?
4. Выполнен ли ретест после устранения уязвимостей?
5. Нет ли захардкоженных секретов, дефолтных паролей, debug-настроек в production-конфигурации?
6. Настроены ли механизмы логирования и мониторинга безопасности?

После приёмки

1. Есть ли процесс оперативного реагирования на новые CVE в зависимостях?
2. Определена ли ответственная сторона за security-патчи в гарантийный период?
3. Есть ли план обновления при появлении значимых уязвимостей?

Частые ошибки заказчиков

Ошибка 1: «Прошло тестирование — значит безопасно»

Функциональное тестирование (QA) и security-тестирование — разные дисциплины. QA проверяет, работает ли функционал по ТЗ. Security-тест проверяет, можно ли этот функционал сломать, обойти или использовать против владельца системы.

Ошибка 2: «Мы проверили в конце»

Находить и устранять архитектурные проблемы безопасности (например, неправильно выстроенную авторизацию) после завершения разработки — значительно дороже и болезненнее, чем заложить правильные требования на старте. OWASP прямо указывает: находить проблемы безопасности на этапе требований несравнимо дешевле, чем после сборки продукта [20].

Ошибка 3: «Мы используем хороший фреймворк — значит всё безопасно»

Фреймворки снижают риск типовых ошибок, но не исключают их. Ошибки бизнес-логики, неправильные настройки, уязвимые версии зависимостей возникают независимо от фреймворка.

Ошибка 4: «Подрядчик сказал, что проверил»

Самопроверка конфликтует с интересами: никто не заинтересован находить у себя проблемы накануне сдачи. Независимый аудит и пентест от третьей стороны дают объективный взгляд именно потому, что у аудитора нет мотива скрывать находки [18].

Ошибка 5: «Один сканер закрывает все риски»

Сканеры SAST выдают ложные срабатывания (false positives) и пропускают уязвимости логики доступа (false negatives). Только комбинация SAST + SCA + ручной ревью + пентест даёт достаточное покрытие [16].

Фактор AI: новая переменная в уравнении заказчика

Современные команды разработки активно используют AI-ассистентов. Это реальность, а не исключение. По данным Stack Overflow Developer Survey 2025, 84% разработчиков использовали или планировали использовать AI-инструменты [21]. 25% стартапов из зимнего когорта Y Combinator 2025 сообщили о кодовых базах, на 95% состоящих из AI-генерируемого кода [22].

Скорость выросла. Но контроль не вырос с той же скоростью.

Ключевые риски AI-кодинга, которые заказчик должен учитывать при приёмке:

1. Захардкоженные секреты: AI-assisted коммиты утекают секреты в ~3,2% случаев против более низкого показателя для чисто человеческого кода [2].
2. Ошибки аутентификации и сессий: AI вдвое чаще вносит небезопасную обработку паролей и небезопасные ссылки на объекты [9].
3. XSS-уязвимости: встречаются в 2,74 раза чаще в AI-PR [9].
4. Ошибки бизнес-логики: алгоритмические ошибки появляются более чем вдвое чаще [9].
5. «Галлюцинированные» зависимости: AI иногда импортирует несуществующие пакеты, которые злоумышленники могут опубликовать под этим именем в реестре — классическая атака package confusion.

Инструменты вроде HighVibe позиционируются как слой контроля именно для этого сценария: они анализируют конкретное изменение — код, конфигурации, зависимости, служебные файлы — до момента merge и дают команде короткий и понятный сигнал о том, что в этом PR действительно критично [23]. Это не замена SAST/SCA/пентеста, а дополнительный слой контроля в точке, где риск пропустить проблему максимален — перед слиянием.

Тренды и что ждёт впереди

Нормативное давление нарастает

Регуляторы по всему миру последовательно повышают требования к прозрачности и безопасности ПО. В 2025 году CERT-In (Индия) сделал SBOM обязательным для критической инфраструктуры [13]. NIST выпустил черновик SSDF 1.2 [5]. ЕС через Cyber Resilience Act движется в сторону обязательной security-документации для цифровых продуктов. Российский ФСТЭК обновил требования через ГОСТ Р 56939-2024 [6].

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

PTaaS вместо разового пентеста

Модель ежегодного пентеста устаревает для продуктов с активным CI/CD. Продукт, выкатывающий изменения еженедельно, успевает несколько раз измениться за время проведения классического пентеста. PTaaS-модель (Penetration Testing as a Service) с непрерывным тестированием лучше соответствует реальному темпу разработки [17].

SBOM как стандарт сдачи

Требование предоставлять SBOM при передаче продукта заказчику быстро становится нормой — по аналогии с тем, как документация к API стала обязательной частью сдачи 10 лет назад. Заказчикам стоит начинать требовать это уже сейчас, не дожидаясь регуляторного обязательства.

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

Если вы заказчик, который принимает разработанный продукт или планирует новый проект, вот минимально необходимые шаги:

1. Добавить требования безопасности в ТЗ или договор до старта — с явным перечнем артефактов (отчёты сканеров, SBOM, пентест).
2. Спросить подрядчика на этапе выбора: какие инструменты SAST/SCA интегрированы в пайплайн, какова политика в отношении AI-генерируемого кода.
3. Включить security-аудит как обязательный этап перед приёмкой — не как опцию, а как условие оплаты.
4. Требовать пентест от независимой стороны для критических систем. Принимать ретест как подтверждение устранения.
5. Получить SBOM в машиночитаемом формате при каждом значимом релизе.
6. Определить ответственного за security-патчи в гарантийный период.

Безопасность не появляется автоматически, когда «всё работает». Она появляется, когда у заказчика есть чёткие требования, а у подрядчика — ответственность за их выполнение.

Источники

[1] Veracode — GenAI Code Security Report 2025 — https://www.veracode.com/resources/genai-code-security-report

[2] Docker Blog — "AI Coding Agent Horror Stories: Security Risks Explained" — https://www.docker.com/blog/ai-coding-agent-horror-stories-security-risks/

[3] OWASP Developer Guide — "Secure development and integration" — https://devguide.owasp.org/en/02-foundations/02-secure-development/

[4] CISA — "NIST SP 800-218, Secure Software Development Framework V1.1" — https://www.cisa.gov/resources-tools/resources/nist-sp-800-218-secure-software-development-framework-v11-recommendations-mitigating-risk-software

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

[6] Anti-Malware.ru — "ГОСТ Р 56939-2024: как проводить аудит безопасной разработки ПО" — https://www.anti-malware.ru/analytics/Technology_Analysis/GOST-R-56939-2024-Secure-Development-Audit

[7] Unicis.Tech — "OWASP ASVS Compliance Software — Application Security Verification Standard" — https://www.unicis.tech/frameworks/owasp-asvs/

[8] OWASP Foundation — "OWASP Product Security Guide" — https://owasp.org/www-project-product-security-guide/

[9] Help Net Security — "AI code looks fine until the review starts" — https://www.helpnetsecurity.com/2025/12/23/coderabbit-ai-assisted-pull-requests-report/

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

[11] CodeAnt.ai — "Secure Code Audits in 2025: Checklist and Best Practices" — https://www.codeant.ai/blogs/source-code-audit-checklist-best-practices-for-secure-code

[12] OX Security — "Top 5 SBOM Tools 2025: Secure Your Software Supply Chain" — https://www.ox.security/blog/sbom-tools/

[13] GetAstra — "Fintech's Guide to CERT-In SBOM Guidelines 2025" — https://www.getastra.com/blog/compliance/cert-in-sbom-guidelines-2025/

[14] CISA — "Software Bill of Materials (SBOM)" — https://www.cisa.gov/sbom

[15] RBC Компании — "Технический аудит качества кода: кому нужен и как его правильно проводить" — https://companies.rbc.ru/news/64oOw7Zjwj/tehnicheskij-audit-kachestva-koda-komu-nuzhen-i-kak-ego-pravilno-provodit/

[16] RTM Group — "Аудит кода: уязвимости и цена анализа" — https://rtmtech.ru/services/audit-koda/

[17] Penligent.ai — "Outsource Penetration Testing with AI Without Losing Control" — https://www.penligent.ai/hackinglabs/outsource-penetration-testing-with-ai-without-losing-control/

[18] NetSPI — "The Balancing Act of In-House vs Third-Party Penetration Testing" — https://www.netspi.com/blog/executive-blog/penetration-testing-as-a-service/in-house-vs-third-party-penetration-testing/

[19] GetAstra — "Third-Party Penetration Testing (Updated Guide in 2026)" — https://www.getastra.com/blog/security-audit/third-party-penetration-testing/

[20] OWASP / DEV.to — "Security in Requirements phase" — https://dev.to/owasp/security-in-requirements-phase-33ad

[21] Stack Overflow — Developer Survey 2025 — https://survey.stackoverflow.co/2025/

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

[23] HighVibe — Слой контроля безопасности AI-кодинга — https://highvibe.dev