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

Дмитрий Третьяков

Руководитель отдела методологии и практик управления кибербезопасностью Infosecur

Содержание

Введение
Почему «левый» код убивает Shift Left
Типичные проблемы при контроле внешних разработчиков
Стандарты, о которых нельзя молчать
Контрольные процедуры: от договора до продакшена
Интеграция со смежными процессами
Как выстроить процесс системно
FAQ: частые вопросы
Читайте также

Введение

Концепция «Shift Left» стала мантрой индустрии: встройте SAST, DAST и SCA в CI/CD-пайплайн - и уязвимости будут выявлены до релиза. Но что происходит, когда ядро продукта пишет аутсорс-команда, а вы получаете готовый билд раз в квартал по e-mail? Все ваши сканеры молчат ровно до того момента, когда чужой код оказывается в вашем репозитории. К этому времени исправление обходится в десятки раз дороже, а о «левом сдвиге» не может быть и речи.

Почему «левый» код убивает Shift Left

Типичная картина - бизнес заключает договор с разработчиком, фиксирует функциональные требования и забывает про нефункциональные. В результате:

Исходный код передаётся через файлообменники или архивы в мессенджерах, минуя инструменты безопасной разработки.
Сторонние библиотеки не проходят проверку на уязвимости (SCA), а лицензионные риски игнорируются.
Уязвимости в поставленном коде обнаруживаются постфактум, когда интеграция уже завершена и откат невозможен.

Shift Left предполагает, что безопасность встроена в процесс создания кода. Если код создаётся за периметром вашего контроля, вы фактически сдвигаете безопасность не влево, а вправо - к этапу приёмки, где каждая найденная проблема превращается в конфликт сроков и бюджетов.

Рисунок 1. Концептуальная схема контроля жизненного цикла внешней разработки.

Типичные проблемы при контроле внешних разработчиков

Даже когда процессы формально выстроены, на практике возникают системные проблемы, которые сводят усилия на нет.

Разные подходы к оценке критичности. Классический конфликт: заказчик видит уязвимость с CVSS 9.8 и требует срочного исправления, а подрядчик ссылается на Temporal Score, отсутствие эксплойта в публичном доступе и специфику окружения, где компонент не используется. Без согласованной методики приоритизации каждая такая уязвимость становится предметом спора, а SLА по устранению превращается в фикцию.

Разногласия по SLA и стоимости исправлений. Аутсорсер часто закладывает в договор только функциональные требования. Устранение уязвимостей, выявленных уже после приёмки, трактуется как «доработка» и оплачивается отдельно. В результате заказчик вынужден либо платить повторно, либо мириться с рисками.

«Чёрный ящик» в процессе разработки. Подрядчик демонстрирует зрелый подход «на бумаге», но реальные артефакты (отчёты SAST, журналы ревью, SBOM) отсутствуют или предоставляются выборочно. Проверить заявления без доступа к процессам невозможно.

Формальное закрытие договора. Отношения с контрагентом завершаются без согласования в части ИБ: не проверено, остались ли бэкдоры, не переданы ли секреты, не сохранены ли копии кода. Это создаёт отложенные риски, которые проявляются уже после расторжения договора.

Лицензионные и Supply Chain риски. В поставленном коде обнаруживаются компоненты с несовместимыми лицензиями (GPL в проприетарном продукте) или библиотеки с известными уязвимостями, которые не обновлялись годами. SCA-проверка на стороне заказчика становится сюрпризом, а не штатной процедурой.

Стандарты, о которых нельзя молчать

Международные стандарты прямо указывают на необходимость контроля поставщиков на всех этапах жизненного цикла ПО.

ISO/IEC 27001:2022. Контроль A.15 (управление отношениями с поставщиками) требует, чтобы требования информационной безопасности были зафиксированы в договорной документации до начала работ. Контроль A.8.25 (безопасный жизненный цикл разработки) обязывает распространять политики безопасной разработки на внешний код.

COBIT 2019. Процесс APO10 (Managed Vendors) предписывает оценивать зрелость поставщика на основе объективных метрик, а BAI03 (Managed Solutions Identification and Build) — интегрировать проверки безопасности в цикл приёмки решений, включая сторонние.

OWASP SAMM и NIST SSDF. Оба фреймворка подчёркивают, что верификация сторонних компонентов должна быть встроена в пайплайн наравне с проверкой собственного кода.

Контрольные процедуры: от договора до продакшена

Опираясь на наш опыт выстраивания процессов ИБ и ИТ, мы рекомендуем следующий набор контрольных процедур для работы с внешними разработчиками.

1. Договорной контур. Все требования к безопасности — стандарты кодирования, допустимые библиотеки, SLA по устранению уязвимостей — фиксируются в договоре и приложениях к нему. Все требования и обязательства со стороны внешнего контрагента должны быть оформлены в виде договорной документации. Важно также выстроить процесс постоянной актуализации требований и шаблонов договоров. Не допускается завершение отношений с контрагентом без предварительного согласования возможности закрытия договора в части ИБ.

2. Объективная приёмка. Принятие решений в отношении контрагента должно осуществляться на основании объективных свидетельств и метрик. Решение о приёмке кода принимается на основании метрик: количество критических и высоких уязвимостей по CVSS, покрытие тестами, результаты SCA. Субъективная оценка «код выглядит нормально» не принимается.

3. Изолированный репозиторий. Исходный код от внешнего разработчика загружается в выделенный репозиторий, к которому подключены SAST, SCA и секрет-сканеры. Передача кода по email, через файлообменники и мессенджеры запрещена.

4. Приоритизация уязвимостей. Уязвимости ранжируются по CVSS Base Score с учётом Temporal Score и бизнес-контекста. Критические дефекты блокируют приёмку.

5. Песочница для коробочных решений. Готовые продукты и компоненты тестируются в изолированной среде (Sandbox) до развёртывания в промышленном контуре.

Интеграция со смежными процессами

Управление поставщиками - это не изолированный процесс. Его эффективность напрямую зависит от того, насколько плотно он встроен в смежные процессы ИТ и ИБ. Без такой интеграции контроль остаётся формальным.

Рисунок 2. Взаимосвязь процесса управления поставщиками со смежными процессами.

Управление закупками. Требования ИБ должны появляться не после выбора подрядчика, а на этапе формирования тендерной документации. Критерии оценки поставщика (наличие сертификатов, зрелость процессов безопасной разработки, практика раскрытия уязвимостей) становятся частью объективных свидетельств при принятии решения.

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

Управление жизненным циклом ПО. Внешний код должен встраиваться в единый SDLC компании: те же этапы ревью, те же шлюзы безопасности, те же инструменты. Иначе «левый» код становится параллельной реальностью, живущей по своим правилам.

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

Управление изменениями и релизами. Каждая поставка от подрядчика проходит через стандартный процесс изменений: оценка влияния, согласование, план отката. Хаотичные «срочные патчи» это прямой путь к инцидентам.

Управление инцидентами. Если во внешнем коде обнаружен бэкдор или уязвимость нулевого дня, должен быть понятен процесс эскалации: кто уведомляет, в какие сроки, как организуется совместное расследование.

Управление ИТ-активами и конфигурациями. Сторонние компоненты должны быть учтены в CMDB и реестре активов. Иначе при инцидентах типа Log4Shell вы просто не узнаете, где в инфраструктуре используется уязвимая библиотека, поставленная подрядчиком год назад.

Как выстроить процесс системно

Разрозненные проверки не дают устойчивого результата. Необходим комплексный подход, охватывающий процессы управления жизненным циклом ПО, управления уязвимостями, управления конфигурациями и управления ИБ в отношениях с поставщиками.

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

FAQ: частые вопросы

Как разрешать разногласия с подрядчиком по критичности уязвимостей?

Зафиксируйте в договоре единую методику приоритизации: CVSS Base Score + Temporal Score + бизнес-контекст. Для спорных случаев предусмотрите эскалацию до CISO сторон и независимую верификацию.

Можно ли доверять внешнему разработчику, если у него есть сертификат ISO 27001?

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

Когда нужно начинать контролировать внешнего разработчика?

С момента формирования технического задания. Требования ИБ должны быть зафиксированы в договоре до написания первой строки кода.

Остались вопросы?

Оставьте свои контактные данные, чтобы мы могли связаться с вами для дальнейших шагов.

КИИ

Информационная безопасность в финансовом секторе: новый подход к оценке и защите

Постановление № 92 от 06.02.2026: новые правила категорирования КИИ в банках, ежегодная отчётность, штрафы по ст. 13.12.2 КоАП и что делать банкам.

06.11.2026

Читать

Законодательство

Cookie и персональные данные: что нужно учитывать владельцам сайтов

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

07.11.2026

Читать

Ai / Безопасность ИИ

Этапы подготовки к сертификации ISO/IEC 42001

Что такое ISO/IEC 42001 и как подготовиться к сертификации: структура стандарта, 5 этапов от обследования до аудита, цикл PDCA.

10.11.2026

Читать

Сертификация ISO

10 шагов по внедрению ISO/IEC 27001

Пошаговый план внедрения ISO/IEC 27001 в 10 шагов: от области применения СУИБ до внутреннего аудита. Типовой срок подготовки — 5–12 месяцев.

05.11.2026

Читать

Другие статьи

Все статьи

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

Оставайтесь на шаг впереди

Дайджесты

Акции

Чек-листы

Памятки

Новые услуги

Аутсорс-разработка: Как «левый» код убивает ваш «Shift Left»

Содержание

Введение

Почему «левый» код убивает Shift Left

Типичные проблемы при контроле внешних разработчиков

Стандарты, о которых нельзя молчать

Контрольные процедуры: от договора до продакшена

Интеграция со смежными процессами

Как выстроить процесс системно

FAQ: частые вопросы

Как разрешать разногласия с подрядчиком по критичности уязвимостей?

Можно ли доверять внешнему разработчику, если у него есть сертификат ISO 27001?

Когда нужно начинать контролировать внешнего разработчика?

Читайте также:

Остались вопросы?

Информационная безопасность в финансовом секторе: новый подход к оценке и защите

Cookie и персональные данные: что нужно учитывать владельцам сайтов

Этапы подготовки к сертификации ISO/IEC 42001

10 шагов по внедрению ISO/IEC 27001

Другие статьи

feeds:title