Language
Country/Area
No result found
Скрытые опасности программного обеспечения с открытым исходным кодом: ваш код уже находится под угрозой?
В современной среде разработки программного обеспечения программное обеспечение с открытым исходным кодом (OSS) стало выбором номер один для многих компаний и разработчиков. Однако знаете ли вы, что использование программного обеспечения с открытым исходным кодом также несет в себе потенциальные риски? Анализ состава программного обеспечения (SCA) — это метод, который помогает разработчикам проверять компоненты с открытым исходным кодом, встроенные в их код, чтобы проверить их актуальность, наличие уязвимостей безопасности и соответствие лицензионным требованиям.
Программное обеспечение с открытым исходным кодом пользуется большой популярностью из-за своей гибкости и низких затрат на разработку, однако связанные с ним риски часто упускаются из виду.
Предыстория риска
Такой подход к разработке программного обеспечения из различных компонентов стал все более распространенным с конца 1990-х годов, с появлением программного обеспечения с открытым исходным кодом. Такой подход позволяет разделить большую кодовую базу на более мелкие части, что повышает гибкость и ускоряет процесс разработки. Однако риски, связанные с программным обеспечением с открытым исходным кодом, явно растут по мере использования большего количества компонентов, и эти риски можно разделить на пять основных категорий:
<ул>Автоматизированный анализ и управление рисками становятся необходимостью для организаций, которые широко используют компоненты с открытым исходным кодом.
Как работает SCA
Продукты SCA обычно работают следующим образом: сначала сканирующий механизм проверяет исходный код программного обеспечения и связанные с ним артефакты, используемые для его компиляции, определяя используемые компоненты с открытым исходным кодом и их версии. Затем эта информация сохраняется в базе данных, формируя каталог используемых компонентов с открытым исходным кодом. Затем этот каталог сравнивается с базой данных известных уязвимостей безопасности, лицензионных требований и исторических версий.
Например, при обнаружении уязвимостей безопасности это сравнение часто проводится с известными уязвимостями безопасности, отслеживаемыми в Национальной базе данных уязвимостей (NVD). Некоторые продукты могут использовать для своих проверок дополнительные фирменные базы данных уязвимостей. Для обеспечения соответствия требованиям интеллектуальной собственности и законодательства продукты SCA извлекают и оценивают типы лицензий, используемых компонентами с открытым исходным кодом. Эти результаты обычно предоставляются пользователям в различных цифровых форматах и включают оценки рисков и рекомендации по юридическим требованиям, основанные на потребностях различных продуктов, в частности требования к лицензиям на сильное или слабое совместное использование.
Результаты могут также включать в себя Манифест компонентов службы (SBOM), в котором подробно описаны компоненты с открытым исходным кодом, используемые в программном приложении, и их свойства.
Использование SCA
Поскольку SCA влияет на различные организационные функции, разные команды используют эти данные, часто в зависимости от размера и структуры организации. ИТ-отделы используют SCA для внедрения и эксплуатации технологий, а основными заинтересованными сторонами являются директор по информационным технологиям (CIO), директор по технологиям (CTO) и главный архитектор предприятия (EA). Данные о безопасности и авторизации часто используются директором по информационной безопасности (CISO) для управления рисками безопасности, в то время как директор по интеллектуальной собственности/соответствию нормативным требованиям фокусируется на рисках в сфере интеллектуальной собственности. В зависимости от возможностей продукта SCA эти инструменты могут использоваться непосредственно в интегрированной среде разработки (IDE) разработчика или использоваться в качестве необходимого шага в процессе контроля качества программного обеспечения.
Преимущества и недостатки SCAВ некоторых странах, например в США, необходимость создания SBOM является обязательной для обеспечения безопасности программного обеспечения, поставляемого поставщиками государственным учреждениям.
Автоматизация — главное преимущество продуктов SCA. Когда разработчики используют и интегрируют компоненты с открытым исходным кодом, нет необходимости выполнять дополнительную ручную работу. Сюда также входит автоматическая обработка косвенных ссылок на другие компоненты с открытым исходным кодом. Однако текущие продукты SCA также имеют некоторые ключевые недостатки, такие как: процесс развертывания сложен и требует много времени, и для его полной эксплуатации могут потребоваться месяцы; каждый продукт использует собственную библиотеку компонентов OSS, размер и охват этих библиотек ограничены; показатели могут существенно различаться; а данные об уязвимостях часто ограничиваются сообщением только о тех уязвимостях, которые были официально зарегистрированы в NVD.
Кроме того, в продуктах SCA часто отсутствуют автоматизированные руководства, неадекватные рекомендации по действиям, которые следует предпринять в отношении данных в отчетах, и мало указаний по юридическим требованиям для обнаруженных лицензий OSS.
На этом фоне вы также думаете о том, как эффективнее управлять потенциальными рисками программного обеспечения с открытым исходным кодом и защищать свой код от угроз?
