«Есть ли у нас уязвимости?» Что нужно знать директорам по информационной безопасности (CISO) о рисках своего программного обеспечения

Источник: JFrog•

«Есть ли у нас уязвимости?» Что нужно знать директорам по информационной безопасности (CISO) о рисках своего программного обеспечения

Когда критические уязвимости поражают Curl, PHP или LiteLLM, можете ли вы ответить на вопрос: «Есть ли у нас уязвимости?» Узнайте, как CISO оценивают видимость и риски цепочки поставок программного обеспечения.

Недавние события в очередной раз подчеркнули необходимость быстро отвечать на вопрос: «Есть ли у нас уязвимости?»

Теперь мы сталкиваемся с угрозами для бизнеса и государственных структур, исходящими от уязвимостей и компрометаций в трех фундаментальных компонентах, используемых при разработке программного обеспечения: Curl, PHP и LiteLLM.

Curl

Когда речь заходит о Curl и его базовой библиотеке передачи данных libcurl, угроза может затронуть самую основу передачи данных в интернете. Поскольку libcurl встроена во многие корпоративные среды — от бэкенд-микросервисов и сред выполнения контейнеров до автоматизированных конвейеров CI/CD и скриптов оболочки, эта уязвимость несет в себе потенциальный системный риск. Основная угроза сосредоточена вокруг серьезных изъянов, раскрытых в октябре 2026 года, в частности проблемы использования памяти после освобождения (use-after-free) в HTTP/2 (например, CVE-2026-92392), когда вредоносный вышестоящий сервер, обрабатывающий выгрузку, может повредить память на стороне клиента и при определенных условиях вызвать удаленное выполнение кода или сбой приложения на машине, инициирующей передачу. Поскольку libcurl по умолчанию согласовывает HTTP/2 для URL-адресов HTTPS, если сервер поддерживает это, а приложения редко проверяют, что libcurl делает «под капотом», стеки разработки и автоматизированные конвейеры развертывания, которые не были обновлены до исправленной версии, могут оставаться уязвимыми перед враждебными внешними конечными точками.

LiteLLM

Что касается LiteLLM, то исследовательская группа JFrog Security Research обнаружила проблему в течение 2 часов, и ошибочный пакет LiteLLM версии 1.107.0 уже был удален из PyPI. Демонстрируя непрерывно улучшающуюся зрелость экосистемы сообщества открытого исходного кода, сопровождающие пакеты уже опубликовали отчет. Но в период с 11:39 до 13:23 по всемирному координированному времени (UTC) 21 октября 2026 года разработчики программного обеспечения, автономные агенты или ваши сборочные системы могли загрузить этот пакет из PyPI, а затронутые образы Docker оставались доступными до 14:20 UTC. Эффект домино от попадания скомпрометированного пакета или уязвимого компонента в среду затрагивает не только разработчиков или команду безопасности. Он также влияет на ИТ-операции и, в конечном итоге, на аудиторов. Каждое изменение затрагивает всю организацию. Руководителям, лицам, принимающим бизнес-решения, которые определяют, куда инвестировать и как распределять ресурсы, нужен способ понять, каков их уровень этой зрелости. Есть ли у них полная видимость или нет?

PHP

В случае с PHP две уязвимости якорного уровня КРИТИЧЕСКОЙ степени тяжести в ядре PHP (CVE-2026-109618, CVE-2026-109619) были обнародованы и получили общее название PHP2Shell. Согласно публичным рекомендациям, эти ошибки могут разрешить неаутентифицированное удаленное выполнение кода и раскрытие памяти в стиле Heartbleed непосредственно в самом PHP, независимо от работающего поверх него приложения. В течение нескольких дней новостные агентства сообщили об уязвимостях, а Агентство по кибербезопасности и защите инфраструктуры США (CISA) выпустило предупреждение с призывом к организациям немедленно установить исправления, включая CNBC и BBC, CISA.

«Есть ли у нас уязвимости?»

Когда CISO размышляет над вопросом «Есть ли у нас уязвимости?», его процесс триажа должен быть сосредоточен на следующих ключевых проблемах:

  • Действительно ли это угроза?
  • Где это используется?
  • Каково влияние на бизнес?
  • Есть ли у меня обязательства по отчетности или раскрытию информации в соответствии с правилами или стандартами, применимыми к моей организации, такими как требования Комиссии по ценным бумагам и биржам США (SEC), стандарта PCI DSS или, для производителей продукции, Закона ЕС о киберустойчивости (CRA)?
  • Заблокировали ли мы это?
  • Как это исправить?

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

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

Практический опыт проведения оценки

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

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

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

Оценка зрелости безопасности от JFrog

Основываясь на опыте работы JFrog со многими клиентами из списка Fortune 100 и благодаря экспертизе нашей собственной команды исследователей безопасности, мы создали собственную оценку зрелости безопасности. Она позволяет организациям самостоятельно оценить зрелость своей программы безопасности цепочки поставок программного обеспечения по 11 доменам на основе их ответов.

Я настоятельно рекомендую уделить несколько минут вашего напряженного дня заполнению этой анкеты, так как она оценивает сильные и слабые стороны, возможности и риски в ваших операциях по разработке программного обеспечения и может помочь вам определить, с чего начать, когда речь идет о том, чтобы действительно ответить на вопрос: «Есть ли у нас уязвимости?»

Основные выводы

Вопрос «Есть ли у нас уязвимости?» может оказаться сложным и трудным для оценки, но недавние громкие инциденты безопасности не дают CISO роскоши тратить дни на подготовку ответа. Корпоративным руководителям и членам совета директоров нужны быстрые и точные ответы.

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

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

О чём эта статья

Ещё в разделе «Разработка ПО»

Все →

Ещё от JFrog