-
Похожий контент
-
Автор KL FC Bot
Как мы уже писали в одном из предыдущих постов, современная разработка практически немыслима без использования компонентов open source. Но в последние годы связанные с этим риски становятся все разнообразнее, сложнее и многочисленней. Когда уязвимости появляются в инфраструктуре и ПО компании быстрее, чем их устраняют, данные неточны и неполны, а в популярных компонентах может таиться вредоносное ПО, недостаточно только сканировать версии компонентов и создавать задачи для ИТ по устранению. Нужно расширить процесс управления уязвимостями, охватив им политики скачивания ПО, правила работы ИИ-ассистентов и процесс сборки ПО.
Доверенный пул компонентов open source
Фундаментальная часть решения — предотвратить использование уязвимого и вредоносного кода. Для этого имеет смысл реализовать следующие меры:
Внутренний репозиторий артефактов. Единственным источником компонентов для внутренней разработки должен быть единый репозиторий, компоненты в который попадают только после серии проверок. Тщательный скрининг компонентов. Среди необходимых проверок: известные версии компонента, известные уязвимые и вредоносные версии, дата публикации, история активности, репутация пакета и авторов. Обязательно сканировать все содержимое пакета, включая инструкции по сборке, тест-кейсы и другие вспомогательные данные. Для фильтрации реестра при его наполнении должны использоваться специализированные решения для сканирования open source или комплексное решение для безопасности облачных нагрузок. Закрепление зависимостей. Процессы сборки, ИИ-инструменты и разработчики не должны использовать шаблоны при указании версий (например, latest). Сборка проекта должна идти на основе проверенной версии. При этом закрепленные зависимости должны регулярно обновляться до последней, но проверенной версии, которая сохраняет совместимость и лишена известных уязвимостей. Это значительно снижает риск атак на цепочку поставок через компрометацию известного пакета.
View the full article
-
Автор KL FC Bot
В прошлом только специализированные компании по разработке ПО и очень крупные бизнесы должны были заботиться об уязвимостях в цепочке поставок и открытом исходном коде (open source). Но сегодня даже небольшие компании имеют собственную разработку, и проблема становится актуальной и для них. Даже когда основное направление бизнеса вообще не связано с «софтом», в каждой второй компании внутренние команды ИТ пишут код, настраивают интеграции и автоматизируют бизнес-процессы. Этого требует эффективность бизнеса. Но в результате организация сталкивается с новыми видами уязвимостей в ПО, найти и устранить которые гораздо сложнее, чем просто скачать обновление Windows.
Современная разработка активно, неизбежно использует компоненты open source. Но связанные с этим риски стали в последние годы разнообразнее, сложнее и многочисленней. Это вредоносный код в популярных репозиториях, неполная и неточная информация о программных уязвимостях, систематическое использование устаревших, уязвимых компонентов и нарастающая сложность оценки цепочки зависимостей.
Дефицит данных об уязвимостях open source
Даже если в организации хорошо налажено управление уязвимостями в готовом ПО, для open source процесс придется значительно перерабатывать и дополнять. Публичные, наиболее популярные источники информации об уязвимостях часто неполны, неточны и пополняются поздно в части, касающейся ПО с открытым исходным кодом. В результате приоритизация уязвимостей превращается в гадание, и никакая автоматизация здесь помочь не способна, пока не будут устранены пробелы в базовой информации.
Например, по данным Sonatype, около 65% open-source-уязвимостей, получивших идентификатор CVE, не имеют оценки критичности (CVSS) в наиболее популярной базе уязвимостей NVD. Из этих уязвимостей 46% получили бы высокую оценку критичности.
View the full article
-
Автор KL FC Bot
Согласно исследованию State of Open Source Report, проведенному компанией OpenLogic, 96% опрошенных организаций используют решения с открытым исходным кодом. Решения open source (OSS) есть в любом сегменте ИТ-рынка, в том числе и среди средств для обеспечения информационной безопасности. Нередко их рекомендуют для построения систем SIEM.
При поверхностном анализе кажется, что это отличный выбор. Основная функция SIEM — систематизированный сбор и корреляция телеметрии, которые можно организовать на хорошо известных инструментах хранения и обработки данных. Собрали все данные через Logstash, прикрутили поиск Elasticsearch, построили нужные визуализации в Kibana — и готово! Три секунды поиска позволяют найти и готовые решения для SIEM (часто собранные на тех же компонентах) — от Wazuh до Security Onion. В SIEM всегда важно адаптировать сбор и обработку данных к реалиям организации — и собственная OSS-система предлагает для этого бесконечные возможности. Причем стоимость лицензии равна нулю. Но успех этого предприятия решающим образом зависит от состава команды разработчиков, особенностей организации и того, насколько долго она готова ждать результата и тратиться на поддержку в дальнейшем.
Время — деньги
Ключевой вопрос, важность которого постоянно недооценивается, — сколько времени пройдет, пока SIEM в компании не просто заработает, а начнет приносить пользу. По данным Gartner, даже готовую полнофункциональную SIEM полноценно внедряют в среднем полгода, а каждая десятая компания тратит на это год.
С собственной разработкой или адаптацией одной из OSS SIEM это время надо умножать на два-три (пессимистам — на десять), а для расчетов бюджета — умножать это время на стоимость разработчиков. При этом сложно представить себе, что полноценная SIEM-система будет поддерживаться талантливым одиночкой — компании придется содержать целую команду.
Опасной психологической ловушкой является быстрое появление прототипа. Развернуть в тестовой среде готовое OSS-решение можно за считаные дни, но вот его доводка до промышленной эксплуатации может занять многие месяцы и даже годы.
View the full article
-
Автор KL FC Bot
Приложения с открытым исходным кодом используются уже в 96% компаний. Широкий выбор, возможность доработок и нулевая стоимость лицензии очень привлекательны, но более половины фирм, опрошенных в рамках отчета 2025 State of Open Source, испытывают серьезные проблемы с их сопровождением. 63% не успевают обновлять решение и применять патчи, немногим меньше проблем с кибербезопасностью, регуляторным соответствием и наличием open-source-софта с истекшим сроком службы (EOL, более неподдерживаемым). Как минимизировать вероятность возникновения этих проблем и куда смотреть еще на этапе выбора open-source-приложения для внедрения?
Обновления и патчи
Поскольку своевременные обновления — самая широко распространенная проблема, смотреть на приложение-кандидата с этой точки зрения нужно особенно внимательно. Прямо в публичном репозитории приложения несложно проверить частоту и масштабность обновлений, а также их состав. Обращать внимание нужно на то, насколько хорошо задокументированы обновления; какого рода проблемы в них решаются и какие функции добавляются; часты ли ситуации, когда следом за выходом новой версии через несколько дней или недель выходят мелкие фиксы; насколько быстро закрываются запросы, связанные с устранением ошибок?
Ответить на эти вопросы помогут стандартные инструменты вроде GitHub Insights, а также вспомогательные сервисы, например Is it maintained, Repology, Libraries.io. Последний сразу отображает, какие устаревшие зависимости используются в текущей версии.
Отдельное внимание стоит уделять обновлениям, связанным с безопасностью. Выходят они отдельным треком или их выпускают вместе с функциональными обновлениями? Как правило, разработчики идут по второму пути, и тогда надо разобраться, долго ли обновления безопасности ждали своего выпуска.
Также надо оценить, насколько сложна установка обновлений. Для этого недостаточно официальной документации и помощи (хотя с ее изучения можно начать). Но тут скорее поможет внимательное изучение отзывов в сообществах пользователей.
View the full article
-
Автор Rgn
Добрый день
после ecnfyjdrb антивирус на MacOS через каждые 30 минут начинает отключаться wifi,
подскажите с чем возникнуть данная проблема ?
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти