Ещё недавно софт с открытым исходным кодом не считался безопасным для применения в коммерческих проектах. Однако его достоинства заставили заказчиков наращивать использование Open Source, и теперь он встречается практически везде. Уже никто не возражает против применения опенсорса, однако заказчики и разработчики со вниманием относятся к тому, чтобы обеспечить безопасность кода.
- Введение
- Безопасность Open Source
- Малые, средние и крупные компании
- Выбор политики безопасности кода в компании
- Контроль за уязвимостями в Open Source
- Уровень возникающих рисков при использовании Open Source
- Откуда становится известно об уязвимостях?
- Сколько времени тратится на поиск уязвимостей?
- Главные выводы исследования
- Направления дальнейшего развития безопасности Open Source
- Выводы
Введение
Программное обеспечение с открытым исходным кодом (Open Source) уже стало неотъемлемой частью большинства программных экосистем. Экспертные оценки указывают на то, что совокупный объём опенсорсного кода, находящегося в эксплуатации в коммерческих системах по всему миру, составляет в настоящее время от 70 до 90 %. Код Open Source встречается практически повсюду: от операционных систем до контейнеров в облачных вычислениях, широкое применение он нашёл в криптографии, сетевых устройствах, веб-разработках.
В апреле 2022 года компания LF Research провела опрос, в котором приняли участие 539 компаний, использующих ПО с открытым исходным кодом для своей разработки и в эксплуатации. Результаты были опубликованы в виде отчёта под названием «Addressing Cybersecurity Challenges in Open Source Software». Партнёрами исследования выступили некоммерческая организация Linux Foundation, ассоциация Open Source Security Foundation (OpenSSF) и ряд других структур (Snyk, Eclipse Foundation, CNCF и CI/CD Foundation). Целью исследования были оценка достигнутого уровня безопасности кода Open Source и выявление направлений, где уровень безопасности ещё недостаточно высок.
Далее мы расскажем о полученных результатах исследования, которые позволили выделить наиболее важные для развития безопасности опенсорс-программ направления. Забегая вперёд, отметим, что в целом полученные результаты были ожидаемыми и не принесли сюрпризов. Польза от исследования состоит прежде всего в том, что оно позволило получить количественные оценки таких понятий, как «безопасная разработка» и «степень уверенности в безопасности при эксплуатации Open Source».
Безопасность Open Source
Исследование началось с вопросов, через которые планировалось оценить сложившееся отношение разработчиков и заказчиков к безопасности открытого кода. Как показали результаты, только половина разработчиков уделяют этим вопросам должное внимание. В остальных компаниях пока не налажен должный контроль за безопасностью.
Если переходить к цифрам, то только 49 % опрошенных организаций, где ведётся разработка программных продуктов, имеют развитый набор правил, позволяющих контролировать должным образом безопасность создаваемого ПО. В то же время треть опрошенных (34 %) заявили, что у них нет специальных требований по контролю за безопасностью разработки. Немало (17 %) было также и тех, кто заявил, что они не могут сказать ничего определённого, поскольку не сталкивались с подобными вопросами.
Рисунок 1. Контроль за безопасностью открытого исходного кода
Исследователи также указали на полный набор мероприятий, который должны иметь компании для обеспечения полноценного контроля над безопасностью разрабатываемого кода и его администрированием. Без соответствующих политик предприятия подвергают себя значительным финансовым и репутационным рискам, считают исследователи. Причиной возникающих рисков становится отсутствие у компаний уверенности относительно надёжности применяемого открытого кода.
Малые, средние и крупные компании
Следующий этап исследования был связан с выявлением различий в контроле над безопасностью для компаний различного масштаба. Были выделены организации малого, среднего и крупного размера. К числу малых предприятий были отнесены компании с числом сотрудников до 500 человек; их доля в исследовании составила 44 %. К компаниям среднего уровня (их доля — 20 %) были отнесены организации с численностью персонала до 5000 человек. Доля крупных компаний с численностью более 5000 человек составила 35 %.
Оказалось, что в компаниях среднего и крупного масштаба внедрённые политики безопасности встречаются чаще, чем в небольших фирмах. Результат вполне ожидаемый. Неожиданным стало то, что сохранилась та же доля (15–17 %) компаний, сотрудники которых не осведомлены о принимаемых мерах по безопасности.
Рисунок 2. Контроль за безопасностью Open Source в компаниях разного уровня
Интерес вызвала также оценка уровня безопасности применяемого ПО с открытым исходным кодом. Подавляющее большинство респондентов уверены, что используемый в их компаниях открытый код «в целом безопасен» (рис. 3). Высокую степень уверенности (не ниже, чем «в целом безопасен») высказали представители 59 % компаний. С ростом внимания к защите и со внедрением регламентов для её контроля доля уверенности в используемом ПО увеличивается (до 70 %). Если регламенты отсутствуют, то степень уверенности падает (до 45 %).
Рисунок 3. Оценка уровня безопасности используемого ПО с открытым исходным кодом
Аналогичная картина наблюдается и применительно к оценке уровня безопасности открытого кода, используемого в разработке (рис. 4). Около 59 % опрошенных считают, что применяемые процессы безопасны «в определённой степени» или «им можно полностью доверять». Когда в компаниях налажен явный контроль за безопасностью используемых опенсорс-компонентов, степень уверенности возрастает до 73 %. Если специального регламента для контроля безопасности нет, то она падает до 47 %.
Рисунок 4. Оценка уровня безопасности при разработке или эксплуатации открытого кода в компании-вендоре
Результаты исследования также показали, что повышенное внимание к безопасности применяемого ПО с открытым исходным кодом ведёт к росту уверенности. По оценкам, нынешние 59 % должны вырасти до 72 % к концу 2022 г. и до 77 % к концу 2023 г. Повышенное внимание выражается прежде всего во внедрении лучших практик безопасной разработки ПО и в развитии средств автоматизации в технологических процессах.
Выбор политики безопасности кода в компании
Следующий вопрос, который интересовал исследователей, касался особенностей внедрения политик безопасности в компаниях. Его результаты, на первый взгляд, обескураживают. Даже среди небольших компаний только 42 % участников заявили о наличии ответственных за контроль над безопасностью применяемого открытого кода среди CISO и / или специальных команд. В компаниях среднего уровня доля сообщающих о присутствии такого контроля совсем невысока — 19 %. По мнению исследователей, этот уровень явно недостаточен.
Рисунок 5. Ответственные за контроль над безопасностью Open Source
Самым неожиданным моментом для исследователей стала доля выбравших опцию «Никто». Оказалось, что существуют компании, в которых может быть даже подготовлен план мероприятий по контролю над безопасностью кода, но ответственные не назначаются. В среднем бизнесе доля таких компаний достигает 30 %, в крупном их меньше, но всё равно вполне много — 12 %. И только в небольших компаниях, где все поставленные задачи «на виду», вариант «Никто» отметил только 1 % опрошенных.
Наиболее обнадёживающими для исследователей были ответы «Разные группы» и «Специально выделенные сотрудники» — эти опции выбрали 10–20 % опрошенных из компаний всех уровней.
Приблизительно столько же респондентов выбрали передачу ответственности за безопасность опенсорс-компонентов разработчику или интегратору, оказывающему техническую поддержку: от 8 до 17 %.
Контроль за уязвимостями в Open Source
Появление уязвимостей в открытом коде является естественным процессом, считают исследователи. Они назвали несколько причин: особенности применяемого языка программирования, особенности процесса разработки и интеграции ПО (CI/CD), уровень образования и накопленные навыки программистов, объём соответствующего тестирования.
Как отмечают исследователи, управление уязвимостями нельзя отнести к «точной науке». Этот процесс требует подхода, который учитывал бы самые разные, подчас противоречащие друг другу факторы. При сканировании часто возникает множество срабатываний, часть из которых являются ложными, а точность выявления уязвимостей сильно зависит от применяемого сканера. С другой стороны, даже обнаруженная в коде уязвимость не всегда имеет существенное значение, потому что не весь загружаемый код реально работает для решения практических задач.
Исследователей интересовало прежде всего то, есть ли связь (прямая или косвенная) между процессом выявления уязвимостей и внедрением ПО с открытым исходным кодом. Как показали результаты, в целом в отрасли принято считать, что прямые риски от использования Open Source легко отслеживаются на практике, поэтому возникновение подобных рисков не влечёт за собой критической опасности. Главные проблемы возникают с появлением косвенных связей, когда внедряемое ПО подгружает сторонние модули, контроль за безопасностью которых сильно затруднён или отсутствует вообще. Подобные риски стараются выявлять и устранять.
Рисунок 6. Вероятность появления уязвимостей или компрометации данных из-за наличия внешних ссылок в открытом коде
Уровень возникающих рисков при использовании Open Source
Главным источником рисков при использовании открытого кода являются сторонние программы и модули, вызываемые из применяемого ПО. Эти компоненты разрабатываются на стороне, в них постоянно вносят изменения. Компания может проверить установленное ПО с открытым кодом на уязвимости на этапе внедрения, однако это не гарантирует безопасности при последующих загрузках.
При такой неопределённости оценку рисков было решено давать по количеству подгружаемых модулей. По мнению исследователей, этот показатель (количество внешних связей на проект) является хорошей отправной точкой для оценки величины угрозы.
Рисунок 7. Среднее количество внешних связей на проект на различных языках программирования
Как видно из диаграммы, среднее количество может составлять от 25 (Python) до 173 (JavaScript).
Естественно, возникает вопрос: действительно ли код на JavaScript (173 внешние ссылки) более опасен, чем код на .NET (49 зависимостей), Go (56 зависимостей) или Java (40 зависимостей)? Исследователи дают однозначный ответ: нет. Каждая зависимость в коде на JavaScript ведёт к подключению только одного внешнего модуля, и поэтому степень влияния каждой ссылки невелика. В то же время код на Java имеет ссылки на крупные внешние библиотеки, которые применяются для выполнения различных прикладных задач, и поэтому диапазон влияния каждой ссылки значительно шире.
Рисунок 8. Среднее количество обнаруживаемых уязвимостей в зависимости от языка и сложности проекта Open Source
Откуда становится известно об уязвимостях?
Серьёзное внимание во многих компаниях уделяется выбору источника информации об уязвимостях. Правильный выбор имеет критическое значение, отмечают исследователи.
Рисунок 9. Источники информации об уязвимостях в открытом коде
В целом, опрошенные выделяют главные отраслевые источники данных о раскрытых уязвимостях (каталоги CISA (US-CERT), NIST (NVD), MITRE (CVE) и др.), ссылаются на оповещения от систем автоматизированного мониторинга. Среди других важных источников информации называются сообщения на форумах разработчиков, отраслевые новости и блоги.
Большое значение для выявления уязвимостей имеют также проведение аудитов с привлечением внешних экспертов, результаты собственных проверок, тестовые запуски в рабочих группах, сообщения от хакеров.
Сколько времени тратится на поиск уязвимостей?
Получить точный ответ на этот вопрос непросто, отмечают исследователи. Он зависит от разных факторов. Однако можно назвать среднее время (количество дней), в течение которых удаётся выявить и устранить уязвимости.
Рисунок 10. Средняя задержка при устранении уязвимости в открытом коде для различных языков программирования
Перечислены также основные инструменты, которые применяются компаниями для поиска уязвимостей. На первом месте оказались инструменты SAST (Static Application Security Testing), на втором — SCA (Software Composition Analysis). Третьим по распространённости способом названо применение расширений среды разработки, позволяющих проводить всё тот же статический анализ кода. Предложенный порядок в списке — весьма условный, отмечают исследователи. Как показывает практика, эти и другие способы поиска уязвимостей часто используются одновременно.
Рисунок 11. Источники обнаружения уязвимостей в открытом коде
Для контроля безопасности в проектах применяются свои инструменты, перечисленные на следующей диаграмме.
Рисунок 12. Программные инструменты для проверки безопасности при разработке с применением Open Source
Главные выводы исследования
Главным практическим результатом проведённого исследования авторы называют полученный список правил повышения безопасности при разработке с использованием опенсорс-компонентов.
Рисунок 13. Наиболее эффективные методы, способствующие повышению безопасности открытого кода
Прежде всего выделено использование интеллектуальных средств контроля безопасности кода (59 %). Передовой уровень отражает также наличие сертификатов по безопасной разработке ПО — об этом упомянули 52 % опрошенных. Отмечается наличие сертификатов OpenSSF Best Practices, OpenSSF Scorecards, CNCF. Упоминается также OpenSSF (LFD121) — учебный курс с последующей сертификацией.
Направления дальнейшего развития безопасности Open Source
В заключении выделены направления, по которым исследователи рекомендуют наращивать внутри компаний активность по повышению безопасности открытого кода.
Рисунок 14. Направления дальнейшего роста безопасности Open Source
В ответах респондентов наиболее часто упоминались применение лучших практик для безопасной разработки (73 %), использование специальных инструментов для анализа уязвимостей (61 %) и обучение сотрудников (53 %).
Выводы
Проведённое Linux Foundation и Snyk исследование позволило количественно оценить то, как в компаниях борются за повышение безопасности открытого кода на стадиях его разработки и эксплуатации. В целом, результаты оказались предсказуемыми. Но благодаря собранной статистике они обеспечивают возможность дать объективный анализ общего состояния дел с поддержкой безопасности в проектах с использованием Open Source.
Результаты интересны также для России, где проводимая сейчас политика импортозамещения предполагает активное применение разработок Open Source для ускоренного устранения разрыва в программных технологиях с западными вендорами. В этих условиях разработка безопасного софта имеет первостепенное значение.
