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

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

Исследование, проведенное 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, так это оказать давление на поставщиков и пользователей, чтобы они обратили внимание на риски безопасности и управление в компонентах с открытым исходным кодом», - сказал он.

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

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

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

По материалам: Technewsworld