Кибербезопасность с открытым исходным кодом — это бомба замедленного действия

Я был ошеломлен, когда в марте прошлого года узнал, что программный сбой представляет собой значительный риск для обширных областей Интернета. Оказалось, что XZ utils, широко используемый инструмент сжатия с открытым исходным кодом, был тайно интегрирован в многочисленные программные приложения и операционные системы. Без ведома большинства пользователей этот инструмент содержал скрытый бэкдор.

Скрытый вход в программное обеспечение, называемый бэкдором, мог дать неавторизованным лицам возможность получить контроль над зараженными компьютерами. Если бы этот бэкдор получил широкое распространение, он мог бы подвергнуть опасности бесчисленное количество пользователей.

Я рад, что был частью команды, которая обнаружила проблему до того, как она нанесла массовый ущерб. Будучи старательным инженером-программистом в Microsoft, во время плановой проверки я обнаружил некоторые странности в коде. Мы сразу же взялись за проект и устранили проблему.

Как геймер, я едва предотвратил катастрофу во многих играх, но недавний эпизод XZ напомнил мне о постоянных проблемах в разработке с открытым исходным кодом. Дело не только в этом инциденте: было множество случаев, когда ошибка в открытом исходном коде подвергала риску обширные части сети. К сожалению, этот цикл, вероятно, будет продолжаться. Решение сложных вопросов кибербезопасности, связанных с программным обеспечением с открытым исходным кодом, может оказаться непростой задачей, особенно для новичков. Итак, позвольте мне отправиться в путешествие по его сложной экосистеме и пролить свет на эти запутанные вопросы.

Интернет работает на FOSS

Сегодня большая часть кодовых баз, примерно от 70 до 90 процентов, создается с использованием программного обеспечения с открытым исходным кодом. Это справедливо для большинства «стеков» программного обеспечения, и весьма вероятно, что многие приложения на вашем телефоне были разработаны с его помощью. Фактически, если вы входите в число 2,5 миллиардов людей, использующих Android, операционная система вашего устройства основана на модифицированной версии ядра Linux — крупнейшего в мире проекта с открытым исходным кодом.

Как страстный геймер, я осознал, насколько глубоко взаимосвязаны наши любимые веб-продукты и услуги через так называемые «цепочки поставок программного обеспечения». Значительная часть этой кодовой базы построена из компонентов с открытым исходным кодом. Вездесущность открытого исходного кода принесла ему прозвище «критической инфраструктуры» Интернета, универсальной субстанции, необходимой и чрезвычайно мощной.

Несмотря на свою значимость, программное обеспечение с открытым исходным кодом — это концепция, незнакомая многим за пределами технологического сообщества. Фактически, значительное количество людей даже не были знакомы с этой концепцией.

Зачем использовать открытый исходный код?

Для тех, кто не знаком с этой концепцией, вот упрощенное описание: вместо закрытого или эксклюзивного программного обеспечения всем доступно бесплатное программное обеспечение с открытым исходным кодом (FOSS), позволяющее его изучать и модифицировать. Права на использование регулируются различными лицензионными соглашениями. Его отличает то, что его обслуживанием и обновлениями обычно занимаются волонтеры — бесплатные разработчики, которые посвящают свое личное время обеспечению функциональности и актуальности программного обеспечения.

Как страстный геймер и энтузиаст технологий, я бы сказал так: проекты с открытым исходным кодом могут возникать из разных отправных точек. Они могут стать скромным началом для авторов, которые просто хотят создать что-то инновационное в цифровой сфере. Со временем некоторые из этих проектов набирают обороты и становятся востребованными компонентами. Когда группы корпоративных разработчиков планируют разработать новое приложение, они часто предпочитают использовать обширную библиотеку уже существующих программных компонентов. Сегодня большинство этих компонентов созданы сообществом открытого исходного кода, что делает его важным центром для разработчиков игр, программистов и технологических новаторов.

Как большой поклонник технологий и их тонкостей, я могу сказать вам, что понимание сложного взаимодействия между коммерческим программным обеспечением и экосистемами с открытым исходным кодом может оказаться довольно сложной задачей. Однако несколько лет назад Рэндалл Манро, опытный художник веб-комиксов, придумал блестяще простой и юмористический способ проиллюстрировать эти, казалось бы, нелогичные отношения через свой ставший теперь культовым мем.

Кибербезопасность с открытым исходным кодом — это бомба замедленного действия

Компании часто выбирают решения с открытым исходным кодом, помимо финансовой выгоды от отсутствия затрат. Программное обеспечение с открытым исходным кодом (FOSS) позволяет разработчикам быстро и эффективно создавать приложения, предоставляя доступ к уже существующим основам кода. Это позволяет программистам сосредоточиться на улучшении рыночных аспектов своего программного обеспечения, а не перестраивать фундаментальные структуры с нуля. В быстро развивающихся отраслях, таких как Силиконовая долина, где быстрый выход на рынок имеет важное значение для сохранения конкурентоспособности, открытый исходный код становится незаменимым инструментом для DevOps.

Преимущества скорости и гибкости сопряжены с неизбежными рисками. Если свободное программное обеспечение с открытым исходным кодом (FOSS) является широко распространенным компонентом современного программного обеспечения, то в экосистеме существуют скрытые проблемы, которые подвергают огромное количество программного обеспечения значительной опасности. Эти проблемы могут быстро перерасти в сложные и серьезные затруднения, часто приводящие к катастрофическим последствиям.

Ошибки из ада

В эпизоде ​​XZ судьба благоволила нам, поскольку катастрофы удалось избежать, но это был узкий промах. В качестве примера можно привести печально известный инцидент с «log4shell», произошедший три года назад, в ноябре 2021 года. В этот период была обнаружена критическая ошибка в библиотеке журналирования с открытым исходным кодом под названием log4j, которая была чрезвычайно популярна в то время. Log4j, управляемый Apache, широко использовался и интегрировался в бесчисленное множество приложений по всему миру. Его использование было настолько широко распространено, что на момент обнаружения уязвимости оно присутствовало в миллионах приложений по всему миру.

К сожалению, уязвимость log4j, получившая название «log4shell», представляла собой серьезную угрозу. Подобно ошибке XZ, она позволяла удаленно выполнять код. Это позволило хакерам внедрить свой собственный вредоносный код в уязвимые программы, в конечном итоге взяв под контроль машины, на которых они работают. Учитывая широкое использование log4j, потенциальные последствия были огромными. Многочисленные громкие корпорации, стоимость которых исчисляется миллиардами, оказались под угрозой. По оценкам, около 500 миллионов устройств были признаны уязвимыми. После обнаружения ошибки специалисты по кибербезопасности предупредили, что она представляет серьезную угрозу и что злоумышленники активно ищут возможности ее использовать.

Как страстный любитель новостей о технологиях, я не могу не радоваться недавнему обнаружению ошибки, которая потрясла корпоративную Америку и вызвала волнения на самых высоких уровнях правительства. Это была не просто ошибка; это представляло значительную угрозу для некоторых крупнейших компаний мира, что делало его вопросом национальной безопасности.

После встречи высшие руководители Linux Foundation, в том числе Брайан Белендорф в качестве генерального менеджера OSSF, инициировали план по повышению безопасности всей экосистемы FOSS (свободного и открытого программного обеспечения). Одновременно федеральное правительство работало над новыми правилами для технологической отрасли. Примечательно, что в стратегии кибербезопасности президента Байдена, опубликованной в прошлом году, особое внимание уделяется нескольким новым мерам защиты, направленным на предотвращение появления разрушительных ошибок в программном обеспечении.

Несмотря на очевидные риски, связанные с уязвимостью XZ, важно признать, что бесплатное программное обеспечение с открытым исходным кодом (FOSS) по-прежнему подвержено критическим ошибкам на своих верхних эшелонах. Эти ошибки потенциально могут оказать разрушительное воздействие на Интернет в целом. Однако преодоление этих рисков в FOSS — непростая задача. Это требует углубления в тонкости отдельной экосистемы, которая генерирует огромное количество глобального программного обеспечения.

Закрытый исходный код не означает большую безопасность

Прежде чем двигаться дальше, важно прояснить распространенное заблуждение: маркировка «с закрытым исходным кодом» или проприетарная не делает программу автоматически более безопасной. На самом деле специалисты по безопасности и сторонники программного обеспечения с открытым исходным кодом утверждают, что часто верно обратное. Чтобы проиллюстрировать этот момент, я приведу вам пример с использованием Microsoft Corporation, известной корпорации с закрытым исходным кодом. Несмотря на видное положение Microsoft в отрасли, ее продукты неоднократно подвергались взлому, что в некоторых случаях приводило к значительному ущербу. Многие другие компании с закрытыми линейками продуктов имеют аналогичный опыт, и их уязвимости безопасности часто не раскрываются, поскольку только компания имеет доступ к коду. Мы вернемся к этой теме позже, а пока позвольте мне обратить ваше внимание на Microsoft в качестве примера.

Сопровождающие

Чтобы обсудить потенциальные угрозы безопасности в программном обеспечении с открытым исходным кодом, крайне важно сначала сосредоточиться на людях, ответственных за код. В сфере разработки с открытым исходным кодом таких людей обычно называют «сопровождающими». Их роль так же важна, как следует из названия: они контролируют обслуживание и поддерживают качество программного обеспечения.

Поддержание проекта с открытым исходным кодом предполагает важнейшую ответственность, аналогичную обязанностям строителей и инженеров в реальном мире. Они обеспечивают надежность и функциональность инфраструктуры проекта, а также разрабатывают новые функции, когда это необходимо. По сути, сопровождающие выступают в роли хранителей и создателей своих проектов, сотрудничая с участниками — пользователями, которые предлагают улучшения кодовой базы.

Как заядлый пользователь проектов с открытым исходным кодом, я не могу не восхищаться тем, как они оживают и развиваются с течением времени. Сердце этого динамичного процесса лежит на таких платформах, как GitHub, где сопровождающие любезно делятся своей работой со всем миром. Эти репозитории служат центральным узлом для совместной работы, предлагая интерактивные функции, которые позволяют сопровождающему находиться на месте водителя.

Роль сопровождающего, который является основным ответственным лицом, контролирующим динамичные проекты с открытым исходным кодом, включает в себя обширную рабочую нагрузку. Обязанности варьируются от управления ежедневным общением с пользователями и участниками, утверждения коммитов кода до создания обучающих материалов, разъясняющих внутреннюю работу программного обеспечения. Несмотря на значительные затраты времени, многие сопровождающие получают минимальную компенсацию или вообще не получают ее. Идея сообщества открытого исходного кода выступает за свободный доступ, а это означает, что сопровождающие в основном получают вознаграждение в виде удовлетворения от осознания того, что их код имеет значение.

Поддержание программного обеспечения с открытым исходным кодом представляет собой уникальную задачу, имеющую глубокие корни в его сложном прошлом и интригующую связь с корпорациями, которые используют его код.

Краткая история FOSS

На ранних этапах открытый исходный код не был тесно связан с корпорациями или финансовой выгодой. Вместо этого он представлял собой другой подход.

Движение «свободное и открытое программное обеспечение» (FOSS) возникло из идеалов движения «свободного программного обеспечения» 1980-х годов, возглавляемого Ричардом Столлманом. Столлман, неординарный учёный-компьютерщик с внешностью, похожей на Джерри Гарсию и твёрдой приверженностью кибернетическому идеализму, инициировал GNU в 1983 году в Лаборатории искусственного интеллекта Массачусетского технологического института. Целью проекта было создание коллекции свободно доступного программного обеспечения, поскольку Столлман выступал против идеи, что корпорации могут ограничивать доступ к своему программному обеспечению. Он считал, что пользователи должны иметь возможность понимать и изменять программы, которые они используют. По сути, концепция Столлмана «свободного» программного обеспечения относится к свободе использовать, изучать, изменять и распространять его — аналогично принципам свободы слова, а не раздачи.

Еще в 1991 году 21-летний финский студент-компьютерщик по имени Линус Торвальдс, обладавший талантом к программированию, обнаружил, что ищет интересный проект, который мог бы его занять. Мало ли мир знал, что это, казалось бы, обыденное занятие приведет к одной из самых революционных инноваций в истории открытого исходного кода. Заинтригованный этой задачей, Торвальдс приступил к разработке новой операционной системы и назвал ее своим именем, ласково назвав «Linux».

В 1998 году избранная группа сообщества свободного программного обеспечения решила дистанцироваться от его философских основ и ввести программное обеспечение в основной деловой мир. Ключевое собрание состоялось в Маунтин-Вью, штат Калифорния, на котором участники обсуждали стратегии ребрендинга свободного программного обеспечения как чего-то более привлекательного для корпораций. По словам Эрика Рэймонда, известного программиста и участника этой встречи, термин «открытый код» был введен в качестве маркетинговой стратегии. Его цель состояла в том, чтобы заменить двусмысленный и политически окрашенный термин «свободный» термином, который нашел отклик у лидеров американской технологической индустрии, сделав их более склонными к практичному ярлыку. Цель заключалась в том, чтобы отвлечься от идеологических основ свободного программного обеспечения и использовать открытый исходный код в качестве альтернативы.

Оказывается, они его купили. Это был пузырь доткомов, Силиконовая долина процветала, а частное предпринимательство жаждало новых способов получения прибыли. Многим предприятиям открытый исходный код, который представлял собой общий пул бесплатной рабочей силы и индустриальную модель инноваций, казался хорошей идеей. Таким образом, движение «открытого исходного кода» в значительной степени отделилось от движения «свободного» и превратилось в собственный, управляемый корпорациями организм, который со временем занимал все большее и большее пространство внутри индустрии программного обеспечения. Linux стал повсеместным, Торвальдс стал знаменитым, а Столлман в основном продолжал делать то, что делал всегда: отстаивать свои цифровые свободы и унижать гигантов корпоративного программного обеспечения. Сегодня мир живет на основе «открытого исходного кода», хотя Столлман по-прежнему категорически отвергает этот термин. Он по-прежнему предпочитает термин «свободное» программное обеспечение.

Код ни для чего

Как страстный геймер и энтузиаст открытого исходного кода, я воочию стал свидетелем того, насколько бесценным стало программное обеспечение с открытым исходным кодом для корпораций. Однако важно помнить, что за кулисами работают преданные своему делу разработчики, которые тратят бесчисленные часы на создание и поддержку этих проектов. К сожалению, они не всегда получают заслуженное признание или финансовую поддержку.

Ежегодный опрос разработчиков программного обеспечения с открытым исходным кодом, проводимый Tidelift в течение последних нескольких лет, неизменно выявлял аналогичную картину: эти люди часто перегружены, недооценены и утомлены своими усилиями. Поразительно, но согласно полученным данным, более половины разработчиков ПО с открытым исходным кодом не получили никакой компенсации за свой труд. В соответствии с этим, опрос Linux Foundation 2020 года показал, что около 51,65% участников попали в категорию неоплачиваемых.

Как преданный читатель технических новостей, я сталкивался с многочисленными случаями, когда термин «выгорание сопровождающего» использовался в связи с громкими инцидентами безопасности, такими как инцидент с XZ. В данном конкретном случае первоначальный сопровождающий проекта открыто признался, что чувствует себя перегруженным и не справляется со своими обязанностями. С тяжелым сердцем они в конце концов передали бразды правления программным обеспечением пользователю по имени Цзя Тан. К сожалению, именно этот пользователь впоследствии внедрил в программную составляющую бэкдор.

Сообщество открытого исходного кода неоднократно призывало бизнес вносить более значительный вклад в его экосистему. Однако этот призыв по большей части остался без ответа. Хотя это правда, что крупные технологические компании в последнее время инвестировали в определенные области открытого исходного кода — в первую очередь там, где такие инвестиции приносят им прямую выгоду.

Большое количество специалистов по программированию с открытым исходным кодом (FOSS) продолжают сталкиваться с проблемой поддержки проектов без особого финансового вознаграждения. Для многих речь идет больше о благодарности, чем об удовольствии или стабильном источнике дохода – думайте об этом как об экономике создателя, но с кодом. На Reddit ведутся многочисленные дискуссии среди разработчиков, изучающих способы финансирования своих проектов FOSS. Некоторые предлагают использовать Liberapay, краудфандинговую платформу с открытым исходным кодом, которая распределяет средства испытывающим финансовые затруднения разработчикам. Другие выступают за Patreon как жизнеспособный вариант. Один человек даже предлагает связаться с Gitcoin, стартапом Web3, который использует гранты на криптовалюту для спонсирования инициатив FOSS. Многие разработчики просто добавляют порталы для пожертвований на страницы своих проектов Github, ссылаясь на такие платформы, как Stripe, PayPal или Buy Me a Coffee. Как и в большинстве творческих занятий, получение финансовой поддержки часто является наиболее надежным способом получения дохода.

Кровотечение сердца

Подумайте о потенциальных рисках, связанных с управлением широко используемым программным обеспечением посредством пожертвований на таких платформах, как OnlyFans. Исследования показывают, что значительная часть коммерческих приложений включает элементы с открытым исходным кодом, которые больше не получают обслуживания или поддержки от своих первоначальных создателей.

Создание корпоративной цифровой инфраструктуры, опирающейся на децентрализованную и непредсказуемую рабочую силу, сопряжено со значительными рисками, о чем свидетельствует инцидент Heartbleed.

В 2014 году ошибка Heartbleed была обнаружена как основная слабость OpenSSL, широко используемого метода шифрования с открытым исходным кодом для безопасных веб-коммуникаций. В то время на него полагались такие известные организации, как Google, Facebook, Netflix и Yahoo, а также множество других приложений и сервисов, включая VPN, системы обмена мгновенными сообщениями и платформы электронной почты. Обнаружение того, что эта уязвимость позволяет злоумышленникам извлекать конфиденциальные данные, такие как имена пользователей и пароли, с уязвимых серверов, вызвало широкую тревогу в Интернете.

«Джон Каллас, эксперт по криптографии и инженер-программист, рассказал о смятении, вызванном открытием того, что широко используемая вещь поддерживается лишь несколькими людьми, которым даже не платят за свои усилия». (Каллас сам не был членом команды OpenSSL, но в то время участвовал в аналогичном проекте.)

Удивительно, как Каллас отметила, что затруднительное положение OpenSSL, похоже, связано с его сопровождающими. Как ни странно, позже выяснилось, что этим жизненно важным программным обеспечением, которому доверяют бесчисленные крупные корпорации для защиты своих служб конфиденциальности и безопасности, на самом деле управляла компактная команда, состоящая всего из одиннадцати человек. Среди них был «основной» квартет и всего один штатный сотрудник.

Каллас выразил обеспокоенность по поводу проблемы поддержки пакетов программного обеспечения с открытым исходным кодом, опираясь на свой опыт одного из архитекторов OpenPGP. Он признал, что этот вопрос важен из-за решающей роли, которую играют эти цифровые инфраструктуры.

Вера в безопасность открытого исходного кода, сформированная многолетней доктриной, заключалась в том, что прозрачный код делает FOSS более безопасным, чем проприетарное программное обеспечение. Причина заключалась в том, что бесчисленное количество глаз, изучающих открытый исходный код, привело к более быстрому выявлению и устранению уязвимостей. Однако ошибка Heartbleed выявила существенный недостаток в этой парадигме: даже при наличии прозрачности критические проблемы безопасности могли оставаться незамеченными в течение длительного времени.

В идеальном сценарии аргумент «больше глаз» подтверждает безопасность FOSS. Однако на самом деле проекты с открытым исходным кодом редко обладают обилием ресурсов или квалифицированными участниками. Напротив, они обычно сталкиваются с нехваткой того и другого. Следовательно, вместо того, чтобы получить выгоду от чрезмерного контроля, эти проекты могут оказаться недостаточно обеспеченными, что сделает их уязвимыми для потенциальных угроз. Более того, нередко на них бросают злонамеренный взгляд нежелательные элементы, например киберпреступники.

Бесспорно, значительное количество проектов свободного и открытого программного обеспечения (FOSS) могут похвастаться впечатляющим уровнем безопасности. Например, с 2005 года ядро ​​Linux было тщательно изучено примерно 14 000 участников. Linux Foundation, который курирует его разработку, насчитывает около 150 сотрудников и в прошлом году получил примерно 262,6 миллиона долларов дохода, большая часть которого поступила от корпоративных и частных пожертвований. . Эта надежная поддержка и прозрачность позволили обнаружить проблемы безопасности, такие как уязвимость XZ, созданная Цзя Таном. Однако использование Linux в качестве эталона безопасности с открытым исходным кодом сопряжено с явным предостережением: подавляющее большинство проектов FOSS не пользуются таким же уровнем ресурсов и контроля, как Linux.

Коллекция ножей предателя

Как страстный геймер и энтузиаст технологий, я помню, когда случился Heartbleed — это был пугающий момент для всего сообщества разработчиков программного обеспечения. Это было похоже на сигнал тревоги, прозвучавший глубокой ночью, заставивший нас всех сесть и обратить внимание. Корпоративная Америка была в блаженном неведении о потенциальных рисках безопасности, скрывающихся в проектах с открытым исходным кодом, но этот инцидент изменил все. Внезапно безопасность открытого исходного кода стала главным приоритетом и впервые потребовала нашего коллективного внимания.

Как обеспокоенный наблюдатель за цифровым миром, я не могу не задуматься о том, как Heartbleed, серьезная уязвимость безопасности, обнаруженная в 2014 году, не вызвала немедленной реакции со стороны всех. Оглядываясь назад, можно сказать, что это послужило зловещим предупредительным знаком о том, что нас ждет в нашем все более сложном цифровом мире. Программное обеспечение с открытым исходным кодом (FOSS) с тех пор стало более распространенным и важным в сети, расширяя сферу потенциальных угроз за пределы случайных серьезных ошибок. Сегодня мы сталкиваемся с множеством сложных проблем, выходящих за рамки простых уязвимостей.

В современном развитом обществе программное обеспечение стало неотъемлемой частью нашей жизни, и его можно найти в различных коммерческих продуктах, начиная от бытовой техники и заканчивая оборудованием для фитнеса и предметами личной гигиены, причем все они поставляются с сопутствующими приложениями. Следовательно, вероятность взлома этих программных приложений значительно возросла. Растущую озабоченность вызывают атаки на цепочки поставок программного обеспечения, которые нацелены на уязвимые компоненты с целью получения доступа и компрометации целых продуктов или систем. Эти недостатки часто встречаются в компонентах программного обеспечения с открытым исходным кодом, что делает их привлекательной мишенью для киберпреступников. Множество способов использования этих уязвимостей в цепочках поставок программного обеспечения с открытым исходным кодом заслужили зловещее название «коллекция ножей предателя» в известной статье 2020 года.

Дэн Лоренц — человек с обширными знаниями о сложных ландшафтах угроз. Опытный эксперт по безопасности с опытом работы в области свободного и открытого программного обеспечения (FOSS), Лоренц ранее почти десять лет посвятил Google и более трех лет специально занимался кибербезопасностью для Google Cloud. В настоящее время Лоренц возглавляет Chainguard, компанию, специализирующуюся на безопасности цепочек поставок, занимающуюся решением аналогичных проблем, возникших во время его работы в Google.

Как энтузиаст открытого исходного кода, я начал ценить его дух сотрудничества и свободу, которую он предлагает. Однако я должен признать, что его децентрализованное развитие сопряжено с определенными проблемами. Поскольку любой пользователь сети может внести свой вклад в базу кода, важно помнить, что не у всех есть благие намерения.

К сожалению, эпизод XZ — это лишь один из многих случаев, когда проект свободного и открытого программного обеспечения (FOSS) был скомпрометирован сопровождающим или участником, внедрившим вредоносный код. Исследование, опубликованное в 2020 году, показало, что около 17% ошибок, обнаруженных в проектах FOSS, были вставлены злонамеренно, что исследователи назвали «Bugdoors». Яркий пример этого произошел еще в 2018 году, когда разработчик широко используемой программы с открытым исходным кодом под названием event-stream решил передать управление другому пользователю по имени Right9ctrl. Однако позже выяснилось, что Right9ctrl на самом деле был киберпреступником. Получив контроль, преступник внедрил в программное обеспечение вредоносный код, который позволил несанкционированный доступ к определенным криптовалютным кошелькам и привел к значительным финансовым потерям. Вредоносное обновление, скачанное более 8 миллионов раз, оставалось незамеченным около двух месяцев.

Число разработчиков открытого исходного кода, намеренно наносящих ущерб собственным проектам, значительно выросло. В октябре 2021 года сопровождающий широко используемой коллекции библиотек npm Марак Сквайрс неожиданно уничтожил их с помощью серии загадочных обновлений. Эти обновления привели к бессмысленным результатам, которые сделали бесполезным любое программное обеспечение, функциональность которого зависит от этих библиотек. Считается, что в результате этого разрушительного акта пострадали около тысячи программных проектов.

Лоренц отметил, что, вероятно, в критических системах существует множество игнорируемых проектов «log4j», которые требуют большего внимания и внимания. По его словам, этот вопрос возникает «довольно часто».

Когда в корпоративных проектах, использующих решения с открытым исходным кодом, возникают проблемы, ответственность часто перекладывается на сопровождающих. Общественность может их критиковать, подразумевая, что «они плохо выполняют свою работу или уделяют ей недостаточно времени» (Лоренц). Однако это сложный вопрос. Специалисты по сопровождению выпускают эти инструменты для бесплатного использования, и впоследствии пользователи создают на их основе значительную производственную инфраструктуру. Позже они выражают недовольство, когда обнаруживаются ошибки.

Инвентаризация

Как нам управлять технологически развитой сферой, характеризующейся фундаментальной рассредоточенной природой, повсеместной псевдонимностью и встроенным иммунитетом к регулированию сверху вниз?

Этот вопрос не дает спать по ночам многим людям. В разное время после краха log4j я обращался к руководителям OpenSSF, дочерней компании Linux по безопасности, чтобы обсудить ход реализации «плана мобилизации», который, если вы помните, был составлен для создания новых средств защиты среды FOSS. после обнаружения ошибки log4shell. Первоначально предложенный план включал в себя множество движущихся частей, и было не совсем ясно, какие из них будут приоритетными. В 2022 году я разговаривал с управляющим директором OpenSSF Брайаном Белендорфом, который сказал мне, что в плане мобилизации есть как минимум пара предложений, готовых к действию — те, которые он назвал «готовыми к работе». Одно из самых многообещающих решений одновременно и самое очевидное: заставить компании провести инвентаризацию используемого ими кода.

Не правда ли, весьма удивительно, что многие организации не ведут инвентаризацию своих программных активов или имеют ограниченную информацию о компонентах программного обеспечения, которое они используют? Фонд открытого программного обеспечения указал на эту проблему, заявив, что «фирмам часто не хватает знаний о программном обеспечении, которое они используют». Эта ситуация не очень привлекательна, вы согласны? Это похоже на то, как строительная компания строит небоскреб, не зная состава его фундамента. Разве вы не предпочли бы работать или жить в здании, структурная целостность которого известна и надежна?

Кибербезопасность с открытым исходным кодом — это бомба замедленного действия

В плане мобилизации рекомендовалось использовать сторонние проверки кода, также называемые в отрасли «спецификациями программного обеспечения» (SBOM). SBOM составляют список программных компонентов, используемых в конкретной программе, с использованием алгоритмов. Раскрывая содержимое программного обеспечения, SBOM позволяют поставщикам программного обеспечения оценить, содержат ли эти элементы уязвимости безопасности или нет.

«Думайте об этом как о списке компонентов, похожем на список ингредиентов на упаковке продуктов питания», — предложил Тим Макки из Synopsys, одного из поставщиков услуг SBOM. «Спецификация программного обеспечения предназначена для того, чтобы предоставить вам информацию о том, что включено и его происхождение».

SBOM (спецификация программного обеспечения) используются уже много лет, в первую очередь для того, чтобы помочь компаниям определить юридические риски, связанные с программными компонентами с открытым исходным кодом в их кодовых базах. Учитывая сложную сеть лицензионных соглашений, регулирующих использование открытого исходного кода, компаниям важно понимать, какие компоненты присутствуют в их кодовой базе, чтобы знать, какие соглашения применяются, и избегать потенциальных судебных исков.

Начиная с мая 2021 года администрация Байдена издала указ, требующий от поставщиков программного обеспечения, заключивших контракт с федеральным правительством, использовать спецификации программного обеспечения (SBOM). По словам Макки, этот мандат вызвал значительный интерес и рост в отрасли. «С тех пор бизнес значительно расширился», — с энтузиазмом поделился он.

Хотя спецификации программного обеспечения (SBOM) представляют собой прогресс в решении проблем безопасности, связанных с программным обеспечением с открытым исходным кодом (FOSS), они не решают фундаментальных проблем. По сути, SBOM просто служат точной записью компонентов с открытым исходным кодом, используемых в проекте. Как выразился бывший разработчик Google Дэн Лоренц: «Они не волшебные пули; они не исправляют автоматически ошибки и не предотвращают появление новых. Они просто предоставляют ценную информацию о ваших зависимостях». Удивительно, что многим организациям до сих пор не хватает этой фундаментальной инвентаризации активов.

Кори Доктороу, влиятельная фигура в движении за открытый исходный код, утверждает, что в настоящее время у компаний нет мотивации создавать безопасное программное обеспечение. Когда нарушения происходят в цепочках поставок, разработчиков программного обеспечения с открытым исходным кодом часто привлекают к ответственности, но на самом деле ответственность несут компании, использующие код. Доктороу утверждает, что в этом сценарии фирмы не только не обязаны обеспечивать качество своего программного обеспечения и предлагать поддержку разработчикам, но и добровольцы, которые пытаются предупредить компании и их клиентов об уязвимостях, могут быть подавлены, если компании воспринимают такие действия как нанесение ущерба их обществу. изображение. В некоторых случаях технологические компании даже прибегают к судебным искам против исследователей безопасности, стремящихся раскрыть ошибки в своих продуктах.

Отсутствие действий компаний по обеспечению безопасности программного обеспечения ложится значительным бременем на отдельных разработчиков и группы разработчиков открытого исходного кода, такие как Linux Foundation. Примечательно, что эти организации активно решают проблемы безопасности, создаваемые FOSS, посредством инновационных решений. За последние несколько лет они предприняли различные шаги, в том числе выступили за принятие спецификации программного обеспечения (SBOM) и запустили множество инициатив по обеспечению безопасности. Некоторые из этих программ включают создание механизмов отслеживания бесплатного программного обеспечения, таких как GUAC, который позволяет разработчикам выявлять потенциально опасные компоненты в своей кодовой базе. Еще одна инициатива — Sigstore, система криптографической подписи, предназначенная для проверки подлинности программного обеспечения разработчиков.

Если эти инициативы окажутся эффективными, важно признать, что они происходят на фоне растущих угроз со стороны атак на цепочки поставок, постоянной усталости специалистов по сопровождению и ощущения, что безопасность с открытым исходным кодом не значительно продвинулась со времени инцидента с log4j. Некоторые считают, что только комплексная модернизация системы может защитить Интернет. Мэтью Ходжсон, один из соучредителей Matrix, протокола безопасной связи, предложил рассматривать программное обеспечение с открытым исходным кодом (FOSS) как финансируемую государством утилиту, аналогичную физической инфраструктуре в Соединенных Штатах, получающую постоянное федеральное финансирование и поддержку. .

Понятно, что перспектива достижения таких драматических изменений в экосистеме с открытым исходным кодом может показаться непреодолимой проблемой, оставляя тех, кто этим занимается, с ощущением, что они застряли в бесконечном цикле, подобно тому, как Сизиф толкает свой валун в гору. . С прошлого года Брайан Белендорф перешел на другую должность в Linux Foundation, передав ответственность за безопасность Омхару Арасаратнаму, который в настоящее время занимает должность генерального менеджера OpenSSF. Арасаратнам видит свою роль в «обеспечении безопасности Интернета», задачу, которую он признает «чрезвычайно сложной». Более точное описание могло бы быть «недостижимым». Тем не менее, несмотря на признание того, что простых решений не существует, Арасаратнам сохраняет оптимизм из-за значимости результата. «Если нам удастся сделать это правильно, — говорит он, — мы сможем изменить жизнь более 8 миллиардов человек».

Смотрите также

2024-05-08 15:02