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

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

Меня зовут Сергей Склабовский. Я менеджер продукта в 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-решениями.

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

Доверенный репозиторий отвечает за определенный пул задач и этапов:

• загрузка исходного кода и артефактов, и адаптация конвейеров сборки со стороны участника команд разработки;

• автоматизированный анализ на уязвимости различными инструментами безопасной разработки ПО (с последующим ручным разбором результатов анализа);

• публикация для переиспользования другими участниками (в случае успешных результатов проверки критериев безопасности ПО).

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

Роли

При работе с доверенным репозиторием все пользователи делятся по ролям с соответствующим набором обязанностей. 

Упрощенно можно выделить несколько групп участников всего процесса:

• администратор, который распределяет права доступа;

• руководители команд;

• инженеры (добавляются в проект руководителями и зависят от них);

• сотрудники ИБ.

При этом администратор и сотрудники ИБ управляют репозиторием, а тимлиды и инженеры только используют его. 

Обязанности в репозитории распределяются следующим образом:

• Администратор и тимлиды отвечают за предоставление доступа и мониторинг.

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

Сценарий получения артефактов из доверенного репозитория

Базовый сценарий работы с доверенным репозиторием обычно сводится к нескольким этапам:

1. Команда разработки запрашивает нужные артефакты из доверенного репозитория.

2. Запрашиваемые артефакты комплексно сканируются на наличие багов и уязвимостей с помощью различных методик и инструментов (в том числе SAST/DAST).

3. Если уязвимостей нет, артефакт передается разработчику. 

4. Если сканирование выявляет уязвимости, к принятию решений подключается ответственный специалист (как правило, из отдела ИБ), который в ручном режиме принимает решение о критичности уязвимостей и допустимости передачи артефакта.

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

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

Сценарий публикации артефактов

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

Обычно подобная проверка выстраивается по следующему алгоритму:

1. Разработчикам предоставляется доступ к системе, функции, компоненту.

2. Разработчик выбирает один из сценариев проверки: «Публикация артефакта из исходного кода», «Публикация артефакта из исходного кода с DAST-проверкой», «Публикация артефакта в системе из готового образа», «Публикация артефакта из готовой библиотеки» (подробно о каждом из них ниже).

3. Создается соответствующий проект с предварительно выбранными настройками.

4. Выполняется первичный анализ исходного кода и зависимостей загружаемого артефакта.

5. Проводится глубокий анализ и разбор обнаруженных уязвимостей.

6. В случае обнаружения уязвимостей ответственный специалист в ручном режиме обрабатывает запросы.

7. Проверенный и одобренный артефакт и его метаданные публикуются в доверенном репозитории.

Теперь подробнее о каждом из четырех возможных сценариев.

Сценарий «Публикация артефакта из исходного кода»

Первый сценарий — публикация артефакта из исходного кода. 

Сценарий, как правило, стартует с создания проекта в 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 для мониторинга, анализа и защиты контейнеров в реальном времени. Также обязательно добавляется композиционный анализ (проверка компонентов, входящих в состав программного артефакта). 

«Публикация артефакта из готовой библиотеки и/или исполняемого файла»

В этом сценарии речь идет о работе с готовыми библиотеками и/или исполняемыми файлами, которые используются в качестве зависимостей для разрабатываемого ПО. Алгоритм публикации артефакта в таком случае несколько сложнее.

1. Артефакт (например, библиотека) скачивается из внешнего источника.

2. После скачивания артефакт проходит первичную проверку на наличие известных уязвимостей и соответствие стандартам безопасности.

3. Далее артефакт собирается в защищенной среде (песочнице).

4. После сборки артефакт снова проверяется на наличие уязвимостей и других проблем.

5. Если все проверки успешно пройдены, артефакт подписывается и отправляется в доверенный внутренний репозиторий.

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

Технические пайплайны

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

Технический пайплайн подписи артефактов

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

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

Технический пайплайн публикации артефакта

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

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

Концепция работы с единым доверенным репозиторием

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

Условно все сводится к упомянутым выше подходам:

1. Участникам разработки предоставляется доступ к единому доверенному репозиторию.

2. Определяется сценарий работы с артефактами и библиотеками.

3. Проверяется успешность завершения пайплайна.

4. Если пайплайн завершается успешно, артефакт подписывается, складывается в групповое хранилище, а потом передается в доверенный репозиторий, из которого доступен всем.

5. Если пайплайн останавливается, выполняется анализ заблокированных артефактов и/или анализ разбора уязвимостей (в зависимости от причины остановки пайплайна).

6. После проверки уязвимостей пайплайн перезапускается снова до момента, пока артефакт не будет успешно подписан.

При этом ключевыми компонентами обеспечения стабильной работы этой концепции являются:

• выработка единых паттернов работы и принятия решений — чтобы все сотрудники на каждом этапе четко понимали, что делать и что учитывать;

• корректный выбор инструментов для выстраивания всего пайплайна разработки и внедренных проверок для каждого из сценариев;

• оптимальная настройка инструментов безопасности — чтобы, с одной стороны, было минимум ложных срабатываний, а с другой — ничего критичного не было пропущено;

• обязательность применения инструментов и проведения проверок, то есть соблюдение практики Quality Gate, при которой любое взаимодействие с артефактами возможно только после их проверки на безопасность.

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

Кратко о главном

Использование готовых компонентов и привлечение к разработке нескольких команд — часто необходимая практика. Но использование таких подходов требует высокого уровня зрелости внутри компании в части обеспечения достоверности кода и внедряемых фичей. 

Упомянутые в статье практики — лишь один из элементов обеспечения безопасной разработки. Наряду с ними также важно думать об управлении уязвимостями инфраструктуры, контролировать сетевой трафик, мониторить события ИБ и предусматривать защиту от атак разных профилей. 

Безусловно, набор применяемых подходов и инструментов будет зависеть от специфики компании и разрабатываемых продуктов. Но важно понимать, что обеспечение достоверности в коде — общая задача, поэтому каждый участник разработки на своем этапе должен думать о безопасности продукта.

Качайте наш бесплатный white paper «Безопасность корпоративной разработки: как совместить open-source и защиту от киберугроз» и внедрите проверенные решения для безопасной разработки.