Пренебрежение разработчиками открытого исходного кода ставит Интернет под угрозу

Программное обеспечение лежит в основе всех современных предприятий и имеет решающее значение во всех аспектах операций. Почти каждый бизнес будет использовать программное обеспечение с открытым исходным кодом, сознательно или нет, поскольку даже проприетарное программное обеспечение зависит от библиотек с открытым исходным кодом. OpenUK Отчет «Состояние открытости» за 2022 год показал, что 89% предприятий полагались на программное обеспечение с открытым исходным кодом, но не все из них ясно представляют детали программного обеспечения, на которое они полагаются.

Предприятиям все чаще требуется дополнительная информация о критически важном для их работы программном обеспечении. Ответственные предприятия внимательно изучают свою цепочку поставок программного обеспечения и составляют спецификацию программного обеспечения (SBOM) для каждого приложения. Этот уровень информации имеет решающее значение, так как при обнаружении недостатков безопасности в их программном обеспечении они могут сразу же определить, какое программное обеспечение и версии используются, а какие системы затронуты. Знание - сила в таких ситуациях!

Опора на волонтеров

В конце 2021 года уязвимость безопасности под названием Журнал4Shell был идентифицирован в широко используемой среде ведения журналов Java, Log4j. Поскольку это широко используемая библиотека с открытым исходным кодом, уязвимость получила широкую огласку, и ожидалось ее исправление. Тем не менее сопровождающими проекта были волонтеры. У них была дневная работа, и они не требовали срочных исправлений безопасности, даже если было затронуто большое количество систем. По оценкам, одна только эта уязвимость затронула 93% корпоративных облачных сред.

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

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

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

Знайте зависимости для оценки риска

Знание зависимостей облегчает оценку риска, связанного с каждой из них. Эти проекты с открытым исходным кодом проще всего оценить: есть ли ответы на вопросы и были ли в последнее время какие-либо релизы? Возможность видеть сопровождающих и проектную деятельность для каждого проекта дает хорошее представление о состоянии проекта.

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

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

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

Другой подход заключается в поддержке организаций, которые существуют для поддержки открытого исходного кода. OpenSSF (Фонд безопасности с открытым исходным кодом) работает над повышением безопасности проектов с открытым исходным кодом и финансируется организациями, которые зависят от этих проектов. Он также публикует отличные учебные ресурсы, чтобы предприятия могли узнать о рисках программного обеспечения, которое они используют. Еще одна похожая организация Tidelift, которая сотрудничает с сопровождающими для обеспечения выполнения определенных основных требований, опять же финансируемая организациями. Tidelift также предоставляет инструменты и обучение, чтобы помочь предприятиям управлять своей цепочкой поставок программного обеспечения и внедрять лучшие практики в этой области.

Обеспечение более безопасного программного обеспечения в будущем

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

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