Comments 5
Эммм... А как насчет намеренно внедряемых в закрытый код бэкдоров и трекеров (благодаря чему могут отключать станки и турбины тех же Сименс, если их привезут не туда), непрозрачной отправки данных (конечно же обезличенных и чисто для статистики, ага, ага), годами не исправляемых уязвимостей (привет, венда)? Ой, в пропоиетарном софте уязвимостей больше окпзалось? Как так, вахвахваз? Наверное статья тупо голимая реклама анализатора? И правда, она самая.
Пишите лучше чтоли, ну или не позорьтесь. Как бы за это время у проприетарщиков было гораздо больше уязвимостей и их выявить и исправить гораздо сложнее именно в силу закрытости кода, а свободный проект и форкнуть можно.
Как сообщает нам нейросеть, «анализ сторонних библиотек, регулярное обновление зависимостей и применение современных инструментов для аудита безопасности могут значительно снизить вероятность... инцидентов».
Например, если есть зависимость от отправки данных, надо постоянно, постоянно, постоянно её мониторить! :-)
Спасибо за отличный вопрос, наши эксперты на связи :)
Мы согласны, что в проприетарном коде так же встречаются уязвимости (и НДВ, как в Вашем примере). Их выявлять сложнее – используются сложные инструменты и нужны очень опытные эксперты. В данной статье мы рассматривали именно open source из-за его «массовости» и простоты использования в собственных проектах. Действительно, в сторонние библиотеки можно внести исправления (хотя это потребует дополнительного времени и ресурсов), но, согласитесь, первым шагом будет выявление именно проблемной библиотеки.
В тексте противопоставлены не "открытый" и "закрытый" код, а источник кода - "своё" и "сторонее"
Ой, в пропоиетарном софте уязвимостей больше окпзалось?
А это вообще к вопросу не имет отноения, потому что проприетарное ПО это "несвободное", а не "закрытый код".
Открытый и опасный: как снизить риски open-source в приложениях