Согласно новому опубликованному исследованию, ряд популярных коммерческих приложений в различных категориях, от браузеров до приложений для обмена сообщениями и встреч, содержали компоненты с открытым исходным кодом с уязвимостями безопасности. Среда.
Исследование, проведенное Osterman Research для GrammaTech, также показало, что из самых популярных коммерческих браузеров, продуктов для электронной почты, обмена файлами, онлайн-встреч и обмена сообщениями 85 процентов содержали по крайней мере одну критическую уязвимость.
«Коммерческие готовые программные приложения часто включают компоненты с открытым исходным кодом, многие из которых содержат ряд известных уязвимостей, которые могут быть использованы вредоносными программами, но производители часто не раскрывают их присутствие», — старший аналитик Остермана Майкл Сэмпсон говорится в заявлении.
«Отсутствие прозрачности развернутых и подлежащих развертыванию приложений — это, по сути, бомба замедленного действия, которая увеличивает риск безопасности предприятия, поверхность атаки и возможность взлома со стороны киберпреступников», — добавил он.
Онлайн-встречи и почтовые клиенты, которые содержали самый высокий средний вес уязвимостей, были наиболее уязвимыми категориями, изученными исследователями.
«Многие заявки на онлайн-встречи были быстро закрыты из-за пандемии. Вот почему приложения для онлайн-встреч имеют больше компонентов с открытым исходным кодом и больше уязвимостей », — пояснил Кристиан Симко, директор по маркетингу продуктов GrammaTech, компании по тестированию безопасности приложений со штаб-квартирой в Бетесде, штат Мэриленд
Он добавил, что приложения для электронной почты и обмена сообщениями могут содержать множество недостатков, поскольку они зависят от Open SSL, протокола связи с открытым исходным кодом.
«Открытый SSL очень распространен, и это очень уязвимый компонент с открытым исходным кодом», — сказал он TechNewsWorld.
По словам Остермана, на Open SSL приходится 9,6 процента уязвимостей с открытым исходным кодом, обнаруженных во всех приложениях.
Содержание статьи
Необходим лучший мониторинг
Сарью Найяр, генеральный директор Gurucul, компании по разведке угроз в Эль-Сегундо, Калифорния, утверждал, что программное обеспечение с открытым исходным кодом является таким же безопасным или даже более безопасным, чем большинство коммерческих программ.
«Краудсорсинговый подход к программному обеспечению обычно позволяет быстро выявлять и устранять уязвимости», — сказала она TechNewsWorld.
«Однако организации, использующие библиотеки с открытым исходным кодом или другое программное обеспечение, обязаны отслеживать использование открытого исходного кода в своем программном обеспечении, а также исправлять или иным образом заменять программное обеспечение с открытым исходным кодом, которое имеет уязвимости», — сказала она.
«Многие организации, откровенно говоря, не утруждают себя ведением подробного списка использования ими открытого исходного кода и не следят за досками сообщений для своих библиотек с открытым исходным кодом», она продолжила. «Это делает их уязвимыми для атак на известные эксплойты из-за версии, которую они используют».
«Организации будут тщательно проверять свой собственный код, но не так строго с открытым исходным кодом и коммерческим кодом», — добавил директор по маркетингу GrammaTech. Энди Мейер.
Он объяснил, что производители коммерческого программного обеспечения используют компоненты с открытым исходным кодом и сторонних производителей, чтобы соблюсти временные и финансовые ограничения, которым они могут соответствовать.
«Тот факт, что они используют эти компоненты без их тестирования, говорит о проблеме скорости и необходимости ускорения циклов выпуска», — сказал он TechNewsWorld. «Они вынуждены сделать это».
Все с открытым исходным кодом не равны
Риск, который компоненты с открытым исходным кодом представляют для приложений, связан не столько с самим компонентом, сколько с цепочкой поставок это поддерживает его, утверждает Цви Коррен, старший директор по техническим услугам Aqua Security, компании по обеспечению безопасности контейнеров, базирующейся в Рамат-Гане, Израиль.
«Все сводится к степени управления и надзора, которых часто не хватает проектам с открытым исходным кодом», — сказал он TechNewsWorld.
«Нам нужно различать проекты, которые спонсируются и поддерживаются организациями — компаниями-разработчиками программного обеспечения или некоммерческими организациями — и теми, которые были начаты и все еще поддерживаются отдельными лицами или неорганизованными группами», — продолжил он.
«Последняя категория представляет наибольший риск для приложений, потому что эти проекты не могут инвестировать в тестирование безопасности, не предоставляют соглашения об уровне обслуживания для исправлений, и они потенциально могут быть целью для злоумышленников, которые пытаются« внести свой вклад »злонамеренно. кода и сделать его частью проекта », — сказал он.
Поскольку организации не могут контролировать изменения, вносимые в компоненты с открытым исходным кодом, им необходимо знать, когда в них вносятся изменения, — посоветовал Шон Смит, директор по инфраструктуре nVisium, приложения на базе Herndon, штат Вирджиния. провайдер безопасности.
«Использование зависимостей с открытым исходным кодом совершенно нормально, если вы должным образом проверяете источник на наличие проблем, в дополнение к постоянному аудиту каждый раз, когда вы обновляете эту зависимость на своей платформе», — сказал он TechNewsWorld.
«Многие организации будут укомплектовать свои собственные внутренние группы, чтобы сосредоточиться на устранении проблем безопасности, о которых сообщалось в их компонентах с открытым исходным кодом», — добавил Кевин Данн, президент Pathlock, поставщика оркестровки единого доступа во Флемингтоне, штат Нью-Джерси
«Преимущество компонентов с открытым исходным кодом состоит в том, что команды могут создавать свои собственные патчи для исправления проблем, которые их беспокоят, но за это приходится платить», — сказал он TechNewsWorld.
Спецификация программного обеспечения
Ключом к снижению риска использования компонентов с открытым исходным кодом в программном обеспечении является повышение прозрачности процесса проверки.
«Решение проблемы начинается с видимости», — заметил Дэн Нурми, технический директор Anchore, компании по обеспечению безопасности контейнеров в Санта-Барбаре, Калифорния.
«Организации должны понимать полную картину открытого исходного кода», — сказал он TechNewsWorld.
Один из способов получить эту картину — использовать ведомость материалов программного обеспечения (SBOM), в которой перечислены все компоненты и зависимости в приложении.
«Спецификация программного обеспечения может помочь в обеспечении прозрачности и прозрачности всего ландшафта сторонних и четвертых производителей, а также может помочь вам лучше понять, что связано с использованием определенного инструмента», — Деми Бен-Ари, соучредитель и технический директор компании Pananorays. , из Тель-Авива, Израиль, которая автоматизирует, ускоряет и масштабирует сторонние процессы безопасности, сообщил TechNewsWorld.
«Наличие списка компонентов всегда помогает организациям и их командам отслеживать опубликованные и вновь обнаруженные уязвимости», — добавил Пурандар Дас, генеральный директор и соучредитель Sotero, компании по защите данных в Берлингтоне, штат Массачусетс.
«Это также упрощает определение исправлений, которые необходимо применить», — сказал он TechNewsWorld.
Нурми объяснил, что создание спецификаций программного обеспечения — обычная практика в отрасли, но она не была формализована ».
« Нет » — много указаний о том, какая информация важна, когда речь идет об обмене информацией между организациями », — сказал он.
Коррен отметил, что в хорошей спецификации программного обеспечения должны быть указаны точные компоненты, используемые в программном обеспечении.
«Прозрачность лучше, чем сокрытие этих компонентов, но их раскрытие не снижает риска в программном обеспечении», — заметил он.
«Что может сделать BOM, так это оказать давление на поставщиков и пользователей, чтобы они обратили внимание на риски безопасности и управление в компонентах с открытым исходным кодом», — сказал он.
«Пользователям программного обеспечения будет легче найти уязвимости, существующие в этих компонентах, и работать над их устранением», — пояснил он.
«Раскрытие также покажет, идет ли поставщик в ногу с выпусками компонентов с открытым исходным кодом», — продолжил он.
«Но все это требует работы, — добавил он, — и сейчас существует тенденция игнорировать проблему, чтобы программное обеспечение могло продолжать двигаться по конвейеру».
