Призывы к критическому взгляду на то, как защищено и используется программное обеспечение с открытым исходным кодом (OSS), усилились после того, как ряд недавних инцидентов обнажил уязвимости и риски, в частности инцидент с XZ Utils, который выявил бэкдор, внедренный в широко используемое ПО для сжатия и распаковки файлов XZ.
XZ Utils могла бы стать одним из самых серьезных нарушений в цепочке поставок ПО на сегодняшний день, если бы ее не обнаружили вовремя. Хотя в конечном итоге у нее не было такого широкого потенциала эксплуатации, как у Log4j, это послужило еще одним тревожным сигналом о том, что современная цифровая экосистема невероятно хрупка и нуждается в совершенствовании того, как она использует и защищает OSS.
В ответ на эти и другие инциденты разрабатываются дополнительные ресурсы и рекомендации для специалистов по кибербезопасности, которые помогут усовершенствовать способы управления и безопасного использования OSS, включая 10 основных рисков для программного обеспечения с открытым исходным кодом (OSS) от Open Web Application Security Project (OWASP).
Рейтинг OWASP Top 10 изначально был создан Endor Labs, компанией, занимающейся цепочками поставок программного обеспечения и безопасностью приложений, специализирующейся на безопасном использовании OSS, конвейерах CI/CD и управлении уязвимостями. Проект также включал поддержку со стороны таких лидеров отрасли, как Palo Alto, HashiCorp и Citibank.
Хотя традиционное управление уязвимостями рассматривает известные уязвимости, часто в форме списков общих уязвимостей (CVE), сейчас растет осознание того, что известные уязвимости являются запаздывающими индикаторами риска.
Чтобы усовершенствовать наш подход к использованию открытого исходного кода, необходимо изменить парадигму, взглянув на ведущие индикаторы риска, представляющие собой метрики, сигнализирующие о наличии риска, связанного с конкретными библиотеками, компонентами и проектами OSS, которые при целостном рассмотрении могут помочь обеспечить более безопасное использование OSS и снизить риски, проявляющиеся в эксплойтах и уязвимостях.
1. Известные уязвимости
В этом разделе рассматриваются компоненты OSS с известными уязвимостями, такими как недостатки программного обеспечения, которые (часто непреднамеренно) вводятся разработчиками и специалистами по сопровождению программного обеспечения, и впоследствии обнаруживаются и раскрываются публично исследователями безопасности.
Возможность эксплуатации этих уязвимостей зависит от контекста, в котором они используются внутри организации и приложения. Хотя этот момент может показаться тривиальным, на самом деле это не так — неспособность предоставить разработчикам этот контекст приводит к напрасной трате времени и разочарованию в безопасности.
Предпринимаются усилия по решению этой проблемы, такие как каталог известных эксплуатируемых уязвимостей CISA (KEV) и система оценки прогнозирования эксплойтов (EPSS).
Организации могут предпринимать меры по снижению риска компонентов OSS с известными уязвимостями, например сканирование уязвимостей во всех используемых ими компонентах OSS, приоритизация результатов на основе таких методов, как известные случаи эксплуатации, вероятность эксплуатации, анализ достижимости (что может снизить долю ложных срабатываний до 80% ) и многое другое.
2. Компрометация легитимного пакета ПО
Следующим в списке 10 крупнейших рисков OSS является компрометация легитимного пакета ПО. Злоумышленники осознают ценность компрометации легитимного пакета ПО для воздействия на потребителей данного ПО.
Существует множество методов, которые они могут использовать для реализации этого вектора атаки, например, захват учетных записей сотрудников, сопровождающих проект, или использование уязвимостей в репозиториях пакетов ПО.
Они также могут добровольно стать сопровождающими только для того, чтобы в дальнейшем реализовать свои гнусные намерения. Именно это произошло в недавнем инциденте с XZ Utils, когда кто-то долгое время выдавал себя за законного участника проекта, прежде чем внедрить бэкдор.
Рекомендации по снижению этого риска включают использование новых ресурсов и руководств, таких как Microsoft Secure Supply Chain Consumption Framework (S2C2F)(Фреймворк безопасного потребления в цепочке поставок, теперь переданная в дар OpenSSF) , но сейчас в отрасли существует еще несколько подобных фреймворков.
3. Атаки, связанные с путаницей имен
При атаках с путаницей имен (name-confusion attacks) злоумышленники создают вредоносные компоненты, имена которых напоминают легальные пакеты или компоненты OSS, в надежде, что они будут случайно загружены и использованы потенциальными жертвами. Такие атаки, которые также представлены в каталоге CNCF Software Supply Chain Attack, включают в себя тайпсквоттинг и кражу бренда. Когда эти скомпрометированные пакеты попадают в ИТ-среду организации, они могут повлиять на конфиденциальность, целостность и доступность систем и данных.
4. Неподдерживаемое программное обеспечение
Одна из суровых реалий OSS, в отличие от коммерческого ПО, заключается в том, что у него нет поставщика. Разработчики OSS предоставляют программное обеспечение «как есть». Это означает, что нет никаких гарантий того, что ПО будет обновляться или поддерживаться.
Такие отчеты, как отчет Synopsys об OSS, показывают, что 85% оцененных кодовых баз содержат компоненты OSS, которые устарели более чем на четыре года и которые не получали новых обновлений в течение двух лет.
Учитывая, что программное обеспечение быстро устаревает, а новые уязвимости появляются рекордными темпами, это не сулит ничего хорошего для безопасности и гигиены современных приложений, использующих компоненты OSS, которые не обновляются.
OSS в основном поддерживается волонтерами бесплатно. Компоненты ПО могут активно не дорабатываться и не поддерживаться, а исправления недостатков могут либо вообще не происходить, либо не соответствовать требуемым срокам, а также соглашению об уровне сервиса с поставщиком проприетарного ПО в отношении устранения уязвимостей.
Еще одним ключевым фактором, способствующим отсутствию поддержки открытого ПО, является тот факт, что почти 25% проектов OSS имеют только одного разработчика, а 94% проектов поддерживаются 10 или меньшим количеством разработчиков, как цитирует исследователь Чинмайи Шарма в своей публикации «Трагедия цифрового сообщества» (A Tragedy of the Digital Commons), которую рекомендуется прочитать тем, кто хочет получить полное представление об этих проблемах.
Это также часто называют «фактором автобуса», когда задается вопрос: «Каковы будут последствия, если такого-то собьет автобус?» Если у проекта один сопровождающий, риск очевиден. Учитывая, что 60-80% современных кодовых баз состоят из OSS, приходит осознание того, что значительная часть нашей цифровой экосистемы, даже наши самые важные системы, работают на ПО, которое поддерживается и обслуживается в минимальном объеме, что представляет собой значительный системный риск.
Рекомендации по борьбе с этим риском, приведенные в отчете, включают проверку работоспособности проекта, например количества сопровождающих и участников, частоты выпусков обновлений и количества уязвимостей со средним временем устранения.
5. Устаревшее программное обеспечение
В этом случае проект использует устаревшую версию компонента, несмотря на то, что могут существовать более новая версия и обновление. Как отмечается в отчете Synopsys, такая ситуация на самом деле является нормой и встречается в подавляющем большинстве кодовых баз и репозиториев.
Это осложняется сложным набором зависимостей, которыми обладают многие современные приложения и проекты. Эта проблема подчеркивается в отчетах таких групп, как Sonatype и Endor Labs, последняя из которых опубликовала отчет «Состояние управления зависимостями», в котором показано, что 95% уязвимостей связаны с транзитивными зависимостями.
6. Неотслеживаемые зависимости
Это ситуация, когда разработчики/организации вообще не знают об использовании ими конкретной зависимости или компонента. Это может произойти из-за того, что организация не использует такие инструменты, как анализ состава программного обеспечения (SCA) или спецификации программного обеспечения (SBOM), которые обеспечивают видимость компонентов ПО, используемых организацией.
Это служит фактором для более широкого продвижения SBOM и парадигмы безопасности цепочки поставок ПО, поскольку благодаря таким инцидентам, как SolarWinds и Log4j, отрасль осознала, что большинству организаций не хватает полной инвентаризации активов ПО вплоть до уровня компонентов/библиотек, несмотря на то, что инвентаризация активов ПО является критическим контролем SANS/ CIS на протяжении многих лет. SBOM стремятся решить эту проблему, позволяя организациям начать управлять своими запасами компонентов ПО.
7. Лицензионный и регуляторный риск
Этот риск представляет собой ситуацию, когда компоненты или проекты могут не иметь лицензии или иметь лицензию, препятствующую их предполагаемому использованию потребителями.
OWASP заявляет, что организации должны гарантировать, что использование компонентов OSS соответствует применимым условиям лицензирования этих компонентов. Невыполнение этого требования может повлечь нарушение авторских прав и судебные иски.
Это может повлиять на достижение бизнес целей организации, деятельность по слияниям и поглощениям и многое другое, поскольку организации шире используют компоненты OSS в своих собственных продуктах, услугах и предложениях.
Организации могут принять меры по снижению этих рисков, определив применимое лицензирование компонентов ПО, которые они используют в своем собственном программном обеспечении, и предполагаемое использование этих компонентов. В отчете также рекомендуется организациям полностью избегать использования компонентов, не имеющих лицензии, а также определять, когда к компонентам применяются несколько лицензий или конфликтующие лицензии.
8. Незрелое программное обеспечение
Не все ПО создается одинаково высоком уровне. Конечно существуют разные уровни зрелости ПО, отчасти из-за разного уровня вовлеченности сопровождающих.
В некоторых проектах OSS могут не применяться методы безопасной разработки ПО (например, те, которые указаны в NIST Secure Software Development Framework (SSDF)). Конкретные примеры могут включать отсутствие документации, отсутствие регрессионного тестирования, отсутствие руководств по проверке и многие другие передовые практики.
Существует также неприятная реальность: многие разработчики не заинтересованы в безопасности. Это подтверждается исследованиями, например, проведенными Linux Foundation и Лабораторией инновационных наук Гарвардского университета (LISH), которые обнаружили, что разработчики бесплатного ПО с открытым исходным кодом тратят только 2,3% своего времени на повышение безопасности своего кода.
В настоящее время имеются доступные отраслевые инициативы и инструменты, такие как Scorecard OpenSSF, обеспечивающие надежный набор проверок для проектов OSS в Github, таких как наличие защиты ветвей, количество участников/организаций, CI-тесты, фаззинг, обслуживание, лицензирование и т.п. Еще одна подобная инициатива включает CISA и OpenSSF, получившее название «Принципы безопасности репозитория пакетов».
9. Несанкционированное изменение (изменчивость)
OWASP определяет изменчивость ПО как ситуации, в которых его компоненты могут изменяться без уведомления, проверки или одобрения разработчиком изменений. Это может произойти в ситуациях, когда ссылки для загрузки ПО изменяются или указывают на неверсионные ресурсы или даже на небезопасную передачу данных, которые были подделаны, что подчеркивает роль безопасного транзита.
Рекомендуемые меры по снижению данного риска включают использование идентификаторов ресурсов для обеспечения уверенности и указания на один и тот же неизменяемый артефакт. Вы также можете проверить подписи и дайджесты компонентов ПО перед их фактической установкой и использованием. Кроме того, чтобы снизить риск компрометации компонентов ПО при передаче, организациям следует использовать защищенные сетевые протоколы.
10. Зависимость меньшего/чрезмерного размера
Наконец, существуют ситуации, в которых используемые компоненты ПО могут обеспечивать очень узкую или очень широкую функциональность, из которой фактически используется только небольшая часть. Это часто называют «раздуванием программного обеспечения».
В примере с зависимостями меньшего размера из-за ограниченного количества строк кода безопасность компонента ПО становится зависимой от вышестоящих проектов. С другой стороны, если у вас раздутый код, то вы в конечном итоге увеличиваете поверхность атаки и потенциально пригодный для эксплуатации код/зависимости, хотя на самом деле они вам не нужны.
В отчете рекомендуется в таких случаях дойти до внутренней переработки функциональности, чтобы снизить риск недостаточного или чрезмерного размера зависимостей. Мы также наблюдаем стремление в облачных контейнерных средах извлечь выгоду из «безопасных базовых образов», пропагандируемых такими лидерами, как Chainguard, которые представляют собой минимальные защищенные базовые образы с ограниченным количеством уязвимостей или вообще без них.