10 основных рисков безопасности и операционных рисков с открытым исходным кодом в 2023 году
12 марта 2023 г.Endor Labs, компания-разработчик программного обеспечения, которая обеспечивает безопасность и обслуживание программного обеспечения с открытым исходным кодом, выпустила отчет, в котором указаны 10 основных рисков безопасности и операционных рисков в программном обеспечении с открытым исходным кодом в 2023 году.
В отчете, подготовленном командой Endor Labs’ Station 9, приняли участие более 20 главных специалистов по информационной безопасности известных компаний, включая Adobe, HashiCorp, Discord и Palo Alto Networks.
По данным Endor Labs, чрезмерная зависимость от программного обеспечения с открытым исходным кодом зафиксировала некоторые известные уязвимости, отмеченные как общие уязвимости и риски; эти уязвимости часто упускаются из виду и могут быть использованы злоумышленниками, если не будут устранены.
«Программное обеспечение с открытым исходным кодом представляет собой золотую жилу для разработчиков приложений, но оно нуждается в не менее эффективных средствах обеспечения безопасности», — сказал Хенрик Плейт, ведущий исследователь безопасности в Endor Labs. «В среде, где более 80% кода в новых приложениях может поступать из существующих репозиториев, очевидно, что существуют серьезные риски».
Основные риски открытого исходного кода в 2023 году
Ниже выделены основные выводы отчета Endor Labs о 10 основных рисках с открытым исходным кодом в 2023 году.
1. Известные уязвимости
Отчет показал, что версия компонента с открытым исходным кодом может содержать уязвимый код, случайно добавленный его разработчиками. Уязвимость может быть использована в нижестоящем программном обеспечении, что может поставить под угрозу конфиденциальность, целостность или доступность системы и ее данных.
2. Компрометация легитимного пакета
Согласно отчету Endor, злоумышленники могут нацеливаться на законные ресурсы из существующего проекта или инфраструктуры распространения, чтобы внедрить вредоносный код в компонент. Например, они могут захватить учетные записи законных сопровождающих проектов или использовать уязвимости в репозиториях пакетов. Этот тип атаки может быть опасен, поскольку вредоносный код может распространяться как часть законного пакета и его трудно обнаружить.
3. Атаки путаницы в именах
Злоумышленники могут создавать компоненты с именами, похожими на имена законных компонентов с открытым исходным кодом или системных компонентов. Отчет Endor Labs показал, что это можно сделать с помощью:
- Опечатка: Злоумышленник создает имя, которое является орфографической ошибкой имени исходного компонента.
Брандджекинг: Злоумышленник предлагает надежного автора.
Комбинированное приседание: злоумышленник играет с общими шаблонами именования в разных языках или экосистемах.
Эти атаки могут использоваться для того, чтобы заставить пользователей загружать и использовать вредоносные компоненты, которые они считают законными.
4. Необслуживаемое программное обеспечение
Согласно отчету Endor Labs, необслуживаемое программное обеспечение является эксплуатационной проблемой. Компонент или версия компонента больше не может активно разрабатываться, что означает, что исправления для функциональных и нефункциональных ошибок могут предоставляться не сразу или вообще не предоставляться первоначальным проектом с открытым исходным кодом. Это может сделать программное обеспечение уязвимым для использования злоумышленниками, нацеленными на известные уязвимости.
5. Устаревшее программное обеспечение
Для удобства некоторые разработчики используют устаревшую версию базы кода при наличии обновленных версий. Это может привести к тому, что проект упустит важные исправления ошибок и исправления безопасности, что сделает его уязвимым для эксплуатации.
6. Неотслеживаемые зависимости
Разработчики проекта могут не знать о зависимости от компонента по нескольким причинам:
- Он не является частью спецификации программного обеспечения вышестоящего компонента.
Средства анализа состава программного обеспечения не запускаются или не обнаруживают его.
Зависимость устанавливается не с помощью менеджера пакетов, что может привести к проблемам с безопасностью, поскольку уязвимости в неотслеживаемой зависимости могут остаться незамеченными.
7. Лицензионный и регуляторный риск
Компонент или проект может не иметь лицензии или иметь лицензию, несовместимую с предполагаемым использованием, или требования которой не могут быть или не могут быть выполнены.
Использование компонентов в соответствии с их лицензионными условиями имеет решающее значение. Невыполнение этого требования, например использование компонента без лицензии или несоблюдение его условий, может привести к нарушению авторских прав или лицензии. В таких случаях правообладатель имеет право обратиться в суд.
Кроме того, нарушение законодательных и нормативных требований может ограничить или затруднить работу с определенными отраслями или рынками.
8. Незрелое программное обеспечение
Проект с открытым исходным кодом может не следовать передовым методам разработки, таким как использование стандартной схемы управления версиями, наличие набора регрессионных тестов или наличие руководств или документации по обзору. Это может привести к тому, что компонент с открытым исходным кодом не будет работать надежно или безопасно, что сделает его уязвимым для эксплуатации.
Использование незрелого компонента или проекта может привести к значительным операционным рискам. Например, программное обеспечение, которое зависит от него, может работать не так, как предполагалось, что приводит к проблемам с надежностью во время выполнения.
9. Неутвержденные изменения (изменяемые)
При использовании компонентов, идентичность которых при загрузке в разное время не гарантируется, существует значительный риск безопасности. Об этом свидетельствуют такие атаки, как Codecov Bash Uploader, когда загруженные скрипты передаются напрямую в bash без предварительной проверки их целостности. Использование изменяемых компонентов также представляет угрозу для стабильности и воспроизводимости сборок программного обеспечения.
10. Зависимость от недостаточного или чрезмерного размера
В отчете Endor указывалось, что чрезмерная/недостаточная зависимость от компонентов может быть операционным риском. Например, небольшие компоненты, содержащие всего несколько строк кода, подвержены тем же рискам, что и более крупные компоненты. Эти риски включают поглощение учетных записей, вредоносные запросы на вытягивание, а также уязвимости конвейера непрерывной интеграции и непрерывной разработки.
С другой стороны, огромные компоненты могут иметь множество функций, которые не нужны для стандартных вариантов использования. Эти функции увеличивают поверхность атаки компонента и могут привести к неиспользуемым зависимостям, что приведет к их раздуванию.
Шаги, которые необходимо предпринять для снижения этих рисков с открытым исходным кодом
Вот советы от Endor Labs о том, как разработчики программного обеспечения и ИТ-менеджеры могут снизить эти риски, связанные с открытым исходным кодом.
Регулярно сканируйте код для обнаружения скомпрометированных пакетов
Предотвращение скомпрометированных пакетов — сложная проблема, поскольку не существует универсального решения. Чтобы решить эту проблему, организации могут обратиться к новым стандартам и платформам, таким как OpenSSF Secure Supply Chain Consumption Framework (S2C2F).
Они могут выбирать и расставлять приоритеты мер безопасности, которые лучше всего соответствуют их требованиям, исходя из их конкретных потребностей в безопасности и устойчивости к риску.
Проверьте, соответствует ли проект лучшим практикам разработки
Чтобы оценить качество и актуальность проекта, проверьте его документацию и примечания к выпуску на предмет полноты и своевременности. Ищите значки, указывающие на покрытие тестами или наличие конвейеров CI/CD, которые могут обнаруживать регрессии.
Кроме того, вы можете оценить проект, проверив количество активных сопровождающих и участников, частоту выпуска новых выпусков, а также количество открытых и закрытых проблем и запросов на вытягивание. Также крайне важно искать информацию о стратегии обслуживания или поддержки проекта — например, наличие и даты долгосрочных версий поддержки.
Поддерживайте актуальность зависимостей и проверяйте характеристики кода перед их использованием.
Для обеспечения безопасности кода важна проверка как самого кода, так и характеристик проекта. Примеры характеристик кода, которые необходимо проверить, включают перехватчики до и после установки и закодированные полезные данные. Для характеристик проекта учитывайте репозиторий исходного кода, учетные записи сопровождающих, частоту выпуска и количество последующих пользователей.
Один из способов поддерживать актуальность зависимостей — использовать инструменты, которые генерируют запросы на слияние или вытягивание с предложениями по обновлению. Также важно сделать обновления зависимостей и повторяющиеся элементы невыполненной работы приоритетными.
Оцените и сравните инструменты анализа состава программного обеспечения
Команды безопасности должны убедиться, что инструменты SCA способны создавать точные спецификации как на грубом уровне, например, для зависимостей, объявленных с помощью инструментов управления пакетами, таких как Maven или npm, так и на мелкозернистом уровне, например, для артефактов. как отдельные файлы, включенные «вне диапазона» без использования менеджеров пакетов.
Используйте компоненты в соответствии с условиями лицензии с открытым исходным кодом
ИТ-руководители должны следить за тем, чтобы их разработчики программного обеспечения не использовали компоненты с открытым исходным кодом без лицензии, так как это может создать юридические риски. Чтобы обеспечить соответствие и избежать потенциальных юридических проблем, важно определить приемлемые лицензии для компонентов, используемых при разработке программного обеспечения.
Факторы, которые следует учитывать, включают в себя то, как компонент связан, модель развертывания и предполагаемую схему распространения. После того, как вы определили приемлемые лицензии, соблюдайте требования, изложенные в этих лицензиях с открытым исходным кодом.
Читать далее: Основные угрозы кибербезопасности на 2023 год (TechRepublic)
Оригинал