Открытый код: риски и перспективы

Один из актуальных вопросов в российской повестке по импортозамещению – предложение правительства о создании национального репозитория открытого кода. 12 октября 2022 г. Минцифры приняло постановление, в котором обозначен срок проведения эксперимента (с 1 ноября 2022 г. до 30 апреля 2024 г.) и векторы развития новой платформы.

Риски при использовании продуктов open source

Основная проблема платформ, предоставляющих продукты открытого ПО (open source), заключается в том, что это крайне "анархичная" среда, где все строится на доверии и оценках сообщества. Такие проекты, как The Apache Software Foundation, оправдывают доверие специалистов, потому что демонстрируют достаточно серьезный процесс проверки кода и в размещении вредоносных ПО пока не были замечены. Но также существует огромное количество популярных проектов от энтузиастов, которые как раз и несут в себе актуальные риски, связанные с распространением лозунгов, вредоносов, закладок. Например, в феврале 2022 г. появились целые списки ПО, которые намеренно устраивали саботаж.

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

Иностранные источники

Для мирового комьюнити разработчиков основная платформа для публикации кода в открытый доступ – это GitHub. Многие также используют ее возможности для хранения своего кода, но недоступного публично (приватные репозитории). На GitHub происходит постоянный обмен самыми удачными, удобными и новейшими компонентами от программистов со всего мира. И в этом ее огромное преимущество: чем больше разработчиков собрано на одной платформе, тем больше качественных продуктов там можно найти.

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

1. Потеря доступа к открытому исходному коду, расположенному на зарубежных площадках;
2. Невозможность обновить уязвимые пакеты в случае потери доступа к зарубежным источникам;
3. Потеря доступа к собственным приватным проектам на зарубежных площадках (это распространенная практика хранения кода в небольших компаниях);
4. Скрытое внесение изменений в приватные проекты (владельцами платформы).

С каждым днем мы отмечаем рост риска отключения от различных иностранных источников, и легко представить, например, такой мрачный сценарий, при котором будет существенное сокращение или полная остановка трансграничной передачи данных, что, по сути, приведет к смерти интернета и рождению изолированных сетей по географическому признаку. При этом описанные события могут произойти в течение одной недели, и тогда все технологические компании в России останутся в сегменте сети, где доступны только ресурсы, находящиеся на территории нашей страны. Таким образом, нам мгновенно станут недоступны GitHub, GitLab, Stack Overflow, Server Fault и другие ресурсы, которыми разработчики пользуются каждый день. Вероятно, это и был один из тех сценариев, в ответ на который возникло решение правительства о запуске проекта по созданию национального репозитория открытого кода.

Российский репозиторий

Вопрос, который волнует российское сообщество разработчиков – сможет ли национальный репозиторий стать безопасным аналогом популярных иностранных ресурсов? На данном этапе мы можем только надеяться, что, как минимум, для российских ИТ-специалистов отечественная площадка будет часто используемым источником.

В инициативе правительства можно увидеть хорошую возможность создания платформы для обмена ПО, которое уже прошло испытание внутри крупных российских компаний. Представьте, что какое-то высокотехнологичное предприятие разработало электронный журнал для своих постов охраны. Данные собираются и обрабатываются электронно, есть аналитика, и хорошо контролируется доступ. Пригодилась бы такая разработка другим охраняемым предприятиям? Кому-то да, кому-то частично, а кто-то захочет этот журнал обогатить дополнительными фичами для дальнейшего внедрения в свои системы. Но очевидно, что такая разработка вряд ли покинет стены своего предприятия и появится на каком-то независимом международном ресурсе, например, GitHub.

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

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

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

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

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

Вопрос безопасности публикуемых библиотек и продуктов open source будет всегда актуален. Создать абсолютно защищенную площадку не получится – это связано с природой и сложностью обнаружения уязвимостей. В теории можно было бы покрыть автоматизированными проверками все загружаемое на площадку ПО, но по многим причинам это не сделает платформу безопаснее или популярнее. Дело в том, что средства автоматизированных проверок на данный момент все еще не самостоятельны и требуют со стороны платформы участия специалиста ИБ. В то же время отдавать экспертизу на сторону разработчиков open source не стоит, потому что при желании любой запрет можно замаскировать и обойти, а если слишком закрутить гайки и усложнить требования, то платформой будет невозможно пользоваться. Поэтому для того количества обновлений и тысяч разработок, которые постоянно публикуются на том же самом GitHub, обеспечить автоматизированные проверки экспертами – задача утопичная.

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