Корпоративная разработка: существующие риски и практики обеспечения доверенности в коде

При разработке любого программного продукта критически важно обеспечить безопасность кода, избежать дефектов в функционале («битых фичей»), предотвратить наличие несанкционированных точек входа (бэкдоров) и устранить другие потенциальные уязвимости.
Для достижения этих целей необходимо включить в процесс разработки этапы проверки внедряемых фрагментов кода, а также применять практики обеспечения доверия к коду.
Меня зовут Сергей Склабовский. Я менеджер продукта в VK Tech. В этой статье я хочу рассказать о существующих рисках совместной разработки и основных подходах обеспечения доверенности в программном коде при разработке.
Вызовы, стоящие перед компаниями в части безопасности
Число кибератак на российские компании в 2023 году увеличилось минимум на 50%. По итогам 2024 года (относительно 2023 года) количество кибератак на российские компании выросло еще в 2,5 раза и достигло 130 000 случаев.
По данным Positive Technologies:
-
В 2024 году хакеры чаще всего атаковали веб-приложения госучреждений (18%), ИТ-компаний (9%) и ритейла (7%).
-
В 44% случаев точкой входа в инфраструктуру становились веб-приложения, расположенные на сетевом периметре организации.
-
Основными последствиями атак стали утечка конфиденциальной информации (44%), нарушение работы компании (33%), использование ресурсов жертвы для дальнейших атак (15%).
-
Чаще всего нарушение работы компании приводило к недоступности клиентских сервисов, что особенно критично для госучреждений, ИТ-отрасли и ритейла.
При этом злоумышленники используют все возможные векторы атак, в том числе баги в открытых библиотеках и «черные репозитории», содержащие заведомо уязвимые компоненты. Таким образом, использование Open Source становится все более небезопасным — в ПО с открытым исходным кодом все чаще включают вредоносное содержимое.
Примечание: Open Source постепенно отходит от изначальных принципов и в части свободного распространения программного обеспечения — в том числе по инициативе отдельных организаций ограничиваются в правах мейнтейнеры, имеющие отношение к России. Таким образом, считать Open-Source-компоненты полностью независимыми уже не всегда корректно.
Вместе с тем полностью отказаться от применения открытых библиотек, Open-Source-компонентов и наработок других команд зачастую проблематично: с их помощью команды разработки могут быстро включить нужный компонент в состав продукта, не тратя время на разработку.
Соответственно, текущие вызовы вынуждают компании искать баланс, чтобы, с одной стороны, использовать Open-Source-компоненты и наработки других команд, которые значительно ускоряют разработку, а с другой — не делать это в ущерб безопасности продукта.
Чтобы компенсировать эти риски и издержки, компаниям надо уравновешивать их с помощью внутрикорпоративных практик, процессов, принятых паттернов разработки программных продуктов и, главное, внедрения практик обеспечения доверенности в коде.
Что такое обеспечение доверенности
Практика обеспечения доверенности в коде — комплекс мер, направленных на гарантирование безопасности, надежности и прозрачности сторонних библиотек и инструментов, интегрируемых в ИТ-продукт. Ее цель — минимизировать риски, связанные с уязвимостями, скрытыми бэкдорами, лицензионными конфликтами или недобросовестными изменениями в Open-Source-коде.
К ключевым аспектам обеспечения доверенности в коде при разработке относятся:
-
верификация источников (использование проверенных репозиториев, проверка подписей артефактов);
-
аудит зависимостей (сканирование на уязвимости, например через OWASP);
-
аудит кода и лицензий (проверка на соответствие лицензионным требованиям, статический анализ);
-
мониторинг уязвимостей и обновление зависимостей;
-
изоляция и минимизация рисков (применение Sandbox-окружений для теста сторонних компонентов, разграничение прав доступа).
Наряду с этим одной из фундаментальных практик для обеспечения доверенности кода при работе с Open-Source-компонентами и наработками внешних команд является контроль цепочки поставок (Software Supply Chain Security).
Supply Chain Security
Контроль цепочки поставок (Software Supply Chain Security) — это набор процессов, инструментов и практик, направленных на защиту всех этапов создания программного обеспечения — от исходного кода и сторонних компонентов до сборки, доставки и развертывания.
Цель методологии — предотвратить компрометацию ПО на любом этапе его жизненного цикла из-за уязвимостей, подделки компонентов, злонамеренных изменений или ошибок в зависимостях.

Как правило, контроль цепочки поставок предполагает:
-
внедрение практик DevSecOps, в том числе контроль процесса разработки с использованием инструментов статического и динамического анализа;
-
анализ рисков на этапе планирования;
-
тестирование перед деплоем;
-
постоянный мониторинг после выпуска;
-
следование стандартам SLSA (Supply-Chain Levels for Software Artifacts).
Для внедрения всех процессов контроля цепочки поставок, как правило, компании строят доверенный репозиторий.
Доверенный репозиторий
Доверенный репозиторий — централизованное хранилище предварительно проверенных, безопасных и лицензионно чистых компонентов, используемых внутри компании при разработке ПО. Причем к хранимым компонентам могут относиться как наработки внутренних команд, так и открытые библиотеки с Open-Source-решениями.
Главная задача внедрения доверенного репозитория — минимизировать риски, связанные с использованием непроверенных компонентов, и ускорить разработку за счет повторного использования доверенных ресурсов.
Доверенный репозиторий отвечает за определенный пул задач и этапов:
-
загрузка исходного кода и артефактов, и адаптация конвейеров сборки со стороны участника команд разработки;
-
автоматизированный анализ на уязвимости различными инструментами безопасной разработки ПО (с последующим ручным разбором результатов анализа);
-
публикация для переиспользования другими участниками (в случае успешных результатов проверки критериев безопасности ПО).
Помимо этого, доверенный репозиторий обеспечивает техническую интеграцию инструментов и ресурсов смежных подсистем в единый пользовательский интерфейс.

Роли
При работе с доверенным репозиторием все пользователи делятся по ролям с соответствующим набором обязанностей.
Упрощенно можно выделить несколько групп участников всего процесса:
-
администратор, который распределяет права доступа;
-
руководители команд;
-
инженеры (добавляются в проект руководителями и зависят от них);
-
сотрудники ИБ.
При этом администратор и сотрудники ИБ управляют репозиторием, а тимлиды и инженеры только используют его.

Обязанности в репозитории распределяются следующим образом:
-
Администратор и тимлиды отвечают за предоставление доступа и мониторинг.
-
За разработку и коммуникации по рабочим вопросам отвечают инженеры и сотрудники ИБ. То есть инженер пушит изменения, сотрудник ИБ его анализирует и принимает решение о допустимости подписания и публикации артефакта.
Сценарий получения артефактов из доверенного репозитория
Базовый сценарий работы с доверенным репозиторием обычно сводится к нескольким этапам:
-
Команда разработки запрашивает нужные артефакты из доверенного репозитория.
-
Запрашиваемые артефакты комплексно сканируются на наличие багов и уязвимостей с помощью различных методик и инструментов (в том числе SAST/DAST).
-
Если уязвимостей нет, артефакт передается разработчику.
-
Если сканирование выявляет уязвимости, к принятию решений подключается ответственный специалист (как правило, из отдела ИБ), который в ручном режиме принимает решение о критичности уязвимостей и допустимости передачи артефакта.

Примечание: В спорные моменты во всех сценариях решение о пропуске или блокировке артефактов с определенными дефектами или ошибками принимает специалист по информационной безопасности. Поэтому, чтобы исключить человеческий фактор и разночтения, надо унифицировать критерии и стек для принятия решений во всей компании. Только так можно уйти от ситуаций, когда по одной и той же ошибке разные специалисты принимают разные решения.
Но команда разработки должна иметь возможность не только запрашивать уже имеющиеся в доверенном репозитории артефакты, но и загружать в него свои.
Сценарий публикации артефактов
Загрузка в доверенный репозиторий также предполагает обязательную проверку всех загружаемых артефактов на наличие уязвимостей, вредоносного кода, бэкдоров и других проблем безопасности.
Обычно подобная проверка выстраивается по следующему алгоритму:
-
Разработчикам предоставляется доступ к системе, функции, компоненту.
-
Разработчик выбирает один из сценариев проверки: «Публикация артефакта из исходного кода», «Публикация артефакта из исходного кода с DAST-проверкой», «Публикация артефакта в системе из готового образа», «Публикация артефакта из готовой библиотеки» (подробно о каждом из них ниже).
-
Создается соответствующий проект с предварительно выбранными настройками.
-
Выполняется первичный анализ исходного кода и зависимостей загружаемого артефакта.
-
Проводится глубокий анализ и разбор обнаруженных уязвимостей.
-
В случае обнаружения уязвимостей ответственный специалист в ручном режиме обрабатывает запросы.
-
Проверенный и одобренный артефакт и его метаданные публикуются в доверенном репозитории.
Теперь подробнее о каждом из четырех возможных сценариев.
Сценарий «Публикация артефакта из исходного кода»
Первый сценарий — публикация артефакта из исходного кода.
Сценарий, как правило, стартует с создания проекта в GitLab, где уже есть готовый пайплайн.
Здесь возможны два сценария развития событий:
-
использование отдельного пайплайна для каждого стека;
-
использование пайплайна с ветвлением — процессы выбираются в зависимости от стека.
Примечание: Мы обычно используем второй подход.
Далее после написания кода и его отправки в репозиторий запускается проверка, в том числе SAST (Static Application Security Testing, статическое тестирование) с помощью PT Application Inspector.
Если в процессе проверки проблем не обнаруживается, происходит подписание и публикация артефакта.
Если проблемы есть, подключается специалист по информационной безопасности, который принимает решение о допустимости подписания и размещения артефакта.

Сценарий «Публикация артефакта из исходного кода с DAST-проверкой»
Второй сценарий — публикация артефакта из исходного кода с DAST-проверкой. То есть пользователь уже работает не с исходным кодом, а непосредственно с артефактом.
По сути, сценарий может быть реализован в том же конвейере. При этом, помимо SAST-проверки с помощью PT Application Inspector, также добавляется DAST-тестирование (Dynamic Application Security Testing, динамическое тестирование безопасности приложения) c помощью PT BlackBox.

Далее алгоритм схож с первым сценарием: если ошибок нет, артефакт подписывается и публикуется, если ошибки есть, подключается специалист по ИБ, который самостоятельно принимает решение.
Сценарий «Публикация артефакта в системе из готового образа»
Третий сценарий — публикация артефакта в репозитории уже из готового образа.
Тут, по сути, разница в том, что на вход подается не исходный код или промежуточный артефакт, а полностью собранный образ, готовый к использованию.
Соответственно, пайплайн несколько отличается, но логика работы остается прежней.
-
Есть задача, которая в определенный момент перехватывает данные готового образа.
-
Далее джоба передает эти данные в ASPM-платформу AppSec.Hub для детального анализа и обработки.
-
ASPM-платформа AppSec.Hub выполняет проверку. Если автоматическая проверка не обнаруживает проблем, образ подписывается и публикуется в доверенном репозитории. Если проблемы есть, подключается ответственный специалист, который самостоятельно принимает решение о допустимости публикации.

Стоит отметить, что здесь обязательно используется решение класса Container Security для мониторинга, анализа и защиты контейнеров в реальном времени. Также обязательно добавляется композиционный анализ (проверка компонентов, входящих в состав программного артефакта).
«Публикация артефакта из готовой библиотеки и/или исполняемого файла»
В этом сценарии речь идет о работе с готовыми библиотеками и/или исполняемыми файлами, которые используются в качестве зависимостей для разрабатываемого ПО. Алгоритм публикации артефакта в таком случае несколько сложнее.
-
Артефакт (например, библиотека) скачивается из внешнего источника.
-
После скачивания артефакт проходит первичную проверку на наличие известных уязвимостей и соответствие стандартам безопасности.
-
Далее артефакт собирается в защищенной среде (песочнице).
-
После сборки артефакт снова проверяется на наличие уязвимостей и других проблем.
-
Если все проверки успешно пройдены, артефакт подписывается и отправляется в доверенный внутренний репозиторий.
Основная задача в данном сценарии — отслеживать и проверять на наличие уязвимостей любые изменения в готовой библиотеке.

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

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

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

Условно все сводится к упомянутым выше подходам:
-
Участникам разработки предоставляется доступ к единому доверенному репозиторию.
-
Определяется сценарий работы с артефактами и библиотеками.
-
Проверяется успешность завершения пайплайна.
-
Если пайплайн завершается успешно, артефакт подписывается, складывается в групповое хранилище, а потом передается в доверенный репозиторий, из которого доступен всем.
-
Если пайплайн останавливается, выполняется анализ заблокированных артефактов и/или анализ разбора уязвимостей (в зависимости от причины остановки пайплайна).
-
После проверки уязвимостей пайплайн перезапускается снова до момента, пока артефакт не будет успешно подписан.
При этом ключевыми компонентами обеспечения стабильной работы этой концепции являются:
-
выработка единых паттернов работы и принятия решений — чтобы все сотрудники на каждом этапе четко понимали, что делать и что учитывать;
-
корректный выбор инструментов для выстраивания всего пайплайна разработки и внедренных проверок для каждого из сценариев;
-
оптимальная настройка инструментов безопасности — чтобы, с одной стороны, было минимум ложных срабатываний, а с другой — ничего критичного не было пропущено;
-
обязательность применения инструментов и проведения проверок, то есть соблюдение практики Quality Gate, при которой любое взаимодействие с артефактами возможно только после их проверки на безопасность.
Только в таком случае получится добиться доверенности в программном коде.
Кратко о главном
Использование готовых компонентов и привлечение к разработке нескольких команд — часто необходимая практика. Но использование таких подходов требует высокого уровня зрелости внутри компании в части обеспечения достоверности кода и внедряемых фичей.
Упомянутые в статье практики — лишь один из элементов обеспечения безопасной разработки. Наряду с ними также важно думать об управлении уязвимостями инфраструктуры, контролировать сетевой трафик, мониторить события ИБ и предусматривать защиту от атак разных профилей.
Безусловно, набор применяемых подходов и инструментов будет зависеть от специфики компании и разрабатываемых продуктов. Но важно понимать, что обеспечение достоверности в коде — общая задача, поэтому каждый участник разработки на своем этапе должен думать о безопасности продукта.
Качайте наш бесплатный white paper «Безопасность корпоративной разработки: как совместить open-source и защиту от киберугроз» и внедрите проверенные решения для безопасной разработки.
Автор: serg_sklabovskiy