Спрос на управление уязвимостями вырос на 30%, но с внедрением туго

Спрос на управление уязвимостями вырос на 30%, но с внедрением туго

Спрос на управление уязвимостями вырос на 30%, но с внедрением туго

В первом квартале 2025 года интерес российских компаний к управлению уязвимостями (Vulnerability Management, VM) заметно вырос — спрос на решения и услуги в этой сфере увеличился на 30% по сравнению с тем же периодом прошлого года.

По словам специалистов «Информзащиты», основными причинами роста стали увеличение числа уязвимостей (включая так называемые n-day — те, для которых уже есть патчи, но они ещё не установлены) и нехватка системного подхода к их устранению.

По оценке компании, после завершения пентестов в организациях остаётся неустранёнными более 40% уязвимостей, а в отдельных отраслях — до 70%. Хотя своевременная ремедиация может снизить риск успешной атаки почти на треть, многие компании откладывают установку обновлений на месяцы — не из-за технических ограничений, а из-за отсутствия выстроенного процесса.

Как отмечает Кирилл Дёмин, руководитель отдела систем мониторинга в IZ:SOC «Информзащиты», часто бывает так, что в компании нет выделенного VM-специалиста, и задача «зашивается» под SOC — команду, которая и без того загружена инцидентами и расследованиями. Но SOC не всегда имеет нужные полномочия и инструменты, чтобы системно закрывать уязвимости. В итоге — проблема остаётся нерешённой.

Ещё один тормоз — конфликты с ИТ-департаментами. Многие ИТ-руководители не готовы ставить патчи вне регламентных окон, опасаясь, что это повлияет на стабильность бизнес-приложений. По данным компании, таких — до 60%.

Одним из возможных решений эксперты называют создание отдельного подразделения — Vulnerability Operations Center (VOC). Это команда, которая занимается уязвимостями от начала до конца: от сканирования и оценки риска до контроля за тем, чтобы проблема действительно была устранена.

В такой центр входят разные специалисты: аналитики, инженеры по сканированию и внешним поверхностям, патч-менеджеры, специалисты по харднингу, BAS-эксперты и координаторы, работающие с ИТ и SOC. Всё это помогает распределить задачи и встраивать процессы VM в общую инфраструктуру компании.

Пока VOC в России — скорее концепция, чем массовое решение. Не каждая компания готова создавать отдельную команду или нанимать профильного специалиста. Тем не менее, интерес к этой модели растёт: появляются специализированные сервисы, которые берут на себя отдельные части процесса и фактически приближают компании к VOC-подходу. Понимание того, что управление уязвимостями — это не угроза стабильности, а её основа, становится всё более распространённым.

Зачем Яндекс Go создал отдельный язык для расчёта стоимости поездок

Цена поездки в Яндекс Go — это не расстояние, умноженное на минуты и километры. В расчёт вмешиваются геозоны, спрос, скидки, платные дороги, дополнительные остановки и требования вроде перевозки кота, велосипеда или лыж. Чтобы управлять этим хозяйством без бесконечных деплоев, разработчики вынесли алгоритм ценообразования из кода сервиса в собственный язык.

Как объяснили разработчики в статье на Хабре, прайсинг работает не только при заказе машины.

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

 

Сначала сервисы параллельно собирают параметры поездки: тарифную категорию, геозоны, скидки, повышенный спрос и дополнительные услуги. Зависимости между источниками выстраиваются в граф, а запросы выполняются асинхронно на базе userver. Если некритичный источник не ответил, весь расчёт не падает.

 

Сам алгоритм раньше можно было бы держать в C++, но он меняется в среднем дважды в неделю. Выкатка сервиса на 50 подов занимает около 40 минут, а лес динамических конфигов быстро превратил бы код в музей условных операторов.

Поэтому Яндекс разработал собственный DSL. В нём есть условия, функции, неизменяемые значения и fold вместо циклов. Правила собираются в последовательную цепочку: каждое преобразование получает текущую цену и параметры, а возвращает новый результат с метаданными. Грамматику описали через ANTLR 4, а верификатор Z3 проверяет, что программа не выдаст некорректную цену.

 

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

 

В итоге прайсинг превратился в отдельную платформу, которой уже пользуются Такси, Доставка и сервис зарядки электромобилей.

RSS: Новости на портале Anti-Malware.ru