Хотя в прошлом сообщество OSS произвело фурор, сообщая об уязвимостях, широкое использование библиотеки журналирования Java с открытым исходным кодом Log4j означало, что, когда эта уязвимость была обнаружена, шлюзы открылись. Почти за одну ночь открытый исходный код превратился из разговора, предназначенного для глубин каналов Discord, в то, о чем ваша мама могла бы спросить вас за завтраком.
Это возобновление внимания подчеркнуло решающую взаимосвязь между программными компонентами с открытым и закрытым исходным кодом, что привело к возникновению многих неправильных представлений о сообществе открытого исходного кода. Брайан Фокс
Навигация по социальным ссылкам
Здесь не час самодеятельности
Из-за резкого внимания к уязвимости Log4Shell возникло серьезное недопонимание, что, поскольку открытый исходный код был «бесплатным», это сообщество состояло в основном из любителей. Это предположение очень далеко от истины. Разработчики ПО с открытым исходным кодом являются одними из самых преданных своему делу и знающих программистов в мире. Некоторое программное обеспечение с открытым исходным кодом настолько сложно, что для его создания требуются настоящие ученые-ракетчики. Без высококвалифицированных экспертов по открытым исходным кодам мы бы никогда не увидели такие проекты, как F Prime Лаборатории реактивного движения, который лежит в основе архитектуры полетов для миссий на Марс.
Это предположение также противоречит одному из определяющих аспектов сообщества открытого исходного кода: его энтузиазму. Разработчики открытого исходного кода часто присоединяются к сообществу, потому что они могут работать над проектами с большей отдачей, чем позволяет их обычная работа, оставляя после себя неизгладимое наследие.
Работу сообщества открытого исходного кода невозможно переоценить; большая часть Интернета работает на основе разработки с открытым исходным кодом.
Однако важность работы разработчиков открытого исходного кода признается теми, кто осознает свою зависимость от этих вкладов. Многие работодатели нанимают разработчиков ПО с открытым исходным кодом специально для того, чтобы они поддерживали элемент с открытым исходным кодом, необходимый для их ИТ-инфраструктуры.
Помимо неправильной характеристики сообщества, одним из преимуществ привлечения внимания к открытому исходному коду было то, что часть этого света просачивалась в цепочку поставок программного обеспечения в целом. По мере того, как все больше людей начали обращать внимание на цепочку поставок программного обеспечения, на первый план вышло растущее обсуждение стандартов разработки, а также ответственности.
Подпишитесь на информационный бюллетень Ny Breaking и получайте все лучшие новости, мнения, функции и рекомендации, необходимые вашему бизнесу для успеха! Голова тяжелая
Новый акцент на целостности цепочки поставок означал новый акцент на подотчетности. Кто отвечает за безопасность открытого исходного кода? Кто виноват, если будут обнаружены уязвимости? Кто контролирует раскрытие информации? На эти вопросы нет однозначного ответа, кроме «всех». Это означает тех, кто разрабатывает программное обеспечение, использующее компоненты OSS, тех, кто распространяет программное обеспечение, использующее эти компоненты, и всех, кто использует технологии, использующие эти компоненты.
Реальность такова, что, хотя весь код содержит уязвимости, разработчики с открытым исходным кодом, как правило, невероятно эффективно устраняют эти уязвимости. Фактически, данные Sonatype показали, что 96% загруженных компонентов OSS с уязвимостью уже имеют исправление.
Несмотря на эти усилия сообщества OSS, риск существует. Использование компонентов с открытым исходным кодом означает, что вы принимаете на себя ответственность за этот риск. Любой разработчик, использующий элементы с открытым исходным кодом, должен понимать, что это за элемент, откуда он берется и какой риск он может представлять для целостности его программного обеспечения. Этот принцип стал еще более важным, поскольку цепочки поставок программного обеспечения стали более переплетенными и сложными.
Однако важно отметить, что этот уровень риска не следует воспринимать как компромисс при использовании компонентов OSS. Существуют методы, которые разработчики должны использовать для ограничения уровня риска, с которым они сталкиваются.
Однако для этого требуется правильный инструмент; Постоянно растущее число обнаруженных, эксплуатируемых, раскрытых и исправленных уязвимостей делает невозможным отслеживание вручную контекста, в котором они могут быть использованы, и невозможности быстрого обновления. Особенно учитывая множество компонентов и проектов, над которыми работают команды.
Единственный способ узнать, где находятся дыры в вашем ограждении, — это узнать, насколько оно велико. Тот же принцип применим и к программному обеспечению, где спецификация программного обеспечения (SBOM) является решающим шагом в оценке общей уязвимости вашей компании. Простого наличия этой информации недостаточно для защиты вашего бизнеса, но она требует действий. Медленно — это плавно, а плавно — это быстро
Широко распространенный миф, связанный с кибербезопасностью, заключается в том, что придание приоритета безопасности замедляет развитие. Этот миф существовал некоторое время. Мы даже исследовали это в 2021 году и обнаружили, что лучшие результаты были быстрее, чем те, кто сосредоточился исключительно на скорости, и безопаснее, чем те, кто сосредоточился исключительно на безопасности. Это подтверждает, что вполне возможно сделать и то, и другое.
Это может показаться нелогичным, пока вы не остановитесь и не задумаетесь об этом. Компании, которые фокусируются исключительно на скорости, не могут позволить себе роскошь игнорировать проблемы в масштабе Log4Shell.. Им еще предстоит решать эти проблемы, но они к этому абсолютно не готовы. Это приводит к незапланированной работе, немедленному техническому долгу и множеству других проблем, на решение которых потребуется дополнительное время. Это абсолютный убийца производительности.
Организации, которые признают, что более высокая безопасность означает, что команды будут работать медленнее, часто игнорируют возможности для инноваций и повышения скорости. Они приняли то, что считают реалистичными затратами, и отвергли возможность того и другого. Дело закрыто
Важным моментом здесь является не то, что открытый исходный код по своей сути опасен, и даже не то, что следует принимать определенные уровни риска. Скорее, сообщество открытого исходного кода состоит из невероятно талантливой и преданной своему делу группы людей. Проекты, которыми они делятся, составляют основу многих технологий, которые мы используем каждый день. Разработчикам необходимо полностью понимать каждый элемент продуктов, которые они создают, и с помощью автоматизации они могут сделать именно это. Скорость и безопасность не являются противоположными подходами; они могут прекрасно сосуществовать. Приняв эту точку зрения, организации могут уверенно ориентироваться в среде открытого исходного кода, укрепляя свою политику безопасности, сохраняя при этом эффективность и гибкость в разработке программного обеспечения. Мы порекомендовали лучшее программное обеспечение для шифрования.
Эта статья была подготовлена в рамках канала Expert Insights от Ny BreakingPro, где мы рассказываем о лучших и ярких умах современной технологической индустрии. Мнения, выраженные здесь, принадлежат автору и не обязательно совпадают с мнением Ny BreakingPro или Future plc. Если вы заинтересованы в участии, вы можете прочитать больше здесь: https://www.techradar.com/news/submit-your-story-to-techradar-pro.
Статья добавлена ботом, с использованием машинного перевода : https://nybreaking.com/category/tech/
