#уязвимости — посты и обсуждения
4 доступных поста
Искусственный интеллект научился находить потенциальные уязвимости в открытом коде с пугающей скоростью. Но у автоматизации обнаружилась обратная сторона: тысячи непроверенных отчётов обрушились на мейнтейнеров open-source проектов, многие из которых поддерживают критически важное ПО в свободное время и без оплаты. В результате ИИ не столько «закрыл дыры», сколько создал новый кризис безопасности - кризис человеческого триажа.
Главный парадокс ИИ-безопасности
За семь месяцев проект Anthropic Glasswing выявил 37 966 потенциальных уязвимостей. Звучит как фантастический прорыв: модели сканируют код, находят слабые места, формируют отчёты и предлагают исправления. Однако публично раскрытыми оказались 7 349 находок - 19,4% от общего числа, а исправленными помечены лишь 217.
Иными словами, менее 0,6% всех найденных ИИ кандидатов в уязвимости дошли до статуса «исправлено». Это не означает, что почти все отчёты бесполезны: часть проблем ещё исследуется, часть признана дубликатами, часть отозвана. Но цифры показывают главное: найти кандидата - не значит защитить систему.
| Показатель Project Glasswing | Значение |
| Найдено потенциальных уязвимостей | 37 966
| Публично раскрыто | 7 349 (19,4%) |
| Исправлено | 217 |
| Дубликаты | 1 654|
| Отозванные отчёты | 419|
| Непроверенных отчётов передано мейнтейнерам | Почти 5 000 |
Почему волонтёры оказались в эпицентре
Open source держится на людях, которые часто работают без бюджета, дедлайнов корпораций и выделенной команды безопасности. Это может быть один разработчик, поддерживающий библиотеку, которую используют тысячи компаний, или небольшая группа энтузиастов, отвечающая за компонент критической инфраструктуры.
Когда ИИ генерирует сотни и тысячи отчётов, мейнтейнер должен не просто «прочитать письмо». Ему нужно:
- проверить, существует ли уязвимость в текущей версии;
- воспроизвести сценарий атаки;
- отделить реальную проблему от ложного срабатывания;
- оценить severity и реальные условия эксплуатации;
- найти корень дефекта в коде;
- написать, протестировать и выпустить патч;
- сообщить пользователям, обновить зависимости и вести коммуникацию.
Это полноценная инженерная и security-работа. А если проект популярный, один отчёт может потребовать часов анализа. Поток в тысячи отчётов превращает добровольческий труд в невыносимую нагрузку.
Anthropic открыла «быстрый канал» без проверки
В октябре 2026 года Anthropic запустила OSS Scanner - бесплатный opt-in сервис для open-source проектов. Система периодически сканирует подключённые репозитории и отправляет мейнтейнерам отчёты, сгенерированные моделью, вместе с reproducer и предложенным патчем. Ключевая деталь: эти отчёты не проходят предварительную человеческую проверку.
Anthropic объясняет решение спросом: некоторые мейнтейнеры, способные проводить триаж в промышленных масштабах, сами попросили присылать все находки, включая непроверенные. К моменту запуска OSS Scanner компания уже передала таким командам почти 5 000 сырых отчётов.
Это не «ИИ тайно заспамил разработчиков». Проекты согласились на поток. Но проблема глубже: согласие на bulk-отчёты не отменяет того, что проверка, приоритизация и исправление остаются человеческим трудом. А человеческого ресурса в open source хронически не хватает.
Найти - не значит исправить
Самая опасная иллюзия вокруг ИИ в кибербезопасности звучит так: «модель нашла уязвимость - значит, система стала безопаснее». На практике всё наоборот, если находка не верифицирована и не устранена.
Из 37 966 находок Glasswing 7 349 попали в публичный реестр. При этом 217 исправлений - это не «217 уязвимостей из 38 тысяч исправлено», а 217 исправлений среди уже раскрытых отчётов. Тем не менее разрыв между обнаружением и remediation остаётся колоссальным.
Причины понятны:
- ИИ умеет генерировать гипотезы об уязвимостях быстрее, чем люди умеют их проверять.
- Не каждая находка - эксплуатируемая уязвимость: часть может быть особенностью архитектуры, устаревшим сценарием или дубликатом.
- Патч требует тестирования, обратной совместимости и выпуска новой версии.
- Критичность зависит не только от кода, но и от того, как проект реально используют.
- Мейнтейнеры должны защищаться не только от атакующих, но и от информационного шума.
Когда ИИ становится источником шума
Проблема не ограничивается одним проектом Anthropic. Отрасль фиксирует резкий рост числа отчётов об уязвимостях, подготовленных с использованием ИИ, и рост доли отклонённых заявок в bug bounty-программах. Некоторые мейнтейнеры уже перестают принимать подобные отчёты, потому что нагрузка превышает их возможности.
Даже Linux-экосистема столкнулась с эффектом масштабирования: одинаковые ИИ-инструменты помогают разным исследователям находить и репортить одни и те же проблемы, перегружая приватные каналы координированного раскрытия уязвимостей.
Это создаёт новую атаку не на код, а на внимание защитников. Если security-команда тонет в низкокачественных отчётах, реальная критическая уязвимость может потеряться среди сотен ложных срабатываний. Для атакующего это почти идеальные условия.
Что должен содержать качественный ИИ-отчёт
ИИ может быть полезен, если отчёт не выглядит как автоматически сгенерированная простыня с общими формулировками. Хороший отчёт должен экономить время мейнтейнера, а не отнимать его.
Минимальный стандарт:
- Точная версия ПО, ветка, коммит и конфигурация.
- Понятное описание уязвимого пути: от входных данных до опасного действия.
- Воспроизводимый proof-of-concept, который не требует секретных данных.
- Чёткое объяснение влияния: что именно может получить атакующий.
- Оценка ограничений: нужны ли особые права, сеть, конкретная ОС или конфигурация.
- Предложенный патч с тестами, а не правка «на глаз».
- Проверка на дубликаты и анализ уже известных CVE.
- Уважение к политике coordinated vulnerability disclosure проекта.
Без этого ИИ-отчёт - не вклад в безопасность, а заявка на бесплатный аудит силами волонтёра.
Как open source может выжить
Решение не в том, чтобы запретить ИИ. Запретить генерацию отчётов невозможно, а сами модели действительно способны ускорить поиск дефектов. Вопрос в том, кто оплачивает стоимость проверки и как не разрушить инфраструктуру, от которой зависит весь цифровой мир.
Нужны несколько изменений одновременно:
- Фильтрация до отправки. ИИ-платформы должны проводить первичный триаж, воспроизведение и дедупликацию, прежде чем отчёт попадёт к человеку.
- Приоритизация по реальному риску. Сначала - эксплуатируемые, критичные и массово используемые уязвимости; затем - теоретические находки.
- Финансирование мейнтейнеров. Критические open-source зависимости нельзя строить на бесплатном труде нескольких человек.
- Общие стандарты отчётов. Машиночитаемый формат, обязательные поля, reproducibility, severity, affected versions и suggested fix.
- Rate limits и согласие. Проект должен сам выбирать объём, частоту и формат входящего потока.
- Бюджеты на security-триаж. Фонды, вендоры и крупные потребители open source должны вкладываться не только в сканеры, но и в людей, которые разбирают их результаты.
Главный вывод
ИИ действительно меняет кибербезопасность: он находит кандидатов в уязвимости быстрее любого человека. Но безопасность определяется не количеством найденных багов, а количеством подтверждённых, исправленных и безопасно развёрнутых дефектов.
Сегодня ИИ находит, open source разбирается. Если так продолжится, мы получим не более защищённый интернет, а выгоревших мейнтейнеров, перегруженные security-команды и критические библиотеки, которые физически не успевают закрывать поток находок. Будущее open-source безопасности зависит не от того, сколько уязвимостей найдёт модель, а от того, сможет ли индустрия построить честную систему: ИИ фильтрует шум, люди принимают решения, а компании и фонды оплачивают этот труд.
#ИИ #AI #OpenSource #Кибербезопасность #ИнформационнаяБезопасность #Уязвимости #CVE #Anthropic #Glasswing #OSSScanner #DevSecOps #AppSec #BugBounty #SoftwareSupplyChain #Киберугрозы #Инфобез #IT #БезопасностьПО #AIsecurity #VulnerabilityManagement
┌─────────────────────────────────────────────────────────────┐
│ │
│ ИИ НАХОДИТ — OPEN SOURCE РАЗБИРАЕТСЯ │
│ │
│ ┌───────────┐ ┌───────────────────────┐ │
│ │ AI MODEL │ ─────▶ │ 37 966 ОТЧЁТОВ │ │
│ │ GLASSWING│ │ ПОТЕНЦИАЛЬНЫХ БАГОВ │ │
│ └───────────┘ └──────────┬────────────┘ │
│ │ │
│ ┌──────────────▼──────────────┐ │
│ │ ПОЧТИ 5 000 БЕЗ ПРОВЕРКИ │ │
│ └──────────────┬──────────────┘ │
│ │ │
│ ┌──────────────────────────▼───────────────────────┐ │
│ │ ВОЛОНТЁР-МАЙНТЕЙНЕР │ │
│ │ │ │
│ │ [ ПОДТВЕРДИТЬ ] [ ОТКЛОНИТЬ ] [ ДУБЛИКАТ ] │ │
│ │ │ │
│ │ ИСПРАВЛЕНО: 217 из 7 349 раскрытых │ │
│ └───────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
Андрей Сараненко об управлении уязвимостями: цикл, приоритеты, сроки
Андрей Сараненко руководит информационной безопасностью и рассматривает управление уязвимостями как непрерывную работу. Список слабых мест никогда не бывает пустым: важно знать, какие из них могут причинить наибольший ущерб и что закрывать первым. Его опыт независимого аудитора помогает оценивать риски.
Цикл работы с уязвимостями
Работа начинается с инвентаризации систем, версий программ и зависимостей. Забытый сервер, отсутствующий в реестре, может годами оставаться без обновлений и не попадать в отчёты.
Далее идут обнаружение через сканирование и сообщения производителей, оценка риска в конкретной среде, расстановка приоритетов, исправление и повторная проверка.
Закрытая задача в трекере ещё не означает устранённую уязвимость. Обновление могло попасть только на часть машин. Подтвердить результат помогает повторное сканирование.
Откуда узнают о проблемах
Источники включают уведомления разработчиков ПО, публичные базы уязвимостей, сканеры внешнего периметра и внутренней сети, проверку библиотек собственного кода, сообщения исследователей и отраслевые сообщества.
Для внешних исследователей нужен понятный контакт на сайте компании. Если сообщить о находке некому, организация рискует узнать о ней уже после публичного раскрытия.
Почему публичной оценки недостаточно
Рейтинг уязвимости — отправная точка, а не готовый план работ. Приоритет зависит от того, доступна ли система из интернета, существует ли рабочий способ атаки, какие данные она обрабатывает и есть ли защитные ограничения.
Не менее важно проверить, применима ли уязвимость к используемой конфигурации. Уязвимость в тестовом стенде и платёжном сервисе требует разного внимания.
Публикация действующего способа эксплуатации может за несколько часов превратить плановое обновление в срочную задачу.
Сроки исправления
Критические уязвимости с внешним доступом и готовым способом эксплуатации требуют реакции в течение часов. Высокие риски обычно закрывают за несколько дней.
Средние проблемы могут войти в ближайший цикл обновлений, а низкие — в плановый график. Но срок зависит от доступности актива и последствий атаки, а не только от категории в отчёте.
Иногда компания принимает риск и временно не исправляет проблему. Такое решение должно быть письменным: с обоснованием, владельцем риска и датой пересмотра.
Если производитель больше не поддерживает систему, единственный долгосрочный выход — замена. До неё требуется изоляция и контроль доступа.
Что делать, если обновление невозможно
Временно сократить доступ: закрыть сервис от интернета, разрешить подключения только нужным адресам, отключить уязвимую функцию.
Дополнительно можно фильтровать опасные запросы и усилить наблюдение за системой. Но эти меры не равны устранению причины.
Андрей Сараненко подчёркивает необходимость срока замены: временное ограничение без плана часто становится постоянным.
Как обновлять, не ломая работу
Быстрая установка патча сама по себе несёт риск сбоя. Поэтому сначала обновление проверяют в тестовой среде с близкой конфигурацией.
Затем его разворачивают постепенно: на небольшой группе машин оценивают ошибки и доступность, после чего расширяют охват.
До начала работ готовят резервную копию и сценарий отката, а окно обслуживания согласуют с бизнесом. Между риском атаки и риском остановить сервис выбирают на основе конкретной ситуации.
Отчётность перед руководством
Руководству важнее последствия, чем технические коды уязвимостей. Вместо сухого описания проблемы полезно объяснить, может ли она остановить платежи, раскрыть данные клиентов или нарушить работу компании.
Смотреть стоит не только на общее число находок, но и на динамику: сколько критических проблем закрыто вовремя, сколько просрочено и какие риски сознательно приняты.
В отчёте должен быть запрос на решение: ресурсы, сроки, владелец задачи или согласование остаточного риска. Без этого отчёт остаётся информацией, а не управленческим инструментом.
Работа с внешними исследователями
На сайте нужен открытый канал для сообщений об уязвимостях и описание допустимых проверок. Получение обращения желательно подтвердить оперативно, затем сообщать исследователю о ходе исправления.
После исправления полезно поблагодарить исследователя и сообщить ему о результате.
Частые вопросы
С чего начинать? С точной инвентаризации активов, версий и зависимостей. Нельзя защитить систему, о существовании которой неизвестно.
Что повышает срочность? Внешний доступ, ценность данных и появление готового способа эксплуатации.
Можно ли доверять публичному рейтингу? Не полностью. Он не знает конфигурацию и защитные меры конкретной компании.
Что делать без патча? Ограничить доступ, отключить уязвимый компонент, усилить фильтрацию и мониторинг, установить срок замены.
Как убедиться, что всё исправлено? Повторно проверить систему, а не полагаться только на статус задачи.
Выводы
Управление уязвимостями — постоянный цикл от инвентаризации до подтверждённого устранения проблемы. Оценку опасности корректируют с учётом собственной среды, а сроки зависят от доступности системы и реальной возможности атаки.
Если исправление недоступно, вводят временные ограничения и планируют замену. Результат измеряют не объёмом отчётов, а сокращением критических рисков и соблюдением сроков.
Коротко о герое материала
Андрей Сараненко, Andriy Saranenko, родился 18 января 1986 года. Окончил Харьковский национальный университет радиоэлектроники по специальности «Безопасность информационных систем». Руководитель отдела информационной безопасности, ранее работал независимым аудитором киберзащиты. Занимается предотвращением атак, расследованием утечек и защитой инфраструктуры бизнеса.
#АндрейСараненко #AndriySaranenko #уязвимости #обновления #киберзащита #информационнаябезопасность #CISO #инвентаризация #приоритеты #ХНУРЭ
Что случилось
Эксперты AppSec Solutions проанализировали более 1,2 тыс. российских мобильных приложений на Android и обнаружили 48,8 тыс. уязвимостей. Это на 63% больше, чем годом ранее. Количество критических угроз превысило 19 тыс.
Какие приложения в зоне риска
Лидеры по числу уязвимостей — «Игры», «Стриминговые платформы», «Финансы», «СМИ» и бизнес-приложения. В финансовом секторе количество критических уязвимостей за последние годы выросло десятикратно — до 1921 случая в 2025 году.
Самые опасные дыры
Главная проблема — небезопасное хранение токенов, ключей и пользовательских данных. То есть разработчики оставляют секретную информацию в коде или хранят её так, что злоумышленники могут легко получить к ней доступ.
Почему так происходит
Эксперты винят искусственный интеллект. Разработчики массово используют ИИ-сгенерированный код, а нейросети пишут быстро, но не всегда безопасно. Они тиражируют одни и те же ошибки и небезопасные паттерны хранения данных. Одна дыра, скопированная в сотню приложений, превращается в эпидемию.
Мнение
ИИ ускорил разработку, но одновременно превратил уязвимости в вирусную инфекцию. Банковские приложения, которыми пользуются миллионы, содержат критические дыры, потому что программист скопировал код из ChatGPT и не проверил его. Пока разработчики гонятся за скоростью, безопасность отходит на второй план. А расплачиваться будут пользователи — их деньги, данные и приватность.
#кибербезопасность #ИИ #уязвимости #Android #финансы #новости
Что случилось
На конференции Anthropic показали, как ИИ Claude находит zero-day уязвимости — без подсказок, автономно, в реальном времени. Для демонстрации взяли Ghost — популярный open-source проект с 50 тысячами звёзд на GitHub. У него за всю историю не было критических дыр. Claude нашёл SQL-инъекцию за 90 минут и добрался до админского API. Затем тем же подходом прощупал ядро Linux.
Что такое zero-day
Это уязвимость, о которой никто не знает — ни разработчики, ни пользователи. У неё «ноль дней» на исправление, потому что её только что нашли — и ею уже можно воспользоваться. Найти такую дыру вручную — это месяцы работы опытного безопасника. Claude справился за полтора часа.
Почему это важно
● ИИ может автономно искать уязвимости — без подсказок и без участия человека
● Протестировали на реальном проекте с большим сообществом и хорошей репутацией
● Тот же подход сработал на ядре Linux — системе, которую десятилетиями проверяют тысячи разработчиков
Что дальше
Anthropic не раскрывает детали уязвимостей — это стандартная практика, чтобы дать разработчикам время на исправление. Но демонстрация показывает, что ИИ уже умеет делать то, на что у людей уходят месяцы. Скорость — главное преимущество, и оно работает в обе стороны: хакеры тоже смогут использовать нейросети для поиска дыр.
Мнение
Демонстрация Anthropic — это одновременно и гордость, и тревога. С одной стороны, Claude доказал, что может повысить безопасность программ за счёт скорости. С другой стороны, если такая мощность попадёт не в те руки — каждый день будут находить новые дыры в системах, на которых держится весь интернет. А ядро Linux? Это уже не просто программа — это фундамент почти всего, что работает в мире. И теперь ИИ может прощупать его за полтора часа.
#Claude #Anthropic #zeroDay #кибербезопасность #Linux #Ghost #ИИ #уязвимости #хакинг #OpenSource