Анатолий Карпенко, Luntry: Как только вы что-то внесли в проект в виде зависимости или тулинга – оно моментально становится вашим

Анатолий Карпенко, инженер по автоматизации Luntry и автор блога «Технологический Болт Генона», рассказал порталу Cyber Media, как безопасно выстроить процесс работы с open source-кодом в своем проекте, какой инструментарий для этого используется и почему создание российских платформ для открытого кода не решает всех проблем.

Cyber Media: Насколько безопасно использовать open source-проекты?

Анатолий Карпенко: Для начала хотелось бы определиться, что такое open source-проекты. Не каждый open source можно использовать как вздумается. Более того, если у проекта нет лицензии или явного указания нюансов использования, то лучше связаться с авторами и попросить разъяснить, как и что можно использовать.

Существует Open Source Initiative — организация, которая занимается поддержкой, развитием, стандартизацией и тому подобным для открытого исходного кода. В частности, они ведут список и классификацию различных лицензий.

Сейчас не хочется разводить холивар вида «GPL vs BSD» или «Чей код более открытый?», хотелось сделать акцент на том, что open source – разный, и вариаций его огромное количество. Соответственно, и ответ на вопрос «насколько безопасно использовать», тоже не может быть однозначным.

Cyber Media: Как в крупных open source-проектах между мейнтейнерами распределяются роли, связанные с информационной безопасностью, проверкой кода?

Анатолий Карпенко: Я не знаю о разделении среди мейнтейнеров, возможно оно где-то присуствтует, но массово я такого не встречал. Мейнтейнер обычно отвечает за свое направление или область, наверное, и за безопасность тоже, но в контексте безопасности open source-проектов я говорил бы о том, что происходит вокруг проектов, какие есть инициативы и на что они влияют.

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

Одной из таких организаций, которая помогает опенсорсу быть более безопасным — это Open Source Security Foundation (OpenSSF). Она является частью Linux Foundation и занимается отслеживанием потенциально опасных ситуаций в экосистеме, уязвимостях, разработкой тулинга и тому подобным.

«Базовым» инструментом, с точки зрения OpenSSF, является Scorecard, он проводит комплексный анализ проекта на платформе GitHub и выдает отчет о состоянии проекта в целом: присутствует ли статический анализ и фаззинг, насколько активно проект развивается и т.д.

Kubernetes OpenSSF Scorecard Report

Есть большой список проектов, на которые OpenSSF обращает внимание и называет их Critical Open Source Projects. В списке есть Alpine, Ceph, Linux, Kubernetes, Postgres, Node.JS и т.д. Но это лишь одна часть большого движения вокруг открытых проектов. Если проект популярен, он аккумулирует группы людей и организаций, которые заинтересованы в его развитии, безопасности и надежности.

Яркий пример такого проекта — ядро Linux. Чтобы рассказать хоть немного о том, что вокруг него происходит, потребуется целая серия статей, поэтому приведу несколько фактов:

1. Инструмент syzkaller, когда-то созданный Дмит­рием Вьюко­вым из Google, который позволяет генерировать различные входные данные для системных вызовов ядра (на данный момент не только для Linux). С его помощью обнаружено множество проблем в Linux, которые впоследствии были исправлены.
2. Вокруг ядра много исследователей. Например, подборка ссылок на исследования безопасности Linux есть в репозитории Linux Kernel Exploitation, который курирует Андрей Коновалов.
3. В РФ есть «Центр исследований безопасности системного программного обеспечения», который «специализируется» на повышении безопасности ядра Linux. Центр внес уже больше 400 патчей в ядро Linux. Центр сейчас занимается не только ядром Linux, но и другими проектами: Qemu, Nginx, libvirt, NodeJS и т.д.

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

Cyber Media: За последние годы было несколько громких кейсов с внедрением незадекларированных возможностей в проекты с открытым исходным кодом. Наиболее громкая история – это бэкдор XZ в Linux-дистрибутивах. Как подобные кейсы влияют на сообщество разработчиков и open source-проекты?

Анатолий Карпенко: У подобных историй я вижу две стороны.

Первая — негативная. Каждая подобная громкая история наносит урон «карме» открытого программного обеспечения. Она в каком-то смысле разрушает доверие к open source, может создавать недоверие внутри сообщества. Для меня мир open source никогда не был каким-то чудесным миром, где собрались только лучшие люди планеты, но я знаю людей, которых подобные истории сильно задевают.

Вторая — позитивная. После каждого инцидента происходят какие-то изменения, которые бы позволили избежать подобных ситуаций в будущем. Ну или хотя бы были подняты вопросы, которые ранее не задавались. Например, после случая с XZ был поднят технический вопрос о прозрачности сборки компонента или более концептуальный вопрос «Как так получилось, что такой критичный компонент остался в руках одного человека?». Удивительно, но до того момента это мало кого интересовало.

Если брать другие примеры, то стоит отметить повсеместное введение «второго фактора» для разработчиков в различных экосистемах: они начали вводиться как раз после инцидентов или исследовательских отчетов. И все равно остается много проблем. Например, в недавнем исследовании сказано, что многие из наиболее востребованных пакетов размещены под учетными записями конкретных разработчиков, менее защищенных, чем учетные записи созданных под проект организаций.

Cyber Media: На какие маркеры стоит смотреть при оценке open source-кода перед его использованием в собственной инфраструктуре? Как безопасно выстроить процесс работы с ним?

Анатолий Карпенко: Тут я могу процитировать Алексея Смирнова из CodeScoring: «Сторонние компоненты — ваши компоненты!». Как только вы что-то внесли в проект в виде зависимости или тулинга, то моментально оно становится вашим, поэтому он должен проходить ровно те же этапы проверок, что и ваш основной код.

Согласно статистике от Synopsis, 96% коммерческого кода использует проекты с открытым исходным кодом, так что от open source уже никуда не деться.

Начинать инвентаризацию нужно с составления Software Bill of Materials всех компонент, которые есть в проекте. SBOM — всему голова! Именно он является отправной точкой для понимания, что же разработчики притащили в продукт, в том числе и через транзитивные зависимости.

Еще одним важным параметром, который часто забывают, является лицензия, под которой распространяется модуль или продукт. Лицензионная «чистота» важна и должна мониториться с самого начала.

Ну и самый частый пункт, на который обращают внимание — это уязвимости, malware, майнеры и другие проблемы, которые можно притащить случайно в проект. Находят их постоянно и в больших количествах. Например, недавняя статья говорит о том, что сотни NPM-пакетов пытаются притащить майнеры или пакеты из PyPI, цель которых украсть креды от AWS. Часто для распространения может применяться социальная инженерия, например, через ответы на StackOverflow. Такую проблему заметили исследователи из Sonatype.

Да и в целом тренд атак на open source только растет: еще в 2020 году Sonatype отмечал рост атак на цепочки поставок на 430%.

Важно понимать, что обязательно выстраивать процесс, который помог бы минимизировать потенциальные проблемы. Для этого не нужно «изобретать велосипед» и начать внедрять общеизвестные практики SSDLC. Эту тему подробно осветил Алексей Федулаев в своем интервью.

Но и в целом стоит опираться на проекты, которые посвящены различным аспектам безопасной разработки.

В частности, таким проектом является OWASP (Open Worldwide Application Security Project), который закрывает собой различный спектр направлений: начиная от составления рейтинга самых распространенных уязвимостей, фреймворка SAMM (Software Assurance Maturity Model) и заканчивая различным тулингом, который позволяет проводить оценку уязвимостей, динамический анализ приложений и т.д.

Отдельно хотелось бы отметить «фреймфорк» SALSA (Supply-chain Levels for Software Artifacts), который предназначен для защиты от supply chain-атак и отображает потенциальные проблемы, которые могут возникнуть в процессе использования стороннего кода.

Если говорить конкретно о России, то я бы отметил «движение» вокруг РБПО (разработка безопасного ПО), цель которого — донести и показать практики в контексте российской регуляторики. Подробно об этом рассказал Дмитрий Пономарев в своем докладе на OFFZONE 2023 «Инженерные аспекты анализа ПО в парадигме ФСТЭК России».

Cyber Media: В коммерческой разработке компании могут использовать весь спектр инструментов для обеспечения ИБ: от опенсорсных решений до коммерческих больших продуктов. А какой инструментарий используется для обеспечения ИБ open source-проектов?

Анатолий Карпенко: Не понимаю, почему должна быть разница при работе с разными типами проектов. Вся разница упирается в сложность самого проекта и его возможности. Есть открытые проекты, которые могут быть проспонсированы и получить тот или иной тулинг, а есть проекты, которые используют то, что доступно для бесплатного использования.

Например, Flipper Zero долгое время использовал (может, и продолжает использовать) PVS-Studio для статического анализа кода прошивки. PVS-Studio это коммерческий продукт, который может использовать условно любой при желании и необходимости.

Или другой пример от Coverity, который позволяет добавить open source проекты для статического анализа кода. Сейчас в списке больше девяти тысяч репозиториев.

Обратным примером является использование открытых проектов для анализа. Например, Trivy для поиска уязвимостей и секретов. Этот продукт доступен всем, и его также может использовать любой.

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

Cyber Media: Все чаще звучит тема альтернативных площадок для работы с открытым кодом. На ваш взгляд, какие условия нужны для создания таких платформ в рамках России?

Анатолий Карпенко: Такие условия невозможно создать не только в России, но и в любой другой стране, потому что крупный open source строится на взаимодействии в рамках всего мира. Примерами таких проектов являются упомянутый ранее Linux, оркестратор контейнеров Kubernetes, язык программирования Rust, офисный пакет LibreOffice… Их тысячи!

Я бы ставил вопрос: «Можно ли создать площадку для каких-то локальных активностей в рамках русскоязычного комьюнити?». Несомненно, это можно сделать, чтобы попробовать упростить взаимодействие между членами сообщества. Но думаю, что в этом нет острой необходимости.

Если взять в качестве примера недавнюю ситуацию с отстранением мейнтейнеров ядра Linux, которые связаны с РФ, то непонятно, что даст создание альтернативной площадки. Создавать форки можно и сейчас, «вливать» изменения из основной ветки разработки придется все равно, какая бы площадка ни была, взаимодействия с «внешним миром» не избежать.

Если забанят работу из России на какой-нибудь популярной платформе, например, GitHub или GitLab, то нужно иметь «запасную» площадку, чтобы держать свои наработки. Этот аргумент полностью валиден, потому что свои наработки, действительно, нужно где-то хранить. Тут уже можно делать выбор, начиная от облачных решений (как российских, так и иностранных) и до того, чтобы развернуть свое хранилище кода. Выбор таких решений достаточно большой.

Но все равно остается два важных пункта. Во-первых, ваш код будет привязан к «внешнем миру» и нужно что-то придумывать, чтобы хотя бы обновлять зависимости. Во-вторых, всегда нужно иметь резервную копию ваших наработок, вне зависимости от того, хостится ваш проект в РФ или вне РФ.

Я считаю, что есть смысл создавать российские платформы, которые являются альтернативами Github или GitLab под определенные ситуации. Во-первых, они нужны для организаций, которым удобней и проще использовать облачные решения. Оплата иностранных сервисов сейчас затруднена. Во-вторых, это важно для компаний, которые попали под санкции, но они хотят делиться своими наработками. Отечественные решения таких платформ появляются, например, GitFlic, Mos.Hub, GitVerse. Из того, что я видел и пробовал, считаю GitFlic наиболее зрелой.

Создание площадки также имеет смысл в рамках каких-то отдельных разработок или исследований. Например, так поступил ИСП РАН в рамках упомянутого мной ранее «Центра исследований безопасности системного программного обеспечения» и развернул собственный инстанс GitLab.

В завершение хотелось бы сказать, что open source живет не в вакууме, а в реальном мире, в котором может происходить разное. Начиная с того, что разработчик может забросить проект, просто обидеться на сообщество, например, как разработчик Азер Кочулу (Azer Koçulu), который удалил более 250 своих модулей для Node.js.

И заканчивая тем, что могут «прилететь» санкции (например, OpenTofu или Linux) или может быть внедрен зловредный код (например, xz). Ко всем этим процессам и событиям нужно быть готовым, нужно понимать, какие внешние зависимости — критические, что происходит в коде зависимостей и как выстроить безопасную разработку в целом.