5 мифов про (без)опасность Open Source
Фото: 123rf / Legion-Media
В ближайшие два года можно ожидать, что две трети ПО в российском корпоративном сегменте будут основаны на открытом исходном коде. Так утверждают аналитики Института изучения мировых рынков. Тем не менее до сих пор существуют предрассудки относительно Open Source, связанные с аспектами безопасности. Рассмотрим самые популярные из них и вместе с менеджером по продуктовому маркетингу Arenadata Екатериной Ульяшовой разберемся, оправданы ли они.
Open Source Software, OSS — программное обеспечение с открытым исходным кодом, доступное для использования, изменения и распространения в соответствии с лицензионными условиями.
Миф 1. OSS — «решето»: в нем множество ошибок и уязвимостей, которые никто не устраняет
Подход к публикации исходного кода не определяет уровня безопасности. По данным отчета Coverity Scan Report, посвященного качеству кода, cреднее количество ошибок в OSS и проприетарном коде («закрытом» ПО — объекте интеллектуальной собственности автора или правообладателя) примерно на одном уровне — 0,69 против 0,68 ошибки на тысячу строк кода. Это не превышает требований промышленных стандартов качества, допускающих одну ошибку на тысячу строк кода.
Не каждая ошибка является уязвимостью, однако некоторые дефекты в коде могут использоваться во вредоносных целях. При этом скорость устранения уязвимостей в проприетарных и OSS-продуктах в среднем сопоставима — это вопрос компетентности команды и внедренных процессов и процедур, а не бизнес-модели.
Итого: если команда проекта или продукта обладает экспертизой в безопасности, ничто не мешает ей системно отслеживать уязвимости и снижать риски.
Миф 2. За безопасность OSS никто не отвечает
Справедливо, но только если мы говорим о сообществе разработчиков. Если компания принимает решение строить для своих нужд систему на базе открытого исходного кода, то все риски она принимает на себя. В свою очередь, за коммерческий продукт полностью отвечает вендор.
И здесь мы снова уходим от противопоставления открытого исходного кода проприетарному. Если вендор строит коммерческий продукт — на базе OSS или собственных разработок, поиск и устранение уязвимостей и доработки в части информационной безопасности должны вестись целенаправленно, без ожидания исправлений от сообщества. Вендор обладает экспертизой в ИБ и ориентируется в регуляторных требованиях; руководствуясь этими знаниями, он добавляет функции безопасности в продукт, использует практики безопасной разработки и многоуровневые процедуры проверки кода.
Итого: ответственность за безопасность принимает на себя команда, строящая продукт на базе OSS. Приобретение вендорского продукта кратно снижает риски.
Миф 3. В OSS полно «закладок»: кто угодно может встроить что угодно
Частично справедливо. Основано на предположении, что злоумышленник в сговоре с владельцем проекта может добавить недокументированные возможности (НДВ) в продукт. Но с проприетарным софтом тезис тоже работает: мы не знаем, какие возможности, не указанные в документации, есть в продукте. И разобраться в этом сложнее, чем в открытом проекте.
Добавление НДВ в OSS затруднено, так как весь код открыт, это позволяет на этапе сканирования и анализа достаточно беспроблемно выявлять все лишнее. В проприетарном ПО наличие умышленно внедренных нелегитимных функций может быть выявлено только косвенно и негарантированно с помощью моделирования действий злоумышленников.
Выявление «закладок» — одна из приоритетных задач для любого вендора. Процесс настроен так, что в постоянном режиме код в несколько этапов проверяется специалистами.
Итого: нельзя полностью доверять только вендору или только сознательности сообщества. Лучше совместить прозрачность открытого исходного кода и экспертизу вендора, у которого есть команда безопасной разработки и отлаженные процессы.
Миф 4. Проприетарные продукты лучше защищены от взлома
Ломают все, защищенных на 100% продуктов не бывает.
Например, в известном инциденте из мира проприетарного ПО хакеры взломали почтовый клиент Outlook и добрались до аккаунтов государственных служащих. А через эксплойт (внедрение вредоносного ПО) в фреймворк с открытым исходным кодом Apache Struts, который использовала компания Equifax, злоумышленники завладели личной информацией 143 млн американцев.
Итого: безопасность зависит как от скорости обнаружения уязвимостей командой разработки, так и от применения дополнительных мер защиты командой эксплуатации.
Миф 5. Нестабильность развития OSS-проектов с точки зрения ИБ
Жизненный цикл OSS крайне непредсказуем. Перспективных проектов много, но выживает лишь незначительная часть, остальные перестают развиваться. Если проект перестал развиваться, это означает, что и защищенность его падает.
С другой стороны, это справедливо и для проприетарного ПО — не каждый вендор будет инвестировать в безопасность неприоритетных продуктов.
Итого: возвращаемся к тезису об ответственности вендора. Разработчик коммерческого продукта на базе OSS напрямую заинтересован в развитии проекта, чтобы совместить функциональность и другие преимущества открытого ПО с безопасностью.
Подписывайтесь на нас:
Еще по теме
