Действительно ли проприетарное ПО надежнее опенсорса?
В декабре 2021 года в популярной Java-библиотеке с открытым кодом Log4J обнаружили уязвимость «нулевого дня». Ошибка получила название Log4Shell. Компании и государственные организации принялись устранять брешь в безопасности, однако эксперты утверждают, что она будет представлять угрозу по крайней мере вплоть до 2032 года. Сегодня, по данным компании Synopsys, 96 процентов коммерческих программ содержат открытый исходный код. И хотя исследования показывают, что лидеры IT-рынка в большинстве доверяют выбору корпоративных опенсорс-продуктов, инцидент с Log4Shell — это повод задуматься, насколько на самом деле безопасен открытый код.
Этим материалом мы продолжаем проект «Исходный код», посвященный опенсорсу: его истории, философии, ключевым принципам, самым известным и важным разработкам, а также законодательству и лицензированию. Проект подготовлен при поддержке высокопроизводительного и масштабируемого российского веб-сервера Angie.
В 2022 году платформа для дата-сайентистов Anaconda опросила более 3 тысяч профессионалов из числа своих пользователей, посвятив несколько вопросов опенсорсу. Среди опрошенных 40 процентов рассказали, что в 2021 году их компании начали отказываться от софта с открытым кодом из-за опасений по поводу его безопасности, а 31 процент специалистов заявили, что на сегодняшний день уязвимости — главная проблема опенсорса. Однако сама по себе модель разработки не определяет уровень защищенности софта.
«Опасность» открытого кода обосновывается тем, что кто угодно может встроить зловредный код, особенно если состоит в сговоре с людьми, которые утверждают изменения. Но фактически на безопасность опенсорса влияет то же самое, что и на проприетарный код, — наличие того, кто отвечает за безопасность и занимается ею, не полагаясь на сообщество.
Чтобы считаться надежным, ПО должно соответствовать регламентам и стандартам, таким как GDPRОпределяет порядок сбора, обработки, хранения и распространения персональных данных в странах Евросоюза., SSDLCSecure Software Development Lifecycle (SSDLC) — защищенный цикл разработки программного обеспечения. Определяет требования и задачи безопасности проекта или приложения. или Microsoft SDLSecurity Development Lifecycle — это подход к обеспечению безопасности, определяющий требования к программированию, тестированию, сертификации, эксплуатации и обновлении при разработке программного обеспечения.. Безопасность складывается из множества факторов:
Для продвижения этих принципов и повышения безопасности ПО с открытым исходным кодом разработчики и компании по всему миру объединились в фонд, поддерживающий безопасную разработку опенсорса, — Open Source Security Foundation (OpenSSF). Он создан для обмена информацией и призван решить вопросы с безопасностью, в том числе даже в автоматическом виде. OpenSSF стремится предоставить разработчикам возможность изучать методы безопасной разработки и автоматически получать рекомендации по ним через приложения, которые они используют. Исследователи, выявляющие проблемы безопасности, отправляют информацию тем, кто может решить проблему. Кроме того, члены сообщества регулярно предоставляют информацию о компонентах, которые они используют и тестируют.
На практике защищенность софта во многом зависит от взаимодействия между отделами информационной безопасности (ИБ) и разработки. Специалисты по безопасности не должны вмешиваться в процесс на каждом шагу, и в то же время им необходимо контролировать соблюдение правил безопасности. При этом важно соблюсти баланс: если приоритет в коммуникации отдается ИБ, разработчики могут почувствовать излишние ограничения, затрудняющие работу; если наоборот — отдел безопасности может отстать от разработки, а софт будет соответствовать стандартам и регламентам, скорее всего, лишь формально.
Однако в общем случае ПО считают безопасным, если оно не содержит уязвимостей — ошибок, позволяющих, например, получить доступ к конфиденциальной информации пользователей. Но если уязвимость еще никто не нашел, это не означает, что ее нет. Даже в старом коде спустя время может быть найдена новая уязвимость. Известные уязвимости собирают в базах данных, которыми пользуются специалисты по информационной безопасности. Уязвимости ранжируются по уровню опасности, от незначительных к критическим. Зачастую незначительные уязвимости могут долго оставаться неисправленными, потому что разработчикам может быть полезнее потратить время и ресурсы на что-то другое.
Часто источником уязвимостей становится человеческий фактор: несоблюдение рекомендаций по безопасности, неправильная настройка программного обеспечения, простые пароли, отсутствие процессов проверки и методов шифрования данных. Например, в 2020 году администратор программы «РЖД Бонус» спровоцировал утечку, по ошибке поместив базу данных в корневой каталог сайта. Согласно исследованию компании Tessian и профессора Стэнфордского университета Джеффа Хэнкока, ошибками сотрудников вызваны 88 процентов утечек данных.
Существует заблуждение, что программы с закрытым исходным кодом лучше защищены от внешних угроз. Между тем, по данным американской технологической компании Qualys, которая также ссылается на отчет Агентства по кибербезопасности и защите инфраструктуры США (CISA), в 2022 году большая часть наиболее эксплуатируемых уязвимостей относилась именно к коммерческому ПО. От взлома не застрахованы даже самые крупные компании. Например, в декабре 2022 года хакеры взломали почтовый клиент Outlook и сервис OneDrive, принадлежащие Microsoft, и получили доступ к аккаунтам государственных служащих США.
Причиной утечек становятся уязвимости в используемом ПО, слабые или редко меняющиеся пароли, целевые атаки с применением вредоносных программ, избыточные права доступа, фишинг и украденные учетные записи. Нередко компании отдают разработку на аутсорс или обмениваются исходным кодом с другими организациями. Взломав их, хакеры могут оставить «закладки» в системе или получить к ней доступ.
Поскольку софт с открытым исходным кодом так или иначе используют многие компании, злоумышленники могут скомпрометировать отдельные части коммерческого ПО или сети его распространения. Например, захватить учетные записи участников проекта или воспользоваться уязвимостями в репозиториях.
Именно это произошло во время кибератаки на американскую компанию SolarWinds. Хакеры проникли в программное обеспечение для управления и мониторинга IT-инфраструктуры компании и модифицировали подключаемый модуль с открытым исходным кодом. Обновление программы Orion, которое затем скачивали пользователи, оказалось заражено вредоносным софтом Sunburst. Жертвами стали крупные технологические компании, такие как Microsoft и Cisco, но сильнее всего пострадали Казначейство, Министерство торговли и Министерство национальной безопасности США.
Согласно отчету компании Endor Labs, наибольший риск сегодня представляют известные, то есть наиболее распространенные и часто эксплуатируемые уязвимости. Разработчики стараются устранять их в первую очередь. Например, уязвимость CVE-2017-5638 в Apache Struts вызвала утечку данных бюро кредитных историй Equifax. Хакеры похитили данные 148 миллионов человек, включая имена, адреса, социальные страховые номера, даты рождения и номера водительских удостоверений. Расследование показало, что компания знала об уязвимостях в системе, но не устранила их вовремя. А уязвимость CVE-2021-44228, также известная как Log4Shell, в Apache Log4j до сих пор считается одной из самых опасных (в момент обнаружения ей был присвоен максимальный уровень опасности по шкале CVSS), поскольку эта библиотека используется во множестве Java-приложений. Поэтому, если не установить обновление вручную, у пользователя исправления не будет, даже если она сама по себе уже исправлена.
Одна из причин, почему проприетарное ПО считается более защищенным, — это то, что часто в нем применяется так называемая обфускация — приведение кода к виду, затрудняющему анализ и понимание алгоритмов его работы при декомпиляции, но сохраняющему исходную функциональность. Однако на самом деле для взлома не требуется восстановление кода всей или даже части программы. Тем, кто взламывает ПО, не обязательно видеть исходный код — бывает достаточно послать неожиданные или необычные данные (например, случайный набор символов) и проследить за реакцией программы, которая может указать на алгоритм обработки входных данных. Если она выдает ошибку или ведет себя нештатно, это может указывать на недостаток, который, в свою очередь, может оказаться возможностью для взлома. Вместе с тем средства мониторинга, отладки и дизассемблирования позволяют получить большую часть исходного кода из скомпилированной версии программы и извлечь достаточно информации, чтобы разобраться во внутреннем устройстве проприетарного софта.
В открытом ПО проще найти эксплоит, но это лишь один из рисков безопасности — не единственный, не самый значительный и не более страшный, чем в закрытом. В проприетарном ПО существует другой риск: мы не знаем, что в этом ПО, и нам туда могут прислать все что угодно. Например, встроить сбор телеметрии или дополнительные процессы, которые не указаны в документации, но которые могут хранить или отсылать данные, логи или еще что-то. Прежде чем мы это заметим, может пройти много времени, потому что разобраться в закрытом софте намного сложнее.
Никита Соболев, независимый разработчик, Github Star
По данным анализа, проведенного компанией Synopsys в 2023 году, 89 процентов кодовых баз содержат открытый исходный код, который устарел более чем на четыре года. Если компоненты проектов не обновляются в течение двух лет, скорее всего, это означает, что проект более не поддерживается. Иными словами, многие компании, использующие открытый код, — а такие есть повсюду, от авиации и энергетики до финтеха и здравоохранения, — уязвимы для кибератак.
Программное обеспечение с открытым исходным кодом часто поддерживается добровольцами, а не полноценной командой разработчиков. Разработка коммерческих продуктов отличается строгим распределением ролей. Над ними трудятся команды, куда входят менеджеры, разработчики, технические писатели, тестировщики и инженеры по проверке качества. Проприетарный софт проходит через множество ревизий и проверок, а поддержку и устранение проблем в дальнейшем обеспечивает компания. В то же время в маленькой команде опенсорс-проекта может не хватать специалистов, поэтому она уделяет меньше времени поиску и исправлению уязвимостей.
Безопасность — это всегда управление рисками. Нет абсолютно безопасного софта. Безопасно только то, что не написано и не используется. Все остальное содержит риски. В случае открытого ПО риск заключается в том, что любой человек может посмотреть код и найти в нем проблемы, которыми можно воспользоваться. Однако для этого нужно знать, что у вас это ПО установлено, а также иметь возможность сделать эксплоит опасным. Чтобы выполнить многие эксплойты, нужен определенный уровень доступа. А если есть доступ, то и эксплойт уже может быть не нужен.
Никита Соболев, независимый разработчик, Github Star
Один из минусов опенсорс-разработки в том, что она может не учитывать современные инженерные практики обеспечения безопасности, такие как DevSecOps. Дополнительным риском становятся случаи, когда разработчики отказываются от поддержки пакетов, которые могут быть в составе ПО. Это создает не только потенциал для неисправленных уязвимостей, но и риск того, что в коде могут отсутствовать необходимые механизмы безопасности, такие как современное шифрование. Если разработчик перестал поддерживать какой-то пакет (компонент), то и шифрование со временем устаревает. Кроме того, бывают случаи, когда разработчики по тем или иным причинам сознательно портят код, находящийся в открытом доступе.
«Санитарный минимум» проверки ПО — это использование анализаторов кода как инструмента непрерывной интеграции (Continuous Integration). Существуют роли и этапы, которые обеспечивают качество разработки.
Помимо разработчика, который пишет код приложения, в команде есть технический писатель, работающий над документацией, инженер тестирования, который создает автоматизированные тесты, а также техлид или архитектор, описывающий архитектуру. В разработке проприетарного ПО эти процессы чаще всего выстроены в кросс-функциональных командах (гибкие методологии итерационной разработки).
В опенсорс-проектах большинство ролей «не разработчик» не так привлекательны. С учетом того, что на команду из восьми разработчиков может приходиться два тестировщика, таких специалистов (тестировщик, технический писатель) просто не хватает. Как следствие, мы имеем недостаток покрытия кодовой базы опенсорс-проектов автоматизированными тестами. А это потенциально и уязвимости, и ошибки в приложении.
Заур Абасмирзоев, генеральный директор компании-разработчика российского веб-сервера Angie
Злоумышленники продолжают все активнее и хитрее атаковать цепочки поставок программного обеспечения. Они пользуются зависимостью компаний от опенсорса: создают вредоносные библиотеки-двойники или заражают надежные библиотеки вредоносным кодом, делая разработчиков невольными соучастниками по внедрению уязвимостей или вредоносных функций в приложения. Поэтому сегодня как никогда разработчики стремятся постоянно изучать передовой опыт обеспечения безопасности на всем протяжении цепочек поставок ПО и пользоваться автоматическими инструментами, снижающими риск человеческой ошибки.
Над проектом с открытым исходным кодом могут работать всего несколько постоянных участников, тогда как большинство разработчиков будут приходить и уходить. С одной стороны, это затрудняет работу над безопасностью, а с другой — новые люди могут посмотреть на код свежим взглядом и с большей вероятностью заметить ошибку. Поэтому замечать и исправлять уязвимости, позволяя быстро выявлять и устранять проблемы, потенциально могут тысячи людей. К сожалению, могут, но не всегда стремятся. По данным опроса Linux Foundation за 2020 год среди контрибьюторов по всему миру, только 3 процента из них тратят свое время на вопросы безопасности ПО. Впрочем, успешные проекты с открытым исходным кодом, как правило, обладают достаточным количеством ресурсов, чтобы привлекать сотрудников для аудита исходного кода. Например, в Mozilla для устранения проблем безопасности существует отдельная команда.
Однако, даже если злоумышленник попробует создать форк проекта, он не сможет манипулировать оригинальным репозиторием. Перед утверждением изменения пройдут через аудит специалистов. Это означает, что необходимо приложить дополнительные усилия, чтобы добавить в проект вредоносный код и воспользоваться уязвимостью. Подробнее о том, как устроена работа над опенсорс-проектам, читайте в материале «Софт для всех».
Важно, какие подходы использует конкретный разработчик. В общем случае действует правило: чем меньше денежных и людских ресурсов направлено на безопасную разработку и устранение уязвимостей, тем больше вероятность того, что разработка может быть менее безопасной. В открытом ПО полагаются на себя, коллег и сообщество, которое может проанализировать код, для исправления ошибок с безопасностью. В закрытом ПО за безопасностью «должна» следить компания-разработчик и заказчик. А в реальности все очень по-разному.
Дмитрий Фролов, основатель tvoygit.ru
Уязвимости в проприетарном и открытом софте сегодня устраняются примерно с одинаковой скоростью. Поэтому безопасность зависит от соблюдения стандартов безопасной разработки, скорости обнаружения уязвимостей, а также состава и компетенций команды. Если сотрудники хорошо разбираются в продукте с открытым кодом, то могут отслеживать, изучать и анализировать проблемные места, снижая риски безопасности.
Несмотря на то что у коммерческого вендора выше мотивация вкладываться в безопасность, чем у энтузиастов, полностью полагаться на него нельзя. Поэтому, как и в случае опенсорса, пользователю также следует самому заботиться о безопасности. В конечном итоге недоверие к открытому ПО связано не с безопасностью, проблемы с которой существуют везде. Оно возникает, поскольку зачастую неясно, кого считать ответственным за безопасность. Если за надежность коммерческого софта несет ответственность компания-разработчик, то риски использования опенсорса ложатся на пользователя. Наталья Каперская, президент ГК Infowatch, считает, что нельзя строить системы государственной значимости исключительно на открытом коде. По ее словам, «open source — это „безответственное“ программное обеспечение, за которое никто не несет ответственности». Тем не менее множество компаний по всему миру поддерживают опенсорс и используют программы с открытым кодом. Подробнее о том, почему они это делают, читайте в материале «Философия кода».
Среда, в которой запускается программа, все время меняется: обновляются библиотеки, операционная система, устанавливаются разные программы. Изменения вносятся без участия программиста другими участниками, поэтому всегда возможна ситуация, при которой взаимодействие программы со своим окружением приводит к тому, что уязвимость становится возможной. Поэтому, как бы мы ни старались разрабатывать безопасно, вероятность появления уязвимости при определенном сценарии использования программы остается что в открытом, что в закрытом ПО. Важно тестировать свою программу в том числе и на безопасность, следить и устранять уязвимости, пользоваться анализаторами кода, применять безопасные паттерны разработки и развертывания.
Дмитрий Фролов, основатель tvoygit.ru
Благодарим за помощь в подготовке материала Максима Лапшина, основателя и технического директора Flussonic.
Реклама: ООО «Веб-Сервер», ИНН 9704151517, Kra247g3A