Отчет: большинство коммерческих приложений содержат уязвимости безопасности в коде

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

Исследование, проведенное Osterman Research для GrammaTech, также показало, что из самых популярных коммерческих браузеров, продуктов для электронной почты, обмена файлами, онлайн-встреч и обмена сообщениями 85% содержали по крайней мере одну критическую уязвимость.

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

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

Онлайн-встречи и почтовые клиенты, которые содержат самый высокий процент уязвимостей, были наиболее уязвимыми категориями, изучаемыми исследователями.

"Многие из приложений для онлайн-встреч были быстро вытеснены из-за пандемии. Вот почему в таких приложениях больше компонентов с открытым исходным кодом и больше уязвимостей", - пояснил Кристиан Симко, директор по маркетингу продуктов GrammaTech, компании по тестированию безопасности приложений со штаб-квартирой в Бетесде, штат Мэриленд.

Он добавил, что приложения для электронной почты и мессенджеры могут содержать множество уязвимостей, так как они зависят от Open SSL, протокола связи с открытым исходным кодом.

"Открытый SSL очень распространен, и это чрезвычайно уязвим ый компонент с открытым исходным кодом", - говорит эксперт.

По словам Остермана, на Open SSL приходится 9,6% уязвимостей с открытым исходным кодом, обнаруженных во всех приложениях.

Необходим лучший мониторинг

Сариу Найяр, генеральный директор Gurucul, компании по анализу угроз из Эль-Сегундо, Калифорния, утверждает, что программное обеспечение с открытым исходным кодом так же безопасно или даже более безопасно, чем большинство коммерческих программ.

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

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

"Организации будут тщательно проверять свой собственный код, но не так строго как с открытым исходным кодом и ли коммерческим кодом", - добавил директор по маркетингу GrammaTech Энди Мейер.

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

"Тот факт, что они используют эти компоненты без их тестирования, говорит о проблеме скорости и необходимости ускорения циклов выпуска", - сказал эксперт в интервью.

Открытый исходный код не дает гарантии

Риск, который компоненты с открытым исходным кодом представляют для приложений, связан не столько с самим компонентом, сколько с цепочкой поставок, которая его поддерживает, утверждает Цви Коррен, технический директор Aqua Security, компании по обеспечению безопасности контейнеров, базирующейся в Рамат-Гане, Израиль.

"Все сводится к степени управления и надзора, которых часто не хватает проектам с открытым исходным кодом", - говорит он.

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

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

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

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

"Многие организации будут укомплекто вы вать свои собственные внутренние группы, чтобы сосредоточиться на устранении проблем безопасности, о которых сообщалось в их компонентах с открытым исходным кодом", - добавил Кевин Данн, президент Pathlock, поставщика унифицированного доступа во Флемингтоне, штат Нью-Джерси.

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

Спецификация программного обеспечения

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

"Решение проблемы начинается с видимости", - заметил Дэн Нурми, технический директор Anchore, компании по обеспечению безопасности контейнеров в Санта-Барбаре, Калифорния.

Один из способов защиты - использовать ведомость материалов по программному обеспечению (SBOM), в которой перечислены все компоненты и зависимости в приложении.

"Спецификация программного обеспечения может помочь в обеспечении прозрачности и видимости всего ландшафта сторонних и четвертых сторон, а также может помочь лучше понять, что связано с использованием конкретного инструмента", - говорит Деми Бен-Ари, соучредитель и технический директор Panorays, Tel Авив, Израиль, который автоматизирует, ускоряет и масштабирует сторонние процессы безопасности.

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

Нурми объяснил, что создание ведомостей материалов для программного обеспечения - обычная практика в отрасли, но она не получила официального оформления.

"Существует не так много указаний о том, какие виды информации имеют отношение к обмену информацией между организациями", - сказал он.

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

"Прозрачность лучше, чем сокрытие этих компонентов, но их раскрытие не снижает риска в программном обеспечении", - заметил он.

"Что может сделать BOM, так это оказать давление на поставщиков и пользователей, чтобы они обратили внимание на риски безопасности и управление в компонентах с открытым исходным кодом", - сказал он.

"Пользователям программного обеспечения будет легче найти уязвимости в этих компонентах и ​​работать над их устранением", - пояснил он.

"Раскрытие также укажет, идет ли поставщик в ногу с выпусками компонентов с открытым исходным кодом", - продолжил он.

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