Американские исследователи подготовили отчет, в котором говорится о том, что компоненты с открытым исходным кодом присутствуют практически во всех современных приложениях, а именно в 96% кодовых баз. Исследование основывается на двух предыдущих переписях, выходя за рамки библиотек операционных систем (ОС) и изучая компоненты уровня приложений.
Резкий рост
Исследователи из Гарвардской школы бизнеса и Лаборатории инновационных наук Гарварда в партнерстве с Linux Foundation Research и OpenSSF подготовили отчет под названием Census III of Free and Open Source Software. Отчет был опубликован на официальном сайте Linux Foundation Research.
В исследовании, подчеркивающем всепроникающую роль свободного и открытого программного обеспечения (ПО) в современной цифровой экономике, показано, что компоненты открытого ПО присутствуют почти во всех современных приложениях, при этом пакеты для облачных вычислений демонстрируют значительный рост такого присутствия, а традиционные модели разработки также быстро эволюционируют в этом плане.
Сам же исследование основывается на двух предыдущих отчетах, но выходит за рамки библиотек ОС изучает компоненты уровня приложений, которые формируют строительные блоки современного ПО.
Основные результаты аналитиков из Linux Foundation Research включают ряд новшеств. ИТ-компоненты с открытым исходным кодом присутствуют в 96% кодовых баз. Наблюдается резкий рост использования пакетов, специфичных для облачных сервисов.
Несмотря на то, что Python 3 вышел 16 лет назад, на некоторых секторах число случаев использования Python 2 достигает 20-30%. В настоящее время по-прежнему используется устаревший Python 2, что подвергает ИТ-системы рискам безопасности. Ведь в настоящее время нет практически никаких причин рассматривать Python 2, если только программист не работает с определенными библиотеками, которые еще не совместимы с Python 3.
С момента проведения исследования Census II число пользователей Rust выросло на 500%, что свидетельствует о переходе к программированию с защитой памяти (memory-safe programming language - язык программирования, безопасный для памяти; включает в себя функции, гарантирующие, что программа не сможет получить доступ к памяти, которая не была выделена или уже освобождена).
Отсутствие стандартизированных имен для программных компонентов повышает риски безопасности. Крупными проектами свободного и открытого ПО, по данным Linux Foundation Research, 40% лучших проектов принадлежат одному или двум разработчикам, на долю которых приходилось более 80% вкладов.
Директор Open Source Supply Chain Security в OpenSSF Дэвид Уилер (David Wheeler) отмечает, что самым большим сюрпризом стало значительное увеличение использования библиотек софта с общедоступным исходным кодом для доступа к облачным ИТ-сервисам. Он рассказал, что если на момент проведения предыдущего анализа Census II использование облачных ИТ-сервисов не было чем-то новым, то в Census III зафиксирован весьма значительный рост их использования. По мнению Уилера, это говорит о том, что раньше при развертывании облаков часто использовался подход lift-and-shift (простой перенос существующих программных приложений без модификации), а уже теперь ПО все чаще разрабатывается специально для работы в облаке и для использования конкретных ИТ-сервисов, доступных в нем.
Риски в проектах
В 2024 г. была обнаружена кибератака на цепочку поставок, которая использовала социальную инженерию для злонамеренного внедрения бэкдора в популярный Open Source-пакет XZ Utils. Сама же ИТ-атака включала в себя запуск кампании давления на единственного мейнтейнера проекта с целью добавления второго сопровождающего, который впоследствии и внедрил бэкдор. Этот инцидент служит подтверждением одного из ключевых выводов отчета о риске концентрации ответственности в FOSS-проектах и последствиях для безопасности, связанных с тем, что проекты поддерживаются очень маленькими командами.
По мнению Уиллера, данная кибератака иллюстрирует проблему, над решением которой работает Open Source Security Foundation: обеспечение того, чтобы используемый людьми исходный код соответствовал тому, что проходит проверку. Большое преимущество открытого ПО заключается в том, что его можно широко проверять на предмет непреднамеренных или преднамеренных уязвимостей, поясняет он. При этом Уилер отмечает, что проверка не поможет, если то, что проверяется, не используется для создания конечного продукта. Проекты OpenSSF, такие как SLSA и Sigstore, работают над укреплением процесса сборки и распространения кода, чтобы гарантировать его проверку перед запуском.
Летом 2024 г. специалисты агентства кибербезопасности и безопасности инфраструктуры США (CISA) опубликовали исследование с подробным анализом 172 ключевых Open Source проектов на предмет ИТ-уязвимости исходного кода различных языков программирования к ошибкам памяти. Согласно отчету CISA, 52% критически популярных проектов с открытым исходным кодом содержат код, написанный на небезопасных для памяти языках, а 55% от общего числа строк кода (LoC) в популярных и ключевых проектах написаны на небезопасных для памяти языках.
Лучшие Open Source проекты
Для бизнеса Open Source раскрывается с двух сторон т.к. первое преимущество в том, что компании могут пользоваться открытое ПО бесплатно. Это экономит деньги и позволяет вносить любые изменения в исходный код, бесплатно настраивая программу под потребности бизнеса. Примеры полезных OSS-решений: OpenOffice - свободный пакет офисных приложений; Linux - бесплатные ОС; iRedMail - почтовый сервер на базе Postfix; Rocket.Chat - корпоративный мессенджер для видеозвонков и переписки.
Программисты используют Open Source-решения для оптимизации процессов разработки. Популярные программы и ИТ-инструменты: редактор VSCodium - альтернатива Visual Studio Code; Supabase - реляционная база данных на основе технологий PostgreSQL; Django - бесплатный фреймворк для веб-приложений на Python. Appsmith - решение для создания административных панелей, дашбордов и внутренних инструментов; Kubernetes (K8s) - решение для автоматизации развертывания и управления сервисами на основе контейнеров.
Источник: cnews.ru
Нейросети убивают Open Source. Разработчики больше не пишут код, они чинят ошибки, которые нафантазировал искусственный интеллект
Искусственный интеллект стал проблемой для разработчиков ПО с открытым кодом. Для поиска ошибок в нем багхантеры стали применять нейросети, и те сразу же начали галлюцинировать и заваливать программистов отчетами об ошибках, не несущих в себе никакой полезной информации. Но выглядят они как легитимные, и потому разработчикам приходится тратить уйму времени на проверку каждого из них.
Интеллект искусственный, мусор реальный
Разработчики ПО с открытым исходным кодом тонут в мусорных отчетах об ошибках, написанных нейросетями, пишет The Register. Специалисты по отлову багов в открытом коде (багхантеры) стали очень активно пользоваться нейросетями для помощи в выполнении своей работы, а те начали генерировать бесполезные отчеты о несуществующих ошибках.
Издание пишет, что проникновение искусственного интеллекта в сферу так багхантинга открыло «новую эру некачественных отчетов по безопасности для программного обеспечения с открытым исходным кодом» (new era of slop security reports for open source). Поддерживающие Open Source-проекты разработчики уже открыто заявляют, что охотникам за ошибками в программном коде стоит меньше полагаться на результаты, полученные с помощью нейросетей.
Вопрос мусорных отчетов об ошибках поднимается уже на очень высоком уровне. В число тех, кто намеренно обращает внимание на проблему входит разработчик систем безопасности в Python Software Foundation Сет Ларсон (Seth Larson).
Всю правду в лицо
В начале декабря 2024 г. Ларсон опубликовал в своем блоге призыв ко всем специалистам по поиску ошибок в коде не использовать в своей работе искусственный интеллект. «Недавно я заметил всплеск крайне низкокачественных, спамовых и LLM-галлюциногенных отчетов по безопасности для проектов с открытым исходным кодом», – написал он (Recently I've noticed an uptick in extremely low-quality, spammy, and LLM-hallucinated security reports to open source projects).
Также Ларсон напомнил, что в январе 2024 г. с аналогичной проблемой столкнулись разработчики Curl – кроссплатформенной служебной программы, позволяющей взаимодействовать с множеством различных серверов по различным протоколам с синтаксисом URL.
Сет Ларсон отдельно прошелся по умению сгенерированных бесполезных багрепортов мимикрировать под корректные и подготовленные настоящими специалистами отчеты. «На первый взгляд эти отчеты кажутся потенциально легитимными, поэтому требуется время для их опровержения», – сказал он (These reports appear at first glance to be potentially legitimate and thus require time to refute).
Разработчики устроят самосуд
Проблема со сгенерированными багрепортами для Curl проявилась почти год назад, но за прошедшее время она так и не была решена. На нее тогда указал один из мейнтейнеров проекта Дэниел Стенберг (Daniel Stenberg), и он же в декабре 2024 г. заявил, что продукты галлюцинаций нейросетей, подаваемые под видом отчетов об ошибках, продолжают поступать ему. Стенберг подчеркнул, то ему приходится тратить время на общение и споры с отправителями таких отчетов.
«Мы регулярно и в больших объемах получаем подобный ИИ-мусор. Вы вносите свой вклад в ненужную нагрузку на разработчиков Curl, и я отказываюсь относиться к этому легкомысленно и полон решимости быстро с этим бороться. Сейчас и впредь», – заявил Стенберг.
«Вы предоставляете нам то, что кажется очевидным ИИ-отчетом, в котором вы говорите, что есть проблема безопасности, вероятно, потому, что ИИ обманул вас, заставив поверить в это, – продолжил Стенбенг. – После этого вы тратите наше время, не сообщая нам, что ИИ сделал отчет за вас, а затем продолжаете обсуждение с еще более бредовыми ответами – по-видимому, также сгенерированными ИИ».
Превратить весь интернет в помойку
Спамовый, низкосортный онлайн-контент существовал задолго до чат-ботов, но генеративные нейросети сделали его производство как никогда простым и быстрым. Результатом является «загрязнение» (pollution) журналистики, веб-поиска, а также социальных сетей, считают аналитики The Register.
Для проектов с открытым исходным кодом отчеты об ошибках, создаваемые с помощью ИИ, особенно пагубны, поскольку они требуют рассмотрения и оценки со стороны инженеров по безопасности (многие из которых являются волонтерами), которые и так ограничены во времени.
Ларсон рассказал The Register, что, хотя он видит относительно немного некачественных отчетов об ошибках ИИ (менее десяти в месяц), это может быть только началом.
«Что бы ни случилось с Python или pip (система управления пакетами для Python – прим. CNews), это, скорее всего, в конечном итоге произойдет с большим количеством проектов, – утверждает Ларсон. – Меня больше всего беспокоят мейнтейнеры, которые работают в изоляции (в отрыве от сообщества – прим. CNews). Если они не знают, что отчеты, генерируемые ИИ – обычное дело, они могут не распознать, что происходит, прежде чем потратят тратить кучу времени на ложный отчет. Тратить драгоценное время волонтеров на то, что вам не нравится, и в итоге впустую – это самый верный способ отвадить мейнтейнеров от работы».
Поиск решения
Ларсон утверждает, что сообществу разработчиков ПО с открытым исходным кодом необходимо сыграть на опережение, чтобы смягчить потенциальный ущерб. «Я не решаюсь утверждать, что "больше технологий" – это то, что решит проблему. Я думаю, что безопасность открытого исходного кода нуждается в некоторых фундаментальных изменениях. Она не может продолжать возлагаться на небольшое количество мейнтейнеров, и нам нужно больше нормализации и прозрачности в отношении их вклада в открытый исходный код», – заявил он The Register.
«Мы должны ответить на вопрос: "как нам привлечь больше доверенных лиц к участию в сообществе открытого исходного кода?". Финансирование персонала – это один из ответов, например, мой собственный грант через Alpha-Omega, а вовлечение в виде пожертвованного рабочего времени – это другой ответ», – подытожил Ларсон.
Пока сообщество разработчиков ПО с открытым исходным кодом размышляет, как реагировать, Ларсон просит отправителей ошибок не присылать ему отчеты, пока они не будут проверены человеком, и не использовать ИИ, потому что «эти системы сегодня не могут понимать код» (these systems today cannot understand code). Он также призывает платформы, которые принимают отчеты об уязвимостях от имени техников, принять меры по ограничению автоматического или злонамеренного создания отчетов о безопасности.
Источник: cnews.ru
