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

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

К процессу приема результата нужно отнестись со всей серьезностью, так как гарантировать стопроцентное отсутствие закладок в чужом коде невозможно. Современный проект – это тысячи, а порой и миллионы строк кода плюс десятки сторонних библиотек, и проверить каждую строку вручную нереально. Задача заказчика заключается в том, чтобы выстроить процесс приемки, при котором внедрить закладку, и остаться незамеченным становится слишком рискованным и дорогим занятием для недобросовестного подрядчика. Далее рассмотрим, как грамотно и поэтапно выстроить процесс, что закладывать в договор, как организовать саму проверку и какие инструменты для этого используются.

Договор – это первый рубеж защиты. Безопасная приемка начинается не в момент получения кода, а на этапе подписания договора. Именно там имеет смысл закрепить несколько вещей. Во-первых, право заказчика на аудит: должна быть возможность в любой момент проверить код своими силами или силами приглашенной команды, без возражений со стороны подрядчика. Во-вторых, в договоре нужно определить состав того, что передается по итогам работы. Это должен быть не исполняемый файл или ссылка на рабочий сервис, а полный исходный код, история изменений в системе контроля версий, документация по архитектуре и инструкция по сборке, перечень используемых библиотек с версиями. Такой комплекс называется SBOM – Software Bill of Materials – cпецификация состава программного обеспечения, своего рода паспорт состава продукта. Если подрядчик готов отдать только готовый файл без исходников – это повод насторожиться. Без исходного кода экспертная проверка невозможна, и заказчик остается полностью зависим от разработчика. В-третьих, полезно заранее зафиксировать в техническом задании явные требования безопасности: запрет на встроенные в код пароли и ключи доступа, обязательное логирование критичных операций, отсутствие недокументированных функций и учетных записей. Тогда любой спорный момент при приемке будет решаться по заранее согласованным правилам, а не на словесных переговорах постфактум.

Работа с кодом – это центральная часть приемки и здесь важно соблюдать несколько простых принципов. Первоначально код всегда нужно разворачивать в изолированной среде без доступа к боевым данным, внутренней сети и интернету, кроме явно разрешенных адресов. Таким образом, даже если в коде есть что-то опасное, исключается возможность причинения реального вреда на этапе проверки. Далее стоит убедиться, что рабочий продукт действительно собирается из переданного исходного кода, для этого необходимо провести так называемую воспроизводимую сборку. Это исключает ситуацию, когда безопасные исходники сопровождаются подмененным рабочим файлом, который на деле отличается от того, что лежит в репозитории. Саму проверку лучше поручать нескольким командам. Хорошая практика – привлекать сразу два независимых взгляда: внутреннего специалиста, знакомого с архитектурой продукта, и иного независимого эксперта по безопасности, который видит эту архитектуру впервые. Это может быть как внутренний, так и внешний специалист. Свежий взгляд со стороны нередко замечает то, что человек, погруженный в проект, давно воспринимает как норму.

При приемке важно использовать технические инструменты проверки кода. Статический анализ (SAST): программа читает исходный код, не запуская его, и автоматически находит типовые проблемы, такие как вписанные пароли и ключи в коде, опасные конструкции, распространенные уязвимости. Это быстрый и недорогой способ отсеять большинство очевидных проблем, хотя хорошо замаскированную закладку такой анализ не всегда заметит. Анализ состава зависимостей (SCA): отдельная проверка сторонних библиотек, которые использует продукт. Значительная часть современных атак приходит именно через внешние компоненты, например, устаревшую библиотеку с уже известной уязвимостью или, что хуже, поддельный пакет с названием, похожим на оригинальный. SCA сверяет используемые версии с базами известных уязвимостей и подсвечивает подозрительные зависимости. Динамическая проверка (DAST): приложение запускают в тестовой среде и наблюдают за его реальным поведением, куда оно обращается по сети, как реагирует на нестандартные данные, не проявляются ли функции, которые не видны при простом чтении кода.

Помимо технических инструментов краеугольное место занимает ручное код-ревью – это самый трудозатратный, но и самый важный этап. Автоматические инструменты хорошо ловят типовые технические ошибки, но не понимают бизнес-логику продукта. Увидеть, что где-то есть резервный вход в систему, скрытый режим администратора или условие, активирующее нештатное поведение при определенных обстоятельствах, способен только человек, разбирающийся в контексте проекта. В первую очередь ручной проверке подлежат модули авторизации, работа с платежами и персональными данными, а также механизмы удаленного обновления, потому через них можно внести закладку уже после приемки, когда бдительность снижается.

Помимо кода есть организационные признаки, которые сами по себе не являются доказательством, но должны насторожить. Например, отказ подрядчика передать полную историю изменений, а готовность отдать только финальную версию файлов. Сопротивление независимому аудиту или настойчивое предложение проверять код исключительно силами самого подрядчика. Функциональность, которой не было в техническом задании и которую объясняют фразой вроде «на всякий случай сделали». Использование малоизвестных, недавно появившихся библиотек без репутации и истории поддержки. Каждый такой момент в отдельности можно объяснить, но, если их набирается сразу несколько – это повод для более пристального разбора, а не для подписания акта приемки.

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

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

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

Автор: Юлия Сонина, старший аналитик